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
