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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
