On Mon, May 1, 2023 at 12:55 PM libor.peltan <libor.peltan= 40nic...@dmarc.ietf.org> wrote:
> Hi Paul, > > if you really ask for opinions, here is mine. > > Considering the recent voluminous discussion about the meaning of Lame > delegation, it seems to me that there are at least several people being > more-or-less sure what the term means, with the issue that everyone > thinks something slightly (or less slightly) different. > > A word that means something different according to each speaker is not a > good communication tool. I'm afraid (but not sure) that we should rather > avoid it to prevent present and future misunderstanding. > > In order to do so, I'd suggest treating it similalrly as the term > Bailiwick: abandon the word and make up a new, precisely defined term > that means the same for everyone. But I don't insist. > > Libor has a good point (and similarly, I don't insist.) I think, in fact, more than one term may be needed, since there are distinct situations involved: - One situation is where at least one (but not all) parent-child NS targets do not respond authoritatively. - Another situation is where none of the parent-child NS targets respond authoritatively. The latter is something I think that needs to be addressed, separately, by the DNSOP WG. (I have some ideas around that, but won't clutter this discussion with those.) Brian > Dne 01. 05. 23 v 18:09 Paul Hoffman napsal(a): > > It would be grand if a bunch more people would speak up on this thread. > > > > --Paul Hoffman, wearing my co-author hat > > > > On Apr 27, 2023, at 1:05 PM, Benno Overeinder <be...@nlnetlabs.nl> > wrote: > >> Dear WG, > >> > >> The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion > >> on lame delegation did not find consensus, but two specific suggestions > >> were put forward. We would like to include one of them in rfc8499bis if > >> we can get consensus to do so. > >> > >> The chairs are seeking input on the following two suggestions: > >> > >> * Either we leave the definition of “lame delegation” as it is with the > >> comment that no consensus could be found, or > >> > >> * alternatively, we include a shorter definition without specific > >> examples. > >> > >> 1) Leaving the definition of lame delegation as in the current > >> draft-ietf-dnsop-rfc8499bis, and including the addition by the > >> authors that: > >> > >> "These early definitions do not match current use of the term "lame > >> delegation", but there is also no consensus on what a lame delegation > >> is." (Maybe change to ... no consensus what *exactly* a lame > >> delegation is.) > >> > >> 2) Update the definition as proposed by Duane and with the agreement of > >> some others (see mailing list > https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/): > >> > >> "A lame delegation is said to exist when one or more authoritative > >> servers designated by the delegating NS RRset or by the child's apex > >> NS RRset answers non-authoritatively [or not at all] for a zone". > >> > >> The chairs ask the WG to discuss these two alternative definitions of > >> the term "lame delegation". We close the consultation period on > >> Thursday 4 May. > >> > >> Regards, > >> > >> Benno > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
