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

[Benno Overeinder]

Dear WG,

The extended WGLC rfc8499bis has been closed.  With the specific 
question from the chairs, the WG did not find consensus on either of the 
two proposed definitions of the term "lame delegation".  In one 
subthread of the discussion there was some convergence towards a 
definition, but in other subthreads we saw suggestions for new terms and 
definitions, which was not the question to the working group.


The chairs are taking the current WGLC discussion into their evaluation 
of how to proceed and will share our way forward with the document in 
the first half next week.


In the meantime, please continue the discussion.

Best regards,

-- Benno


On 27/04/2023 22:05, Benno Overeinder 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

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

[Donald Eastlake]

I've been around in DNS for quite a while.

The way I've always heard "lame delegation" used is in the sense of a
useless parent NS record at a delegation point. Note that "delegation" is
singular. The usual case is that the server name in the NS RR is a
non-existent name or has no address associated with it or, if it does have
an address, there is no DNS server there. If an NS RR at the delegation
point has an existing name that resolves to the address of a DNS server,
its lameness is getting pretty mild but if that server can't answer
authoritatively, then I guess it really is still a lame delegation...

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Thu, Apr 27, 2023 at 4:05 PM Benno Overeinder  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

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

[John Kristoff]

On Mon, 01 May 2023 21:15:29 +
Joe Abley  wrote:

> Yes -- some people (not me) would evidently describe a server that
> they didn't receive a response from as lame.

Lots of people and organizations tend to talk about "types" or "ways"
in which a server or delegation is lame. Here are a few well known
organizations or popular pages talking about what lame means so you
know the sorts of inconsistency (that's a term I like :-) you're up
against:

  

  

  
  
  

  

John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

Hi Benno,

On Thu, Apr 27, 2023 at 16:05, Benno Overeinder <[be...@nlnetlabs.nl](mailto:On 
Thu, Apr 27, 2023 at 16:05, Benno Overeinder < wrote:

> 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".

This is close to what I understand by the term.

I would eliminate the parenthetical section, since as I have droned on about at 
some length already I think the lack of a response is not what we understand by 
"lame" -- lameness involves a response, and without a response there can be no 
lameness.

I am also unsure about "or by the child's apex NS RRSet" since in my mind 
"delegation" is something that is configured definitively north of the zone 
cut. But since some implementations promote the NS set found south after 
following a referral I suppose the effect is the same if a server exhibits the 
same characteristics.

Joe

>___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[George Michaelson]

I prefer option 2. I think it fulfills the implicit obligations
inherent in 1) -which would be to fill the hole of uncertainty. Its
succinct, and it covers the cases I think define the condition.

I would ask if 2) also needs to define ".. or cannot be resolved"
because "[or not at all]" is a bit wide to encompass "that FQDN didn't
actually resolve" for a listed NS. As it stands it seems to terminate
in a belief you have something to ask. It's equally lame to be pointed
to this.name.hasnt.been.delegated.alt. as an NS

Irrespective I prefer 2). I don't like the dangling fate of 1) I think
the lack of agreement is only conditionally true: I think we could
reach consensus on 2) if we tried a bit harder.

-G

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Benno Overeinder]

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