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.hoff...@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 <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://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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
