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

On Mon, May 1, 2023 at 12:55 PM libor.peltan <libor.peltan=
40nic.cz@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 <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://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
>