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

Petr Špaček <pspacek@isc.org> Wed, 23 April 2025 11:47 UTC

Return-Path: <pspacek@isc.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 3D9541FEF803 for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 04:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b="rCKzcNO1"; dkim=pass (1024-bit key) header.d=isc.org header.b="CaaQEF5i"
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 0UK9xqmPq7_O for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 04:47:34 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 09D811FEF7F4 for <dnsop@ietf.org>; Wed, 23 Apr 2025 04:47:33 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (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 did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 176EB3AB358; Wed, 23 Apr 2025 11:47:33 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org 176EB3AB358
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1745408853; cv=none; b=dBAZ4bd4ii++5e028UOBnBqxehjm6jTtFPD0t9CikTYtKppxdRfGcOIurddpMSzsfLt9WiUBmHHXZWUnO2zEQjr2x/tKs1Whc+oA3PotBs62LxFVgppzljH/OBCr2IlTcLYI8ysbrZPcJYaDEa52kSgSsP6fGttZYNQhg6b77Yc=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1745408853; c=relaxed/relaxed; bh=pMKK5upjOHH8Gb6hr90fo/MeKv8M/s5IDxWbpbYetWs=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=PVeU/ifcZyQKoERU/lhTpkqYZG6ui0JBp1gdWFoc/78UAiwJ08lKCVJInVInEpvGkLCasn9HngPqaLBtmcqNKe5IADApIlqafdsA3VhbOX727SYOTbMBttCGE/dTlXv0RPg/Q6GK31Gy/wm4xXxAV0WfpCenUa3STuvpqSeBaRw=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org 176EB3AB358
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1745408853; bh=RzcrMP5+2d5dC4au90NL1IR3QkLt6lnl+r3uK2zEaEM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=rCKzcNO1dqo9zEPMlMvi56k6tqk4zWp2+pPbcp28x5OBZWrHYGfr/tnkbaLFbGGuN AkP2LUwXlrqOUsb6UWyKj0sIAiS5f2VwU8DUZYChkxl5z9MX1sJOrk7Kxss9Q7xt4K 4H7sgdRYKpLzktTwbDG8Pr8fUJVYysWiAENccW/Y=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 11E28AE4DB1; Wed, 23 Apr 2025 11:47:33 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id E3BE0AE5848; Wed, 23 Apr 2025 11:47:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org E3BE0AE5848
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1745408852; bh=pMKK5upjOHH8Gb6hr90fo/MeKv8M/s5IDxWbpbYetWs=; h=Message-ID:Date:MIME-Version:To:From; b=CaaQEF5i7QrW/sTHDtZ22m0p/y/mCTcQScN60q2Oy1a6Y6kCZcTEHles7VKvqdq/b QRHG316za2lpOQJ7LCocHDqNsUiNKsv3UbaseRiSvD+78cvj4jxgFXKqXn8gbSAhP7 9xre9kVdKDEHU5Fagt/gi7UQrYFtE/gJGTFXRgFI=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id qb3G1NtVlQVp; Wed, 23 Apr 2025 11:47:32 +0000 (UTC)
Received: from [192.168.0.224] (ip-86-49-240-85.bb.vodafone.cz [86.49.240.85]) by zimbrang.isc.org (Postfix) with ESMTPSA id BAB28AE4DB1; Wed, 23 Apr 2025 11:47:31 +0000 (UTC)
Message-ID: <cc84f69c-c349-4d91-b942-80221b564a9b@isc.org>
Date: Wed, 23 Apr 2025 13:47:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Andrew McConachie <andrew@depht.com>
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> <89047B78-A2B1-43F2-A996-94DF1E90538A@depht.com>
From: Petr Špaček <pspacek@isc.org>
Content-Language: en-US
Autocrypt: addr=pspacek@isc.org; keydata= xsFNBF/OJ/4BEAC0jP/EShRZtcI9KmzVK4IoD/GEDtcaNEEQzPt05G8xtC0P4uteXUwW8jaB CdcKIKR4eUJw3wdXXScLNlyh0i+gm5mIvKPrBYNAMOGGnkbAmMQOt9Q+TyGeTSSGiAjfvd/N nYg7L/KjVbG0sp6pAWVORMpR0oChHflzKSjvJITCGdpwagxSffU2HeWrLN7ePES6gPbtZ8HY KHUqjWZQsXLkMFw4yj8ZXuGarLwdBMB7V/9YHVkatJPjTsP8ZE723rV18iLiMvBqh4XtReEP 0vGQgiHnLnKs+reDiFy0cSOG0lpUWVGI50znu/gBuZRtTAE0LfMa0oAYaq997Y4k+na6JvHK hhaZMy82cD4YUa/xNnUPMXJjkJOBV4ghz/58GiT32lj4rdccjQO4zlvtjltjp9MTOFbRNI+I FCf9bykANotR+2BzttYKuCcred+Q7+wSDp9FQDdpUOiGnzT8oQukOuqiEh3J8hinHPGhtovH V22D0cU6T/u9mzvYoULhExPvXZglCLEuM0dACtjVsoyDkFVnTTupaPVuORgoW7nyNl0wDrII ILBqUBwzCdhQpYnyARSjx0gWSG1AQBKkk5SHQBqi1RAYC38M59SkpH0IKj+SaZbUJnuqshXh UIbY1GMHbW/GDhz7pNQFFYm2S4OPUBcmh/0O0Osma151/HjF7wARAQABzR9QZXRyIMWgcGHE jWVrIDxwc3BhY2VrQGlzYy5vcmc+wsGXBBMBCABBAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4B AheAAhkBFiEEEVO2++xeDVoSYmDzq9WHzfBlga4FAmd7vqsFCQmG4S0ACgkQq9WHzfBlga5H dA//SNIJAXyYxpoIrQwtTSOded93J+CIYHd2ArxCsS+ZXzeaSkHcqp2QfneLY2yyiQwjeivu MfqEBIASNZ94T+4OjhEHAFaAUJQtYMY7qmH69Q5h1PQMk/HZX4QNEDB6dihjz4wunB2mRcac GnRziAQUAnlHSSZDU2EtTddmRYTCaeX9rU8O5ja0+qPBJket7PjS0yT8DQJF+aKRsQz17ywT 3rNR7NBgeKrkBud4/zE7VRoxSRCPkWkgixEog+AotZt22psgQTv+kWx89+7cTiFZaLMmtV6v Ws8QTpDRDM3hCJBCI6qk61k8SLuQ+5VuVWBM/ozoN1ON2J9anxVTrxhNsFM3RLHV/Qh9p/0y T4our7JxB6dsos3HtlRR2npXS1PMrrXt7ZnnfYao+9zbOrZHC7NRY3feaLhieLx1pKmdDRHT CAbqaGnqX22hYYemtYFzSAv7stCdqdncAEkZJy4HByjQwFVGn8A6rp7H1xV2LmlkNAMEoWrT GJ+wH8A+VA3qbZF9Ab8Ht2GRj3mQQ4h8NnRYjKyqecCQOI5Xmn4S61nQ9y+wOBUSTlAQ6a5n LmMpCVe2/D4pWFxpUxc1z8Hq+uEN95sPgbihiSdgBR50DRdqW57ulFHA9LKJ0AEnBtQfvVth qAkvG8iBYl+UpoX1xW+dbX2g6nI5Rbx8u+EojKXOwU0EX84n/gEQANARNXihDNc1fLNFZK5s O14Yg2TouK9eo9gGh4yLSrmZ3pjtnuJSpTWmGD4g0EYzhwWA/T+CqjUnrhsvzLQ1ECYVqLpM VqK2OJ9PhLRbx1ITd4SKO/0xvXFkUqDTIF6a5mUCXH5DzTQGSmJwcjoRv3ye+Z1lDzOKJ+Qr gDHM2WLGlSZAVGcUeD1S2Mp/FroNOjGzrFXsUhOBNMo8PSC4ap0ZgYeVBq5aiMaQex0r+uM4 45S1z5N2nkNRYlUARkfKirqQxJ4mtj5XPC/jtdaUiMzvnwcMmLAwPlDNYiU0kO5IqJFBdzmJ yjzomVk1zK9AYS/woeIxETs+s6o7qXtMGGIoMWr6pirpHk4Wgp4TS02BSTSmNzParrFxLpEU dFKq3M0IsBCVGvfNgWL2pKKQVq34fwuBhJFQAigR9B3O9mfaeejrqt73Crp0ng0+Q74+Llzj EIJLOHYTMISTJyxYzhMCQlgPkKoj+TSVkRzBZoYFkUt4OXvlFj73wkeqeF8Z1YWoOCIjwXH9 0u2lPEq0cRHHyK+KSeH1zQJ4xgj0QDGPmkvi81D13sRaaNu3uSfXEDrdYYc+TSZd2bVh2VCr xrcfzQ1uz9fsdC9NPdNd7/mHvcAaNc5e9IhNh67L54aMBkzlJi18d0sWXOOHkyLSvbHnC/OP wv7qCf69PUJmtoeHABEBAAHCwXwEGAEIACYCGwwWIQQRU7b77F4NWhJiYPOr1YfN8GWBrgUC Z3u+zwUJCYbhUQAKCRCr1YfN8GWBrmljD/45mvtqiWzATkikxkJjTlxfhJBGUFXUoPXqvo8l 8zACTTnn6/K7v1TcFmtSHtLqQiTGwwq1vGQSjEG+UFzdXohex9MTv+7JHr+fcQfxFtxYeVGn k9fSkRkIdtpUzuCnBC27VYbq5S+nk4+ophmjm7rFVWd4tz+XTFZkuHTRImWxbaF9EZ/fuWmm XaICw+lzGan9BteM1ZSLIjzSPd7LoG55SuoVtAV91J5oLPo6KDOzgPEffalm2LJo7+ZaAeW6 diQUXxQpvAAROR/l1D1DIIQ0OJOqv0QRFyHt/zBbKgWmGaTQqF5aNab4ukVAt0LMsCkCjA11 HhcUnUwrixHR4V8G3UlHTQsWReiXfPerv/BewTsPHSzIfmufNlrBDfS/uIYdwquZfhOSsK9Z DUJFkaHudJC6tRVQ5LBVFqjgtZDllpAj1cOG7WmlTwHblj/r2+LMpOVHApByNkehEOA2c4Bn tcQ/8qSeorJCyd1/5A5+bUFIfIAJbRz4Ja21JgH107oCMX3hsGEzMnuwplYTf9NP4Dq0FQhK vkXzdnDhhXef8nUqF7l32hj9x1BCLFZ4FFe6iuKD7Q9p83Ca1HDdxauIrsrXTsEr1bjg2o/A JXI4A3sUunmiIf/tu+3riXUhA10P1IG11yEQ4y9ogE6knvOraRBwZ8gvFT7J2YLXJrF5mQ==
In-Reply-To: <89047B78-A2B1-43F2-A996-94DF1E90538A@depht.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 2NKQTL5ASGWEXN4VANC7KBWVBBPWOCF4
X-Message-ID-Hash: 2NKQTL5ASGWEXN4VANC7KBWVBBPWOCF4
X-MailFrom: pspacek@isc.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: 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/dobvjm3UBge1qHJIrhYa0IQSNQA>
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 4/23/25 11:25, Andrew McConachie wrote:
> 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

:shrug: My interpretation of [2] is that term 'delegation' in this opera 
is firmly bound to 'application' process. From that I conjecture SUDN is 
not in scope. But IANAL :-)

-- 
Petr Špaček