Re: [DNSOP] new version submitted for draft-arends-private-use-tld

[Joe Abley <[e-mail]>]

Hi Roy,

On 2 May 2020, at 10:09, Roy Arends <[e-mail]> wrote:

> Ed and I just submitted a new version of our private-use TLD draft.
> 
> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt
> 
> This draft has substantial more information than the first draft. It explains that a private-use namespace does not exist, why it is needed, and how a namespace aligned with the user-assigned alpha-2 code elements in the ISO-3166-1 standard can be used as private-use namespace.
> 
> It contains plenty of examples of how user-assigned code elements are used in the field, including other ISO standards, the UN, UNICODE, CAB/forum, and the IETF itself.
> 
> This new version came about after fruitful discussions with peers inside and outside the IETF. Most discussions were productive. This has lead to the removal of the advice/example to use ZZ, as it was distracting from the point of the draft: these two-letter top level domains are available for private-use.

I have read this document and I like it.

There have been other proposals to make recommendations like this in the past that I have not been very enthusiastic about. The reason I like this draft-arends proposal more is that it neatly avoids the problem of who gets to make policy about this stuff by pointing out that suitable policies already exist and that hence the problem is already solved.

I also like the happy accident that the names on the user-assigned list are all pretty much equally arbitrary in every language in which US-ASCII labels have the potential to have semantic meaning. This seems better than choosing a label that is a recognisable word in some languages but not others.

I have two suggestions for the document. I have some doubt about the second suggestion, but the first one seems definitely great. :-)

1. While this document currently includes instructions to the IANA that could be viewed as specifying TLD naming policy, it might be possible to avoid that particular hidden foot-operated explosive device with some re-wording.

This document could simply make the observation that since existing ccTLD label policy is to defer completely to ISO-3166 alpha-2 (citation needed) and since ISO-3166 alpha-2 includes user-assigned codes that will never be assigned to a territory (citation needed) then it is consistent with existing policies that those user-assigned codes will never be delegated from the root zone in the DNS and, for that reason, will never give rise to collisions with any future new TLD.

That would leave this document simply as a clarifying description of existing policy, instead of appearing to have ambitions to change or specify policy in the root zone (which is the kind of thing that ICANN is also plausibly responsible for). The consequence of that small change might be (is, I think) to make this document completely uncontroversial whilst preserving the core advice. No worm containment failure required.

2. The document stops short of making a clear recommendation in section 5. While the decision to anchor a private namespace in something that looks like a TLD is not necessarily the only plausible answer (I could anchor such a namespace at a domain that I reserve through normal domain registration, for example) the document *could* say "for applications that require a private namespace anchored at something that looks like a TLD, our recommendation is to do this".

It is possible, of course, that a clear recommendation might have an XKCD-927 effect (which would be unfortunate but perhaps tolerable) or no effect whatsoever (which at least seems benign, but which is also a bit useless). However, if the document is not going to make any clear recommendation, I'm not sure what the point of publishing it is.


Joe