Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

On Mon, May 01, 2023 at 04:43:11PM +0000, Wessels, Duane wrote:
> My preferred definition is the one originally given by Paul Vixie, amended by myself, and further amended by Peter Thomassen:
> 
> 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 for a zone.

+1 for this one.

Fred

> 
> I don’t think it is perfect, but it is an improvement.  I don’t think perfection will be achievable.  
> 
> IMO “[or not at all]” does not belong in the definition.  I don’t think we should allow timeouts to be confused for or considered as lame delegation.
> 
> If something like the above definition is adopted then the document can note there is some historical lack of agreement or consistency in use of the term.
> 
> DW
>  
> 
> 
> > On May 1, 2023, at 9:09 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
> > 
> > Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> > 
> > 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 <benno@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://secure-web.cisco.com/1X5AMTQJt2cXj7u31WPDppT_N_lSyi56z_C_stVVEipVVZkqvDApuQPa0iKxw5z8KkYh6lUYaa8WwEbu1lbUw_3U3-oCZDRWfYload0wQnMB3d76sNuzWFVBh7JB6a-2AOK0wOchJz8ErMhve7dpEUAX3u3v-rv-1jqen-3Ar6uMAJe4pFpHNVMWX8RyUI7uPYRUghgCekgBWibFm6LiPtCBLmTeUAdGkHdbCvCQ-SgAe56iNE4EwIGnrBWJTVJZlM-Dv3FrK04mE2gMsQs6HDzz40kt4871oRIkuNMadfKo/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2F4E1AQKGivEHtJDB85gSNhofRuyM%2F):
> >> 
> >>  "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://secure-web.cisco.com/1XVxOCcNMkTcMeadUBQk9SlINRiQvUqtUMpxSKIOYBnT1ERKTnDtcFN1UjyDbfzk5FQqhfy31BXnCbOKFunIXd_OgZghAR9dJnnqlAmKIktWHve95FPY6YA3UinPiPabOUAEi7sOIwtzoF6rScnH_ml4EN5VeCkDj_DbUdU1FINNiKRFrKNlopElAMuHQoV1jehl-oCQtlNNopUy_X-mm_fPAbRNsYgc4S411S5vVePb4M-3xft1EktHXfsQNSe-y_vNR947juf5DmA2OYgq3gw0Efu3o0GxuyisOZ23nNj0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop