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

"libor.peltan" <libor.peltan@nic.cz> Mon, 01 May 2023 19:55 UTC

Return-Path: <libor.peltan@nic.cz>
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 B97B3C151701 for <dnsop@ietfa.amsl.com>; Mon, 1 May 2023 12:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NMEVLlvvtgAx for <dnsop@ietfa.amsl.com>; Mon, 1 May 2023 12:55:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 DA8FEC14CE30 for <dnsop@ietf.org>; Mon, 1 May 2023 12:55:17 -0700 (PDT)
Received: from [192.168.88.252] (ip-217-030-074-194.aim-net.cz [217.30.74.194]) by mail.nic.cz (Postfix) with ESMTPSA id 8354B1C17D7; Mon, 1 May 2023 21:55:12 +0200 (CEST)
Authentication-Results: mail.nic.cz; auth=pass smtp.auth=libor.peltan@nic.cz smtp.mailfrom=libor.peltan@nic.cz
Message-ID: <6e16ded9-695b-a901-0d1b-a5828ff4d2a0@nic.cz>
Date: Mon, 01 May 2023 21:55:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
To: Paul Hoffman <paul.hoffman@icann.org>, DNSOP Working Group <dnsop@ietf.org>
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org>
Content-Language: en-US
From: "libor.peltan" <libor.peltan@nic.cz>
In-Reply-To: <40C193AF-938C-418F-924E-94F4DD358164@icann.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.103.7 at mail
X-Virus-Status: Clean
X-Spamd-Bar: -----
X-Spamd-Result: default: False [-5.10 / 20.00]; BAYES_HAM(-5.00)[100.00%]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:48574, ipnet:217.30.64.0/20, country:CZ]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]
X-Rspamd-Action: no action
X-Rspamd-Queue-Id: 8354B1C17D7
X-Rspamd-Server: mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EZBzxD4PninOPnO2JsJ3UMcZQxQ>
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: Mon, 01 May 2023 19:55:21 -0000

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.

Cheers,

Libor


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