Re: [dd] [Ext] Charter - objectives and scope (long tail)
Wes Hardaker <wjhns1@hardakers.net> Thu, 04 April 2024 21:30 UTC
Return-Path: <wjhns1@hardakers.net>
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 5466EC18DB9B for <dd@ietfa.amsl.com>; Thu, 4 Apr 2024 14:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
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 syAeGEH0euCT for <dd@ietfa.amsl.com>; Thu, 4 Apr 2024 14:30:10 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (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 64D68C18DB94 for <dd@ietf.org>; Thu, 4 Apr 2024 14:30:05 -0700 (PDT)
Received: from localhost (unknown [10.0.0.9]) (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 mail.hardakers.net (Postfix) with ESMTPSA id 0441D20F86; Thu, 4 Apr 2024 14:30:05 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 0441D20F86
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1712266205; bh=8yvAassN0/J/2vZx4QOnxC0yZLc06/qQGEVMAW0HYTU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XEbz8qiZit+7q0pT6F9WYLAGwmrtfeWeqj9tH59ialWa6E54i/Rrf+Motuzxt46Gl 3sCrzz2yo2amJjESlXIzmbis8KOOBMhvWeZYryYxiCD1BwHZiMs7OgYmTRHjHrhbGR Ywarl6wO5HeWnM7Lod5TsubEGYorjD3LySCDAeKE=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>, "dd@ietf.org" <dd@ietf.org>
In-Reply-To: <DB7754B6-871E-41CE-BC25-71A62D626CE6@icann.org> (Paul Hoffman's message of "Sat, 23 Mar 2024 04:32:53 +0000")
References: <0521FB45-FC12-4297-8B17-41053137FF2E@icann.org> <581d56a5-b9c7-a301-264e-6b7282c07c16@redbarn.org> <DB7754B6-871E-41CE-BC25-71A62D626CE6@icann.org>
Date: Thu, 04 Apr 2024 14:30:04 -0700
Message-ID: <yblil0w95pf.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/C5i3ULGc8JRTurm83Pn1JN0Gulc>
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: Thu, 04 Apr 2024 21:30:14 -0000
Paul Hoffman <paul.hoffman@icann.org> writes: > 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? Multiple people have expressed concerns over ensuring backwards comparability. I'm sure many believe this is a "of course" type requirement, but it would be good to be explicit. So I added: It will include a concept of operations that describes how both current and future systems will interact in an Internet-wide interoperable way. -- Wes Hardaker USC/ISI
- [dd] Charter - objectives and scope Edward Lewis
- Re: [dd] Charter - objectives and scope (long tai… Paul Vixie
- Re: [dd] [Ext] Charter - objectives and scope (lo… Paul Hoffman
- Re: [dd] Charter - objectives and scope Jim Reid
- Re: [dd] Charter - objectives and scope Wes Hardaker
- Re: [dd] Charter - objectives and scope Tim Wicinski
- Re: [dd] Charter - objectives and scope Tim Wicinski
- Re: [dd] Charter - objectives and scope Geoff Huston
- Re: [dd] Charter - objectives and scope Jim Reid
- Re: [dd] Charter - objectives and scope tjw ietf
- Re: [dd] Charter - objectives and scope Wes Hardaker
- Re: [dd] [Ext] Charter - objectives and scope (lo… Paul Vixie
- Re: [dd] [Ext] Charter - objectives and scope (lo… Wes Hardaker