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

Magnus Sandberg <mem@fallback.netnod.se> Tue, 02 May 2023 09:06 UTC

Return-Path: <mem@fallback.netnod.se>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6DFC14CE2F for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 02:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_QMD0VJNAEd for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 02:06:32 -0700 (PDT)
Received: from mail2.netnod.se (mail2.netnod.se [192.71.80.75]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981F0C151B04 for <dnsop@ietf.org>; Tue, 2 May 2023 02:06:31 -0700 (PDT)
Received: from [IPV6:2a01:3f0:1:10::1001] (unknown [IPv6:2a01:3f0:1:10::1001]) (Authenticated sender: mem) by mail2.netnod.se (Postfix) with ESMTPSA id 5B73620000D for <dnsop@ietf.org>; Tue, 2 May 2023 11:06:28 +0200 (CEST)
Message-ID: <b0e489a9-fcd5-2efc-2cdc-6763403a90ec@fallback.netnod.se>
Date: Tue, 02 May 2023 11:06:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
To: dnsop@ietf.org
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org>
Content-Language: sv-SE, en-US
From: Magnus Sandberg <mem@fallback.netnod.se>
In-Reply-To: <40C193AF-938C-418F-924E-94F4DD358164@icann.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0p0x_x-0BC5lATAly-rFip4P-8g>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2023 09:06:36 -0000

Hi all,

I think one of the problems are that we look at the term from different 
perspectives.

For me "lame delegation" is a log messages from the resolver software.

A lot of the comments are more from the human view and with different 
operational angles or potential end user experience.


If we only see it from the resolver software point of view it is 
something in the lines of "the status of the response (from what I 
thought was an authoritative server) didn't match my expectations", or 
"I didn't get a response at all".


When humans interpret that log message, we can see it from the resolver 
operation view, the zone owner view, the end users experience when 
trying to reach some service within the child zone, including slow 
responses as the resolver has to do extra work to find a way around the 
problem, etc.


So too many looking glasses or angles to know what we try to make clearer.

Regards,
// mem (without hats)



Den 2023-05-01 kl. 18:09, skrev Paul Hoffman:
> 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