[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

Kim Davies <kim.davies@iana.org> Wed, 23 April 2025 16:12 UTC

Return-Path: <kim.davies@iana.org>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D6EA320182AB for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 09:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FFcZgmkKmOC for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 09:12:44 -0700 (PDT)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [192.0.33.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 378EF2017C6C for <dnsop@ietf.org>; Wed, 23 Apr 2025 09:11:39 -0700 (PDT)
Received: from KIDA-9010.local (unknown [10.32.60.138]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp.lax.icann.org (Postfix) with ESMTPS id 8AD09E1880; Wed, 23 Apr 2025 16:11:38 +0000 (UTC)
Date: Wed, 23 Apr 2025 09:11:37 -0700
From: Kim Davies <kim.davies@iana.org>
To: Petr Spacek <pspacek@isc.org>
Message-ID: <aAkROWIJEYbHmB-f@KIDA-9010.local>
References: <m1u5h1G-0000LcC@stereo.hq.phicoh.net> <83666fd3-a51f-46e1-a5ac-0b9a46361480@desec.io> <49E3B1B6-E960-4A46-9C5D-2721FD57132D@depht.com> <3b5fb9e7-8a2b-420f-a2fb-dd6f6a0b88ae@isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3b5fb9e7-8a2b-420f-a2fb-dd6f6a0b88ae@isc.org>
Message-ID-Hash: SWS3AMKAAVWXMMYEF2SMDNNB7PWQKDRZ
X-Message-ID-Hash: SWS3AMKAAVWXMMYEF2SMDNNB7PWQKDRZ
X-MailFrom: kim.davies@iana.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Andrew McConachie <andrew@depht.com>, Peter Thomassen <peter=40desec.io@dmarc.ietf.org>, Philip Homburg <pch-dnsop-6@u-1.phicoh.com>, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/THZm0XmZGc8ZEybPkjDlxvtlxp4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi Petr,

Quoting Petr Spacek on Tuesday April 22, 2025:
> > 
> > The fact of the matter is that some people want "no delegation" and some
> > people want "insecure delegation". That ship has sailed, and we ended up
> > with "no delegation". DNSOP can´t change that.
> 
> Just to clarify: Are you suggesting ICANN board cannot ever issue another
> resolution on this matter?

I don't think that's true. We have a situation where SSAC specifically
stated the domain should not be delegated in the root zone, it is a
constraint that the ICANN Board codified in accepting SSAC's advice, and
thus that is the constraint we have today.

I have no insight into SSAC's deliberations but I think a reasonable
take is that the prohibition was intended purely to provide assurance
that name collisions would be avoided between private-use and labels
that may be created inside an actual delegation from the root. A
specialized delegation purely for a technical enablement reason (e.g.
breaking the chain of trust) that is consistent with the intent may
still be deemed consistent with the goal of SSAC's restriction. If that
is the case I think superseding advice could be provided to clarify that
aspect and adopted if there was a consensus that this made sense.

kim