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

Andrew McConachie <andrew@depht.com> Wed, 23 April 2025 09:26 UTC

Return-Path: <andrew@depht.com>
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 5DE001FDDA60 for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 02:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 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_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=depht.com
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 829nQZ-lVD-O for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 02:26:12 -0700 (PDT)
Received: from mout-b-112.mailbox.org (mout-b-112.mailbox.org [IPv6:2001:67c:2050:102:465::112]) (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 755021FDDA54 for <dnsop@ietf.org>; Wed, 23 Apr 2025 02:26:12 -0700 (PDT)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (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) (No client certificate requested) by mout-b-112.mailbox.org (Postfix) with ESMTPS id 4ZjDHh07jFzDtj1; Wed, 23 Apr 2025 11:26:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=depht.com; s=MBO0001; t=1745400368; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yG9w7oT2u+vV5ynI0XLL0D9dPa2k5ilg3DGa3wjixSA=; b=T5GFCaIQbjcXAQvBjTVXIe0Ts03fh3T+l7DhPHXtotSp1QEDy7mVFrHkH7Y0UIhVGWWft/ 0/6zDg1CCXvb9RWNecHQiY+MbbQw7ZwEJveZomJ74SCTnvCfaoZRxTTCw9VsuAP8l/CnaZ qBB+vaXJvXtVNt2+23wA01GMOit5ZxPFNI7NRLPbHyZHHURHIJLKmRdS46Snp20l32Eu8v xO1OdiWZ+j8ex2BU+9s4NajkWoXXlZdnvK56rzZ+7gRIFjLHaJF8p7bVjrRQwvneznMNdR tDYxQS0WEpFY8iJoCToDY04J77q2jYO1pstMgQBSfe8741Hc6ilCONoboxeTUA==
From: Andrew McConachie <andrew@depht.com>
To: Petr Špaček <pspacek@isc.org>
Date: Wed, 23 Apr 2025 11:25:54 +0200
Message-ID: <89047B78-A2B1-43F2-A996-94DF1E90538A@depht.com>
In-Reply-To: <3b5fb9e7-8a2b-420f-a2fb-dd6f6a0b88ae@isc.org>
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="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: HN3DWIBBKHIHWJL5BNEKJB7HZRCOLOJI
X-Message-ID-Hash: HN3DWIBBKHIHWJL5BNEKJB7HZRCOLOJI
X-MailFrom: andrew@depht.com
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: 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: 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/RUxXQZ-W9v7VA0XrdUqR7CHeLZw>
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>


On 22 Apr 2025, at 15:48, Petr Špaček wrote:

> On 4/22/25 13:26, Andrew McConachie wrote:
>> This is an overly creative interpretation of the Board’s 
>> resolution. It implicitly adds a modifier preceding “delegation” 
>> where none exists. The Board did not resolve to “reserve[s] 
>> .INTERNAL from [normal|secure] delegation”. They resolved to 
>> “reserve .INTERNAL from delegation”. The resolution could not be 
>> more clear.
>>
>> 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.
>>
>> My suggestion for the people in the “insecure delegation” camp is 
>> to petition the SSAC to write a document asking for a different name 
>> to be insecurely delegated. I see the benefits of both camps, so 
>> I’m not advocating for one or the other. But for .internal this 
>> really can’t be changed at this point.
>
> Just to clarify: Are you suggesting ICANN board cannot ever issue 
> another resolution on this matter?
>
I can’t speak for the Board, I can only read what they publish and 
interpret it.

 From the Board paper on the subject:
“The BTC [Board Technical Comittee] recommends that the Board reserve 
the string .INTERNAL permanently from
delegation in the DNS root zone.”[1]

Or the supporting text in the resolution:
“
What is the proposal being considered?

The Board is considering whether to reserve .INTERNAL from insertion in 
the DNS root zone permanently. Applicants of the next and subsequent 
gTLD application rounds will not be able to apply for the .INTERNAL 
top-level domain.
“[2]

There is also the Board’s interpretation of what SAC113 recommended:
“Along with recommending that the Board identify and reserve in 
perpetuity a single string at the
top-level of the DNS, SAC113 Section 4.1 ..“[1]

So we have at least 2 ‘permanently’s and 1 ‘in perpetuity’. To 
know definitively whether those words can constrain future Board 
resolutions would require a time machine, which we don’t have. So the 
best I can do is point at those words.

--Andrew

[1] 
https://itp.cdn.icann.org/en/files/board-meetings/briefing-materials/briefing-materials-1-29-07-2024-en.pdf
[2] 
https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en