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

From: Roy Arends <[email-masked]>
Date: Sat, 2 May 2020 14:09:18 +0000

Hi,

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. 

Warmly,

Roy

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 May 2020 21:18:17 -0400

Hi Roy,

> 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…

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

---

From: "John Levine" <[email-masked]>
Date: 5 May 2020 22:57:34 -0400

In article <[email-masked]> you write:
>> 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.

I also think it's an improvement, and concur with Joe's advice not to tell IANA to do anything
since they're already doing it.

R's,
John

PS: I don't suppose there's any chance that the IETF could mount an
expedition to Western Sahara or Palmyra atoll and claim .EH or .UM?

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 7 May 2020 13:40:42 -0500

> https://www.ietf.org/id/draft-arends-private-use-tld-01.txt

While I do not have hard facts but just a gut feeling, I would feel
safer if "xn" is excluded from the possible list of private labels to be
used in the DNS, as it is used for prefix of IDNs.

Some, probably buggy, software could match on "xn" instead of "xn--" as
prefix to search for IDNs, and hence having "example.xn" could lead to
problems.

> 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…

Thanks for the new draft version, the new content is useful indeed.

-- 
Patrick Mevzek

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 May 2020 11:45:44 +0000

Hi Joe, thanks for your thoughtful comments.

> On 6 May 2020, at 02:18, Joe Abley <[email-masked]> wrote:
> 
> Hi Roy,
> 

That is good advice. I’ll take it. This will be reflected in version -02, which will drop shortly.

> 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 whi…

Good point, I’ll take this into consideration. I will have new and improved wording in version -02.

Roy

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 May 2020 12:54:16 +0100

Hi John,

> On 6 May 2020, at 03:57, John Levine <[email-masked]> wrote:
> 

Thanks. I’ll reflect this in version .02

> expedition to Western Sahara or Palmyra atoll and claim .EH or .UM?

The delegation of “.eh” and “.um” has been discussed in the past and more information can be found here:

“.eh”: https://www.icann.org/resources/board-material/prelim-report-2007-10-16-en
“.um”: https://www.iana.org/reports/2007/um-report-10jan2007.html

Warmly,

Roy 

> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 May 2020 12:57:08 +0100

Hi Partick

> On 7 May 2020, at 19:40, Patrick Mevzek <[email-masked]> wrote:
> 

That is a good point. I won’t go as far as excluding it, but I will add a warning.

> prefix to search for IDNs, and hence having "example.xn" could lead to

I agree.

> Thanks for the new draft version, the new content is useful indeed.

Thanks Patrick.

Warmly,

Roy

---

From: Petr Špaček <[email-masked]>
Date: Tue, 26 May 2020 17:06:26 +0200

> 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…

I think this is clever hack and should be documented, thank you!

Personally I'm bit torn because I've spent my whole professional career explaining people how bad idea it is to use non-delegated/non-unique names so I would really like to people from overusing this...

Would you be willing to add at least one paragraph with caution? Something along lines "private TLD should be used as _option of last resort_", or more verbose "these special TLDs should be used only when other options, e.g. private subtree under a properly delegated name, were considered and refused."

Thank you.

-- 
Petr Špaček  @  CZ.NIC

---

From: Roy Arends <[email-masked]>
Date: Tue, 26 May 2020 16:00:21 +0000

> On 26 May 2020, at 16:06, Petr Špaček <[email-masked]> wrote:
> 

Any time, thanks!

> Would you be willing to add at least one paragraph with caution? Something along lines "private TLD should be used as _option of last resort_", or more verbose "these special TLDs should be used on…

I’m not sure about ranking different methods of deployment as each has its own little idiosyncrasies that may be useful to the deployment scenario.

How about I add a section that details the additional complexities and adds caution in using this specific method, such as “Using a private use top level domain is not ‘more secure’ or ‘more private’ than using a public domain; it requires additional complexity in resolving and signing, etc, etc”

Does that work for you?

Thanks,

Roy

---

From: Petr Špaček <[email-masked]>
Date: Tue, 26 May 2020 18:05:35 +0200

> How about I add a section that details the additional complexities and adds caution in using this specific method, such as “Using a private use top level domain is not ‘more secure’ or ‘more privat…

Yes, that would be ideal, I just did not want to delve into details so much.

Basically the message I wanted to convey is "usually it is less work and more robust to use a delegated name instead of your own TLD". If you want to add longer explanation I'm happy to review it!

-- 
Petr Špaček  @  CZ.NIC