From paul@nohats.ca Tue Mar 5 09:37:10 2024 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; Tue, 5 Mar 2024 12:37:01 -0500 (EST) Date: Tue, 5 Mar 2024 12:37:01 -0500 (EST) From: Paul Wouters To: dd@ietf.org In-Reply-To: <5ED40695-7126-4B8A-A9C3-AA2139CC8953@fl1ger.de> Message-ID: References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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