Re: [dd] starting charter text for the DELEG BOF discussion

Paul Wouters <paul@nohats.ca> Tue, 05 March 2024 17:37 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8A9C17C8A9 for <dd@ietfa.amsl.com>; Tue, 5 Mar 2024 09:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 uYRAWGCh29fU for <dd@ietfa.amsl.com>; Tue, 5 Mar 2024 09:37:06 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9B4C17C8A2 for <dd@ietf.org>; Tue, 5 Mar 2024 09:37:05 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Tq2nC390LzCnZ for <dd@ietf.org>; Tue, 5 Mar 2024 18:37:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1709660223; bh=CVT1DkzmqEbCRYxdjr09z6Lk4jXghh8vX66tlHGPF+0=; h=Date:From:To:Subject:In-Reply-To:References; b=JXQnehyeYmPjpOREQuizUfoHo2phPjTR4ZF+TjIzwKpVnCGqdjPg6U+mUuY6OTbGM nx8VH1gClilCLT12NhOBtGylZqZ3P51smZ3uHmLPykckHDSiuGooCJlbBQBpADn21G I2UDtYulWdGaQhUoGAyPiczzqO/mdY1rbG9K9EZY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NfXklUTwJKCj for <dd@ietf.org>; Tue, 5 Mar 2024 18:37:02 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dd@ietf.org>; Tue, 5 Mar 2024 18:37:02 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7B1B8117A8B8; Tue, 5 Mar 2024 12:37:01 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 76D66117A8B7 for <dd@ietf.org>; Tue, 5 Mar 2024 12:37:01 -0500 (EST)
Date: Tue, 05 Mar 2024 12:37:01 -0500
From: Paul Wouters <paul@nohats.ca>
To: dd@ietf.org
In-Reply-To: <5ED40695-7126-4B8A-A9C3-AA2139CC8953@fl1ger.de>
Message-ID: <c2c4d84c-210c-115a-ac29-aa1b96e518ad@nohats.ca>
References: <yblbk7wl65k.fsf@wx.hardakers.net> <5ED40695-7126-4B8A-A9C3-AA2139CC8953@fl1ger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/1uym85b9JbjWwPbZmEnoqfayIJs>
Subject: Re: [dd] starting charter text for the DELEG BOF discussion
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2024 17:37:10 -0000

On Tue, 5 Mar 2024, Ralf Weber wrote:

>> To address these challenges, the working group will first develop the requirements for adding a new signaling mechanism that allows parents to return DNS delegation information to resolvers.
>
> Given that there is current work on actual protocol ideas that would stall that. I’m ok with a requirements document and changing the spec, but I don’t want to stall that work, so maybe delete “first” from that sentence.

What I would like to avoid see happening is that people have expectations
and desires for a solution expressed in the requirements doc that are
not covered by DELEG, and getting told "we cannot change it anymore,
it is too late".

A new WG still has a bunch of fundamental questions to answer, such as
whether to overload the DS or not, whether to create generic RRtypes
that resolve at the parent, and whether a new delegation type would
augment or obsolete NS/DS records, and whether nameserver properties
should be stored at the nameserver zone or the delegation of the
target zone.

So the phrase "stall the work" seems inaccurate. We are doing the work,
but the work is more than just finishing one currently proposed draft.

Paul