IETF Logo Mail Archive

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

Paul Vixie <paul@redbarn.org> Sat, 23 March 2024 04:26 UTC

Return-Path: <paul@redbarn.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 0BAD5C14F6AA for <dd@ietfa.amsl.com>; Fri, 22 Mar 2024 21:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.798
X-Spam-Level:
X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=redbarn.org
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 4vn4W7sXrbdI for <dd@ietfa.amsl.com>; Fri, 22 Mar 2024 21:26:50 -0700 (PDT)
Received: from util.redbarn.org (util.redbarn.org [IPv6:2001:559:8000:cd::222]) (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 2F527C14F68F for <dd@ietf.org>; Fri, 22 Mar 2024 21:26:50 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.redbarn.org", Issuer "RapidSSL TLS RSA CA G1" (not verified)) by util.redbarn.org (Postfix) with ESMTPS id 40FD619CCAE for <dd@ietf.org>; Sat, 23 Mar 2024 04:26:49 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1711168009; bh=E5Zs8+Bb95kgrPFsj/h5l73GXP6nmLqRpRHZNMLpDlk=; h=Subject:To:References:From:Date:In-Reply-To; b=SWcid31Ko7CBoDH+umtQrvv17yleYAly4zZjgRz6+V76R3zTGw5rwH48r1KuxLst8 9q3TNE508KXMbHJDDC8+d8iwWkyonr1zioFhMInh6FDUu+Hjcb02XB1a9VHOIQtH0t dNrGjKtirl9VTgJ6uf/GP5q28Apkv77ISRARYAXk=
Received: from [24.104.150.175] (dhcp-175.access.rits.tisf.net [24.104.150.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 0615CC3F1F for <dd@ietf.org>; Sat, 23 Mar 2024 04:26:49 +0000 (UTC)
To: "dd@ietf.org" <dd@ietf.org>
References: <0521FB45-FC12-4297-8B17-41053137FF2E@icann.org>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <581d56a5-b9c7-a301-264e-6b7282c07c16@redbarn.org>
Date: Fri, 22 Mar 2024 21:26:46 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.60
MIME-Version: 1.0
In-Reply-To: <0521FB45-FC12-4297-8B17-41053137FF2E@icann.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/DxNl19I2yxS6WCUDfmny4K-2PCs>
Subject: Re: [dd] 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:26:54 -0000

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.

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