IETF Logo Mail Archive

Re: [dd] [Ext] Charter - objectives and scope (long tail)

Paul Hoffman <paul.hoffman@icann.org> Sat, 23 March 2024 04:32 UTC

Return-Path: <paul.hoffman@icann.org>
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 1D26BC14F699; Fri, 22 Mar 2024 21:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 j74NyRYFSwaK; Fri, 22 Mar 2024 21:32:56 -0700 (PDT)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 386B5C14F696; Fri, 22 Mar 2024 21:32:56 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa4.dc.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 42N4Wn6u024762 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Mar 2024 21:32:49 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Fri, 22 Mar 2024 21:32:53 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1258.028; Fri, 22 Mar 2024 21:32:53 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
CC: "dd@ietf.org" <dd@ietf.org>
Thread-Topic: [Ext] [dd] Charter - objectives and scope (long tail)
Thread-Index: AQHafNsrB2xHPoQn5kO2B08+BZnRVA==
Date: Sat, 23 Mar 2024 04:32:53 +0000
Message-ID: <DB7754B6-871E-41CE-BC25-71A62D626CE6@icann.org>
References: <0521FB45-FC12-4297-8B17-41053137FF2E@icann.org> <581d56a5-b9c7-a301-264e-6b7282c07c16@redbarn.org>
In-Reply-To: <581d56a5-b9c7-a301-264e-6b7282c07c16@redbarn.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <81044ECE450CEA4590AEF113A1D6ECBC@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-23_01,2024-03-21_02,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/LCCK3MkrVKOq_Cqbej60-XVqcpI>
Subject: Re: [dd] [Ext] Charter - objectives and scope (long tail)
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: Sat, 23 Mar 2024 04:32:57 -0000

On Mar 23, 2024, at 14:26, Paul Vixie <paul=40redbarn.org@dmarc.ietf.org> wrote:
> 
> as a charter matter, i hope we can say that no existing signaling (NS RRset and associated AAAA/A RRsets) will be obsoleted, and that DELEG (or whatever new signaling is decided) will be semantically additional. new signaling might add new servers but those described by the NS RRset will remain "at the core" and that domain delegations are expected to remain usable in the future even by implementations who never upgrade. similarly, new signaling might add new trust mechanisms or new transports but the old UDP/53 and TCP/53 and TCP/853 transports are expected to be continuously supported for those nameservers denoted in the NS RRset and associated AAAA/A RRsets, without requirement for newly signaled mechanisms for trust or secrecy or any other purpose.

I hear what you're saying, but I don't see a good place in the charter to say what the WG would not be doing. Can you propose text and say where it would go?

--Paul Hoffman

v2.37.1 | Report a Bug | By Email | System Status