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

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.

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