I am indeed confused by all the lawyering here. To me it is clear that the “no delegation” instruction from ICANN means they won’t delegate it and we can do what we think is correct with it for the intended use for which it has been reserved.
There is a specific reason why we want locally-served domains to have an insecure delegation to a black hole. Not delegating in this way doesn’t make much sense—it creates a situation where you have to disable DNSSEC to get the intended behavior, which seems like a really bad idea. Why go to all this trouble and then wind up with an outcome that doesn’t actually do what was intended? On Wed, Apr 23, 2025, at 4:47 AM, Petr Špaček wrote: > 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 >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
