Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-19

Paul Hoffman <paul.hoffman@icann.org> Wed, 14 December 2022 18:59 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B91C14CEFC for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 10:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 WAbFhuGzC2gm for <dnsop@ietfa.amsl.com>; Wed, 14 Dec 2022 10:59:26 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.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 B8C28C14F731 for <dnsop@ietf.org>; Wed, 14 Dec 2022 10:59:26 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa2.lax.icann.org (8.17.1.19/8.17.1.19) with ESMTPS id 2BEIxPrU019940 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Dec 2022 18:59:25 GMT
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.1118.20; Wed, 14 Dec 2022 10:59:24 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.1118.020; Wed, 14 Dec 2022 10:59:24 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: David Conrad <drc@virtualized.org>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] draft-ietf-dnsop-alt-tld-19
Thread-Index: AQHZD+4uTBzByLwhT02MRZm7DMT16w==
Date: Wed, 14 Dec 2022 18:59:24 +0000
Message-ID: <DA58288A-E4A6-4B54-A884-7DDC90FB6384@icann.org>
References: <20221214103710.zm6t5oshhnfwsm4g@werkbank> <9C02A5E7-3EA5-40EB-B265-4989D9961B6E@nohats.ca> <221b69b9-adea-d13a-2976-25bc9464621f@lear.ch> <595B77CC-433F-47FC-A604-ABA8FE1E8E43@rfc1035.com> <44ACB8E8-D4C5-40DB-972C-7AD0B1B8E099@virtualized.org>
In-Reply-To: <44ACB8E8-D4C5-40DB-972C-7AD0B1B8E099@virtualized.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="utf-8"
Content-ID: <2256D0A3827A274B92B5A21593C50337@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-14_09,2022-12-14_01,2022-06-22_01
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mVIWdmXLroHcO4sdtdAEldkO2KQ>
Subject: Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-19
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Dec 2022 18:59:27 -0000

On Dec 14, 2022, at 10:27 AM, David Conrad <drc@virtualized.org> wrote:
> 
> Hi,
> 
> On Dec 14, 2022, at 9:33 AM, Jim Reid <jim@rfc1035.com> wrote:
>> If these principles apply, why is the IETF bothering with .alt at all?
> 
> My impression has been the primary intent is to ensure .ALT is not allocated for DNS use

That is explicitly stated many places in the document.

> and secondarily, to try to curtail future discussions of this topic.

Curtail, but not prevent. That is, if the draft becomes an RFC and the label is permanently excluded from the global DNS root zone, if someone says "I want a new TLD that will be permanently excluded from the global root zone", an easy response is "show us why you cannot have an SLD under a name that is already permanently excluded from the global root zone". No one here has come up with a good answer to that question, so that such discussions could be reduced to one round trip (well, with possible retransmissions...).

> FWIW, if my impression is accurate, I’m confident the former will be successful (I’m sure the next round of gTLDs will disallow any strings the IETF comes up with, among others)

IANA already informs the parts of ICANN that allocates new TLDs of all TLDs in the SUDN registry, so your confidence is warranted.

> but am less confident about the latter.

I am more confident in the latter because the IETF will have a concrete answer written in a standard instead of "well, let's start from first principles again".

--Paul Hoffman