Subject: [DNSOP] on private use TLDS

From: Roy Arends <[email-masked]>
Date: Tue, 26 Nov 2019 11:18:46 +0100

“ZZ” was used in my presentation as an example. Since this bikeshedding is siphoning attention from the important part of the discussion, I’ll try to re-focus on the question here:

"Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned range as top level domains for my own private use?"

1) RFC1591: Selection of 3166 was made with knowledge that ISO has a procedure for determining which entities should be and should not be on that list.
(Note of the word “entities” and “procedure”)

2) From the ISO 3166-1 Alpha-2 standard, on the construction of an alpha-2 code: "42 alpha-2 code elements are not used in the ISO 3166. Users sometimes need to extend or alter the use of country code elements for special purposes.” 

It is my understanding that the ISO3166 Maintenance Agency can not re-assign codes from the User Assigned range. This needs an action from ISO TC46. 

3) Jaap Akkerhuis writes:

> Shane Kerr writes:
> 
>> Certainly I have 
>> made heavy use of .Q* and .X* in my own testing, with the assumption 
>> that these would never be assigned (and yes, there is .TEST but 
>> sometimes you need more than one one TLD).
> 
> Yes, that is a perfectly legit use. 

For those who are not aware, Jaap is a member of the ISO-3166 Maintenance Agency and a Category C liaison for ICANN to TC46/WG2 [1].  Therefore it is likely that he knows these things. Note that the IETF has its own liaison to ISO-TC46 (John Klensin) [2]. Conversely, I (Roy Arends) make no representation for ICANN.

4) The XN— ACE prefix for internationalized domains was chosen by IANA, because "The use of ISO 3166-1 user-assigned elements removes the possibility that the code will duplicate a present or future ccTLD code.” [3]

5) ISO, ICAO, IATA, WIPO, UNLOCODE, UNICODE, Worldbank, Interpol, CABforum, and the IETF  make use of these User Assigned codes as intended by ISO3166. These codes have been assigned for different purposes that only have meaning in the local context of their organization and their constituencies.

6) It is highly unlikely that any of the 42 codes will ever appear in the root zone (especially following Postel’s Law: Be conservative in what you do), as we follow RFC1591. 

When a private space name is chosen, the 42 top-level labels are safe to use, as it is highly unlikely to collide with any top-level domain now or in the future. 

Please see the presentation during DNSOP at IETF106 here: 
https://youtu.be/yUO1J9s8BdE?t=5042

Follow the slides here:
https://datatracker.ietf.org/meeting/106/materials/slides-106-dnsop-sessa-draft-arends-private-use-tld

Warmly,

Roy Arends
Not representing ICANN.

[1] https://www.iso.org/organization/567449.html
[2] https://ietf.org/about/liaisons/
[3] https://psg.com/~randy/lists/iesg/2003/msg01081.html

---

From: Jim Reid <[email-masked]>
Date: Tue, 26 Nov 2019 10:46:13 +0000

> On 26 Nov 2019, at 10:18, Roy Arends <[email-masked]> wrote:
> 
> ...

It would be prudent to assume that there is a possibility, no matter how remote, that codes from the User Assigned range could get re-assigned one day. Whoever made the current policy could well change it.*

So if your idea goes forward, I think there needs to be some text which explains this. ie User Assigned 3166 codes *might* be OK for private use today; that list of code points is subject to change even if that's highly unlikely; plan accordingly just in case your private use two-letter code gets repurposed.

* I read documents in the late 90s, albeit not from SDOs, telling companies to anchor their internal name space under .corp because it was impossible for that TLD to ever exist in the public Internet. This was before ICANN was formed.

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 26 Nov 2019 11:53:42 +0100

> On Nov 26, 2019, at 11:46 AM, Jim Reid <[email-masked]> wrote:
> It would be prudent to assume that there is a possibility, no matter how remote, that codes from the User Assigned range could get re-assigned one day. Whoever made the current policy could well change it.

I think that once a range has been delegated, it’s just imprudent and counter to good sense to make any assertions whatsoever about what the delegate will do with it.  If two-letter TLDs are delegated to ISO3166, then just say so.  Say that whether or not end-users can use any of them for private purposes is at the discretion of ISO3166, and make no further assertions about it, since, as Jim points out, things can always change, and then you have misinformation floating about.

This doesn’t seem like a complicated principle to me, and I’m having a really hard time seeing what benefit could ever come from violating it.

If you delegate, you delegate.  If you don’t delegate, you don’t delegate.  Mixing the two is chaos.  The whole point of delegation is to scale without chaos.

                                -Bill

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Nov 2019 06:52:25 -0500

It might be worth clarifying what the actual scope of this proposal is.  I think that the idea is to say “look, if you want to use a private name, these names are known to be safe.”   It’s not to say “the IETF hereby declares that the following names are safe,” but rather “the IETF is reporting that these names have been declared safe by this other SDO.”

The point of making this recommendation is that we know that people will have reasons to privately use domains that have not been allocated to them out of the global namespace, and we’ve seen the problems that such private allocations cause when they are done in an unsafe manner.  The advice here is on how to avoid making that mistake.   It’s not a TLD allocation by IETF: those TLDs are already effectively allocated.

Is that about right?

---

From: David Conrad <[email-masked]>
Date: Tue, 26 Nov 2019 13:12:49 +0100

> The point of making this recommendation is that we know that people will have reasons to privately use domains that have not been allocated to them out of the global namespace, and we’ve seen the p…

Exactly (at least from my perspective).

Regards,
-drc

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 26 Nov 2019 12:16:54 -0500

On Tue, 26 Nov 2019 at 05:19, Roy Arends <[email-masked]> wrote:

> “ZZ” was used in my presentation as an example. Since this bikeshedding is
> siphoning attention from the important part of the discussion, I’ll try to
> re-focus on the question here:
>
> "Is it safe to use ISO3166-1 Alpha-2 code elements from the User Assigned
> range as top level domains for my own private use?"
>

Thanks for the context, Roy.  Speaking as someone who was not at the IETF
meeting this week, I found the earlier thread confusing.  But, it looks
like the assumed context of bringing up "what can we use this for" as "can
we assign this string in an RFC?" was correct.

It seems like reassignment of anything in the User Assigned range is
unlikely, however that is the purview of the iSO 3166 maintenance agency,
and not the IETF.  However unlikely it is, we cannot be absolutely certain
they will never reassign those, and so we should not include them in any
standard (note the lower-case) published by the IETF.  Even if the IETF is
just cut & pasting their current advice, I think it's unwise.

I'm also persuaded by Bill's argument that the IETF has already stated that
ISO 3166 has control over that bit of the namespace, and trying to take
back part of it is confusing, bad form, and risky.

Even though they're not specifically proposed, only mentioned in passing,
I'd also like to point out that the referenced potential uses of things
like XH instead of home.arpa. is even more risky, because that fixes that
string for a specific use, even if it's private.  Using XH as an example,
if that had been chosen it would run the risk of colliding with some
legitimate use of XH already being used by a User.. if that user then also
needed to interoperate with Homenet technologies they'd be hosed.

I think, instead of an RFC, what you really want is a Best Current
Practices document, outside of the IETF, that is simply a redirect to the
current ISO 3166 document.  Instead of DNSOP, I'd suggest you have a chat
with one or more  of the BCOP efforts at the NOGs.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Nov 2019 17:35:41 +0000

On Nov 26, 2019, at 9:16 AM, Matthew Pounsett <[email-masked]> wrote:
> I'm also persuaded by Bill's argument that the IETF has already stated that ISO 3166 has control over that bit of the namespace, and trying to take back part of it is confusing, bad form, and risky.

For those who read the draft, ypu'll see that "trying to take back part of it" is not there. The same was made clear in the presentation to the WG. "If you want a private name, here's one to consider; ones like it are already being used as private names in dozens of other contexts" is far from "taking" anything.

--Paul Hoffman

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 26 Nov 2019 12:39:44 -0500

On Tue, 26 Nov 2019 at 12:35, Paul Hoffman <[email-masked]> wrote:

> > I'm also persuaded by Bill's argument that the IETF has already stated
> that ISO 3166 has control over that bit of the namespace, and trying to
> take back part of it is confusing, bad form, and risky.
>
> For those who read the draft, ypu'll see that "trying to take back part of
> it" is not there. The same was made clear in the presentation to the WG.
> "If you want a private name, here's one to consider; ones like it are
> already being used as private names in dozens of other contexts" is far
> from "taking" anything.
>

It's still the IETF stating that it's safe to use for that purpose, which
is no longer the purview of the IETF having delegated that responsibility
to ISO3166.  That is taking back authority over that name.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Nov 2019 10:00:53 -0800

On Tue, Nov 26, 2019 at 9:40 AM Matthew Pounsett <[email-masked]> wrote:

>> For those who read the draft, ypu'll see that "trying to take back part
>> of it" is not there. The same was made clear in the presentation to the WG.

No, this is an example how, in some contexts, a double negative is not
necessarily the same as a positive.

What the proposal is saying is, that the IETF is saying you can't ever use
these 42 labels for global use, that they are only ever possible to use in
strictly local context.
And it is saying, that because ISO 3166 has effectively marked them in a
method similar to RFC 6761, there is no reason to expect that to ever
change, and that if you need to have a pseudo-TLD for private use (strictly
local scope), these would be advisable choices.

And, just the way RFC 1918 works, using these for any purpose other than
local scope is just a bad idea.

However, it is possible for local scope functionality in protocols, to
actually require standardization for interoperation, with the caveat of
"local scope" made very clear, this proposal is actually really important.

I expect to refer to this proposed item in my own proposed work for doing
things related to DNS resolver discovery, where the interoperability inside
RFC 1918 addressed networks (i.e. explicitly local scope) needs a
corresponding local scope namespace.

So, it's a particular corner case, where currently the IETF has no
previously non-delegated namespace it can work with, and where things under
'.arpa' would be poor candidates (because .arpa is a real TLD, etc.).

IMHO, of course.

Brian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 26 Nov 2019 18:15:09 +0000

On Nov 26, 2019, at 9:39 AM, Matthew Pounsett <[email-masked]> wrote:
> It's still the IETF stating that it's safe to use for that purpose, which is no longer the purview of the IETF having delegated that responsibility to ISO3166.  That is taking back authority over that name.  

The term "safe" doesn't appear in draft-arends-private-use-tld. If you have words you would prefer there to make it clearer that what is being proposed is just "If you want a private name, here's one to consider; ones like it are already being used as private names in dozens of other contexts", I bet Roy would consider adding it.

Bigger picture: this WG often gets tied between "we want to be the place recommending best practices for private naming" and "we disagree what settings to put on these three knobs when we are talking about private naming". I would like to think that it is not impossible for this to be resolved, because there is no better set of experienced people to deal with the thorny issue of private naming.

--Paul Hoffman

---

From: Petr Špaček <[email-masked]>
Date: Wed, 27 Nov 2019 12:52:08 +0100

> Bigger picture: this WG often gets tied between "we want to be the place recommending best practices for private naming" and "we disagree what settings to put on these three knobs when we are talki…

I can see two overlaping problems:

1. (missing) Recommendation for running local-only DNS subtrees (like BIND views etc.).
This *also* applies to unique subdomains like "example.office.nic.cz" which cannot be queried from the Internet.
The only attempt I remember is https://datatracker.ietf.org/doc/draft-krishnaswamy-dnsop-dnssec-split-view/ .

2. Advice how (not) to select a non-unique domain name + explanation of consequences for both options.

I guess that uniqueness or non-uniqueness of the name will affect first document so much that it is pointless to give advice for (2) without tackling (1) first.

My two halers.

-- 
Petr Špaček  @  CZ.NIC

---

From: Doug Barton <[email-masked]>
Date: Wed, 27 Nov 2019 20:39:38 -0800

On 11/26/19 9:16 AM, Matthew Pounsett wrote:
> 
> 
> On Tue, 26 Nov 2019 at 05:19, Roy Arends <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     “ZZ” was used in my presentation as an example. Since this
>     bikeshedding is siphoning attention from the important part of the
>     discussion, I’ll try to re-focus on the question here:
> 
>     "Is it safe to use ISO3166-1 Alpha-2 code elements from the User
>     Assigned range as top level domains for my own private use?"
> 
> 
> Thanks for the context, Roy.  Speaking as someone who was not at the 
> IETF meeting this week, I found the earlier thread confusing.  But, it 
> looks like the assumed context of bringing up "what can we use this for" 
> as "can we assign this string in an RFC?" was correct.
> 
> unlikely, however that is the purview of the iSO 3166 maintenance 
> agency, and not the IETF.  However unlikely it is, we cannot be 
> absolutely certain they will never reassign those, and so we should not 
> include them in any standard (note the lower-case) published by the 
> IETF.  Even if the IETF is just cut & pasting their current advice, I 
> think it's unwise.
> 
> Even though they're not specifically proposed, only mentioned in 
> passing, I'd also like to point out that the referenced potential uses 
> of things like XH instead of home.arpa. is even more risky, because that 
> fixes that string for a specific use, even if it's private.  Using XH as 
> an example, if that had been chosen it would run the risk of colliding 
> with some legitimate use of XH already being used by a User... if that 
> user then also needed to interoperate with Homenet technologies they'd 
> be hosed.
> 
> Practices document, outside of the IETF, that is simply a redirect to 
> the current ISO 3166 document.  Instead of DNSOP, I'd suggest you have a 
> chat with one or more  of the BCOP efforts at the NOGs.

I agree with Matt, Bill Woodcock, Steve Crocker, and others that have 
expressed that we should stay out of ISO's sandbox. Whatever the rules 
are today, they can change, and poaching their stuff for our purposes is 
bad form (and yes, I feel that poaching is what is being proposed, in 
spite of the arguments to the contrary).

ICANN has already said that it's not going to ever delegate CORP, HOME, 
or MAIL. 
(https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf 
Section 3.2) IMO it would be useful for the IETF, with ICANN's 
cooperation, to codify that (if it hasn't been done already). I also 
think INTERNAL as a private-use TLD is a good idea, and should be 
included in the same doc. It's also useful to mention the distinction 
between using something temporarily for testing, and building 
infrastructure around it. If someone wants to put together a document 
like that I would be happy to offer support, review, and/or 
contributions if so desired.

So what's the harm? Aside from the PR issues related to poaching ISO 
3166 stuff, I have personally been involved a few times in unwinding the 
giant mess created when clients decided that they were going to use a 
string as an internal TLD, and then subsequently it got delegated 
publicly. This creates serious problems, is difficult to debug, and 
expensive to fix. The advice we've given folks for decades is, "Don't 
take it upon yourself to grab something that doesn't belong to you and 
build your network on it." In my view, that's what is being recommended 
here; and having seen the damage it causes first hand, I cannot support 
the proposal.

Doug

-- 
Since I haven't been involved in the group for a while here is a 
mini-resume for those that don't know me, offered with no small amount 
of embarrassment:
DNS and domain name work for 25 years, 20+ of doing it for a living
Formerly a regular IETF participant
Former GM of the IANA
Former consultant in the DNS/DHCP/IPAM and domain name spaces
Currently managing the domain name portfolio for a Fortune 100 corporation

That said, all views are my own, and are worth exactly what you paid for 
them.  :)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Nov 2019 07:15:23 -0500

So let me get this straight: you want us to stay out of ISO’s sandbox by jumping right in to ICANN’s? ICANN has not promised never to delegate those domains, whereas ISO effectively has, so your reasoning doesn’t make sense. 

> On Nov 27, 2019, at 23:39, Doug Barton <[email-masked]> wrote:
> 
>> On Tue, 26 Nov 2019 at 05:19, Roy Arends <[email-masked] <mailto:[email-masked]>> wrote:
>> Thanks for the context, Roy.  Speaking as someone who was not at the IETF meeting this week, I found the earlier thread confusing.  But, it looks like the assumed context of bringing up "what can we use this for" as "can we assign this string in an RFC?" was correct.
>> It seems like reassignment of anything in the User Assigned range is unlikely, however that is the purview of the iSO 3166 maintenance agency, and not the IETF.  However unlikely it is, we cannot be absolutely certain they will never reassign those, and so we should not include them in any standard (note the lower-case) published by the IETF.  Even if the IETF is just cut & pasting their current advice, I think it's unwise.
>> Even though they're not specifically proposed, only mentioned in passing, I'd also like to point out that the referenced potential uses of things like XH instead of home.arpa. is even more risky, because that fixes that string for a specific use, even if it's private.  Using XH as an example, if that had been chosen it would run the risk of colliding with some legitimate use of XH already being used by a User... if that user then also needed to interoperate with Homenet technologies they'd be hosed.
>> I think, instead of an RFC, what you really want is a Best Current Practices document, outside of the IETF, that is simply a redirect to the current ISO 3166 document.  Instead of DNSOP, I'd suggest you have a chat with one or more  of the BCOP efforts at the NOGs.
> 
> I agree with Matt, Bill Woodcock, Steve Crocker, and others that have expressed that we should stay out of ISO's sandbox. Whatever the rules are today, they can change, and poaching their stuff for our purposes is bad form (and yes, I feel that poaching is what is being proposed, in spite of the arguments to the contrary).
> 
> ICANN has already said that it's not going to ever delegate CORP, HOME, or MAIL. (https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf Section 3.2) IMO it would be useful for the IETF, with ICANN's cooperation, to codify that (if it hasn't been done already). I also think INTERNAL as a private-use TLD is a good idea, and should be included in the same doc. It's also useful to mention the distinction between using something temporarily for testing, and building infrastructure around it. If someone wants to put together a document like that I would be happy to offer support, review, and/or contributions if so desired.
> 
> So what's the harm? Aside from the PR issues related to poaching ISO 3166 stuff, I have personally been involved a few times in unwinding the giant mess created when clients decided that they were going to use a string as an internal TLD, and then subsequently it got delegated publicly. This creates serious problems, is difficult to debug, and expensive to fix. The advice we've given folks for decades is, "Don't take it upon yourself to grab something that doesn't belong to you and build your network on it." In my view, that's what is being recommended here; and having seen the damage it causes first hand, I cannot support the proposal.
> 
> Doug
> 
> -- 
> Since I haven't been involved in the group for a while here is a mini-resume for those that don't know me, offered with no small amount of embarrassment:
> That said, all views are my own, and are worth exactly what you paid for them.  :)
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 28 Nov 2019 11:55:06 -0500

>spite of the arguments to the contrary).

I don't see how relying on ISO's advice is poaching.  They say:

  If users need code elements to represent country names not included in
  ISO 3166-1, the series of letters AA, QM to QZ, XA to XZ, and ZZ, and
  the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ
  respectively, and the series of numbers 900 to 999 are available.
  NOTE: Please be advised that the above series of codes are not
  universal, those code elements are not compatible between different
  entities.

That note tells me they're like RFC 1918 IP addresses, use them in your
organization but be aware that other organizations will use them differently.

>ICANN has already said that it's not going to ever delegate CORP, HOME, 

They said indefinitely defer which is not the same thing at all.  If
the facts change, e.g., the number of root queries for one of them
drops significantly, I'm sure they'll revisit them.  

The IETF has already decided to stay out of the home/corp/mail
argument, reasonably concluding that RFC 6761 are for names that are
technically special which these are not.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Nov 2019 18:25:39 +0000

On Thursday, 28 November 2019 12:15:23 UTC Ted Lemon wrote:
> So let me get this straight: you want us to stay out of ISO’s sandbox by
> jumping right in to ICANN’s? ICANN has not promised never to delegate those
> domains, whereas ISO effectively has, so your reasoning doesn’t make sense.

ISO has other constituencies beyond IANA, and while they have promised not to 
"delegate" certain names, their private-use rules allow those names to be used 
by someone other than IANA.

IANA can be instructed by IETF to never delegate certain TLDs (like .ZZZ).

noting, i would prefer stronger mnemonic naming for this, like .PRIVATE

-- 
Paul

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 13:30:28 -0800

The IETF and ICANN share a sandbox on many topics, including the root 
zone. (But of course you already knew that.) And if you don't think 
ICANN has promised to not delegate HOME, CORP, and MAIL; you didn't read 
the reference I provided. Or, if you did read it, and still have 
concerns, that is that much more reason to work with them on a draft 
that memorializes it.

Meanwhile, as many others have pointed out, and your side of the 
argument continues to ignore, ISO can choose to change those rules. And 
if they do, we would have no recourse. OTOH, we do have a means of 
working with ICANN to codify certain TLDs for private use. Given those 
facts alone I'm frankly astonished that anyone would argue for any other 
course of action.

Doug

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 13:38:31 -0800

> I don't see how relying on ISO's advice is poaching.  They say:

You, like Ted, are ignoring the fact that ISO can choose to change those 
rules.

> They said indefinitely defer which is not the same thing at all. 

Ok, so if you think there is a risk here, then it should be mitigated by 
working together with ICANN on a draft that codifies that they will 
never be delegated. Since there is apparently a need for additional such 
names (like INTERNAL) then they should be included.

Other than some sort of gratuitous "we hate ICANN so we don't want to 
work with them" thing, it's not at all clear to me why we wouldn't want 
to lock the necessary resources down in cooperation with the only other 
entity that has anything to say about what happens in the root zone.

> argument

The IETF can change its mind too.  :)

Seriously, there is obviously a need to have private-use TLDs that we 
can guarantee will never be part of the public root zone. So let's make 
that happen, in a way that we can be sure will never be pulled out from 
under us.

Doug

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Nov 2019 22:15:03 +0000

On Nov 28, 2019, at 1:30 PM, Doug Barton <[email-masked]> wrote:
> The IETF and ICANN share a sandbox on many topics, including the root zone. (But of course you already knew that.) And if you don't think ICANN has promised to not delegate HOME, CORP, and MAIL; you didn't read the reference I provided. Or, if you did read it, and still have concerns, that is that much more reason to work with them on a draft that memorializes it.

That document (https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf) doesn't have such a promise. And, yes, I did read it. (Disclaimer: I also wrote it.)

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 Nov 2019 17:20:09 -0500

Hi Doug,

I am not suggesting that you are wrong in your final paragraph, and I am not philosophically opposed to reserving a label in the root zone for private use, somehow analogously to RFC1918, but I think it's worth challenging how obvious this really is. (Yours is just a convenient hook to hang this reply to; it's not really directed just at you.)

I do think the semantic meaning of the label is worth thinking about, and I am wary of particular scripts or languages being chosen arbitrarily. I realise "internal" and "private" are sensible labels to use for this kind of thing if you are English-speaking and used to reading Latin script; I don't know that it's reasonable not to care that they might not be sensible in other contexts. This to me is a much more important conversation than bikeshedding about what regulatory agency has said what about what.

It's also perhaps worth mentioning that the mechanics of how to provision (or not provision) such a name with regard to DNSSEC validation by various elements of the wider ecosystem have been a matter of some debate in other venues. I doubt that dnsop is immune to that. I won't fulfil that epectation by saying more in this message. :-)

So, on the subject of how obvious it is that we need to reserve a top-level label for private namespaces,

- has the advice to anchor a private namespace in a registered domain in the private namespace really been received and judged to be insufficient? Or has it just not been received? Could such advice be delivered in a more effective way?

- does the growth in observed query traffic for names with non-existant top-level labels really support the idea that squatting on arbitrary undelegated TLDs is on the rise? Is it possible there are other effects? Have we normalised the observed growth against other known causes of growth? If this phenomenon is actually becoming less common, does it need a solution beyond "wait"?

- what are the possible negative effects of providing a TLD label for use in private namespaces? We know that in the addressing realm, RFC 1918 and similar private-use addresses lead to collisions during M&A, interconnections, etc. Perhaps these are reasonable trade-offs for addresses. Is the same true for names?

- does promoting a single anchor for private namespaces concentrate traffic that leaks from those internal contexts to the Internet's DNS? If the leakage of queries that are intended to be private represents a security concern, does the concentration of targets for that traffic on the Internet make the security concern worse?

For the record, I don't personally see any enormous harm from standardising something like Warren's ".internal" (or Roy's ".zzz", to make it clear that I'm not talking about the specific label). But I do think questions like the ones I mentioned are worth putting some effort into answering.

Perhaps I've missed some elegant and robust analysis, but to date all I've seen is "nobody likes the advice to register MYCO.COM (http://MYCO.COM) and use that, so obviously we need to do something". If that's really where we are, it seems like it would be comforting to be able to say so more convincingly.

Joe

> On Thursday, Nov 28, 2019 at 16:38, Doug Barton <[email-masked] (mailto:[email-masked])> wrote:

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 14:29:25 -0800

> That document (https://www.icann.org/en/system/files/files/name-collision-mitigation-01aug14-en.pdf) doesn't have such a promise. And, yes, I did read it. (Disclaimer: I also wrote it.)

Thanks for clarifying. All the more reason to codify it in a draft.

Doug

---

From: Roy Arends <[email-masked]>
Date: Thu, 28 Nov 2019 23:42:22 +0100

> On 28 Nov 2019, at 22:30, Doug Barton <[email-masked]> wrote:
> 
> And if you don't think ICANN has promised to not delegate HOME, CORP, and MAIL; you didn't read the reference I provided. 

From section 3.2: "The deferral is not guaranteed to be forever”. That doesn’t read like a promise to not delegate HOME, CORP, and MAIL.

> Meanwhile, as many others have pointed out, and your side of the argument continues to ignore, ISO can choose to change those rules.

It is not that simple. While it is in ISO’s remit to change a category from User Assigned to another category, it is extremely improbable. A change to categories would force many active users of the standard such as ICAO, IATA, WIPO, UNLOCODE, UNICODE, Worldbank, Interpol, CABforum, and even the IETF and ISO itself to rename internally used strings. From their own ISO-3166 standard: "the ISO 3166/MA shall endeavour to maintain stability in the list of code elements.” 

As an example, say the ISO-3166 TC46 decides to reassign the X* range to countries, all the worlds financial services have to rewrite, re-map and re-issue monetary units and bonds, since ISO4217 makes use of ISO3166. (Take the CFA francs for instance, mapped to XAF and XOF, where XA and XO are used as intended since ISO4217 (the user of the ISO3166 standard) can allocated X* as they see fit). 

I have many examples of standard bodies using ISO3166 User Assigned ranges for private use.

> And if they do, we would have no recourse.

Why not?

The IANA has not blindly surrendered to ISO-3166. There are differences in the list of ccTLDs and ISO’s officially assigned code elements. 

> OTOH, we do have a means of working with ICANN to codify certain TLDs for private use. 

This is false. If you are referring to RFC 6761, then I suggest to read it again. Focus on the “special use” part of the text. While the result of reserving (say) “.private” has the desired effect (nxdomain forever), this is not the intent of RFC6761. 

Roy

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 14:52:01 -0800

On 11/28/19 2:20 PM, Joe Abley wrote:
> Hi Doug,
> 
> I am not suggesting that you are wrong in your final paragraph, and I am 
> not philosophically opposed to reserving a label in the root zone for 
> private use, somehow analogously to RFC1918, but I think it's worth 
> challenging how obvious this really is. (Yours is just a convenient hook 
> to hang this reply to; it's not really directed just at you.)

No worries, but thanks for clarifying.  :) (And thanks for your well 
thought out questions as well.)

> I do think the semantic meaning of the label is worth thinking about, 
> and I am wary of particular scripts or languages being chosen 
> arbitrarily. I realise "internal" and "private" are sensible labels to 
> use for this kind of thing if you are English-speaking and used to 
> reading Latin script; I don't know that it's reasonable not to care that 
> they might not be sensible in other contexts. This to me is a much more 
> important conversation than bikeshedding about what regulatory agency 
> has said what about what.

heh, it's funny you mention that. I actually considered raising that in 
my first post, but decided to get over the hump of "let's do this" 
first. I agree that we need to consider this issue. I think the obvious 
choice would be to pick a word that has meaning in private space but no 
value in public, then document several language's worth of it, along 
with guidance not to delegate other translations of the word. This would 
also solve the issue raised previously that "sometimes you need more 
than one."

> It's also perhaps worth mentioning that the mechanics of how to 
> provision (or not provision) such a name with regard to DNSSEC 
> validation by various elements of the wider ecosystem have been a matter 
> of some debate in other venues. I doubt that dnsop is immune to that. I 
> won't fulfill that expectation by saying more in this message. :-)

Agreed, but having names documented for this purpose will make the 
DNSSEC bits easier, not harder.

> - has the advice to anchor a private namespace in a registered domain in 
> the private namespace really been received and judged to be 
> insufficient?

Yes.

> Or has it just not been received? Could such advice be 
> delivered in a more effective way?

The market has rejected this advice. I could bore you with examples and 
reasoning, but I have never worked with a client in an enterprise larger 
than a taco stand that didn't have at least one private domains set up.

It's fair to ask the question of do we need it, and it's also fair to 
document answers to most/all of the questions you've raised as part of 
the process. But given how things are in the real world, this is 
something that needs to happen.

> - does the growth in observed query traffic for names with non-existant 
> top-level labels really support the idea that squatting on arbitrary 
> undelegated TLDs is on the rise? Is it possible there are other effects? 
> Have we normalised the observed growth against other known causes of 
> growth? If this phenomenon is actually becoming less common, does it 
> need a solution beyond "wait"?

In my experience the practice is so ubiquitous that while these 
questions are good in the abstract, spending time on them would be a 
waste of effort. That said, ICANN's name collision work is relevant 
here, and I encourage anyone with interest in the topic to review that 
at length. It was really well done, and well documented to boot.

> - what are the possible negative effects of providing a TLD label for 
> use in private namespaces? We know that in the addressing realm, RFC 
> 1918 and similar private-use addresses lead to collisions during M&A, 
> interconnections, etc. Perhaps these are reasonable trade-offs for 
> addresses. Is the same true for names?

This is a good question to address, although the collision risk for 
non-common names in a private TLD is lower than the risk of collisions 
of integers. Two orgs using PRIV might each have a www, but if one of 
them has a naming convention of host-rack-floor.priv for their data 
centers, that's not likely to collide.

That said, the commonly chosen names already have a non-trivial risk for 
collisions. The marginal risk of codifying a set of examples is in the 
noise.

> - does promoting a single anchor for private namespaces concentrate 
> traffic that leaks from those internal contexts to the Internet's DNS? 
> If the leakage of queries that are intended to be private represents a 
> security concern, does the concentration of targets for that traffic on 
> the Internet make the security concern worse?

I don't see how we could make this worse. If you look at ICANN's name 
collision work, the results are already concentrated in CORP, HOME, and 
MAIL, which is why they were indefinitely-but-maybe-not-forever taken 
out of the new gTLD program.

> For the record, I don't personally see any enormous harm from 
> standardising something like Warren's ".internal" (or Roy's ".zzz", to 
> make it clear that I'm not talking about the specific label). But I do 
> think questions like the ones I mentioned are worth putting some effort 
> into answering.
> 
> Perhaps I've missed some elegant and robust analysis, but to date all 
> I've seen is "nobody likes the advice to register MYCO.COM 
> <http://MYCO.COM> and use that, so obviously we need to do something". 
> If that's really where we are, it seems like it would be comforting to 
> be able to say so more convincingly.

I think the massive volume of queries for non-delegated TLDs hitting the 
roots already makes that case, doesn't it? We know that this is, at 
least, incredibly common; and in my experience nearly ubiquitous. I do 
agree that we should make sure that we're not making anything worse by 
doing it, but the existence of the demand cannot be more obvious.

Doug

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 15:14:25 -0800

>  From section 3.2: "The deferral is not guaranteed to be forever”. That doesn’t read like a promise to not delegate HOME, CORP, and MAIL.

Yes, Paul Hoffman confirmed your reading of the text, and I've already 
conceded that this isn't a guarantee. Which is all the more reason to 
work with ICANN to solidify it.

> It is not that simple. While it is in ISO’s remit to change a category from User Assigned to another category, it is extremely improbable.

What I find really interesting about this is that folks on your side of 
the argument want us to believe that ICANN is free to change their mind, 
but ISO is not.

> The IANA has not blindly surrendered to ISO-3166. There are differences in the list of ccTLDs and ISO’s officially assigned code elements.

Examples please? I know when I was in charge of that we were pretty 
strict about it.  :)  And yes, I'm aware of the fact that ICANN uses 
"exceptionally reserved" code elements like AC and EU (I worked on the 
IANA Report for the latter), but ICANN's use is consistent with their 
definitions.

> This is false. If you are referring to RFC 6761, then I suggest to read it again. Focus on the “special use” part of the text. While the result of reserving (say) “.private” has the desired effect…

I'm referring to the fact that the IETF and ICANN have a unique 
relationship in regards to the stewardship of the root zone, and that we 
should utilize that relationship, in cooperation with them, to codify 
domains for this use case. Is your argument that this is a thing that 
cannot be done? Just because 6761 documented one aspect of the 
non-public TLD situation doesn't mean that we can't create a new 
document that codifies others.

In fact, that's exactly what you're asking us to do, it's just that for 
some reason you don't want to involve ICANN in the process, you want to 
do it by laying claim to things that don't belong to us.

Doug

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 Nov 2019 18:58:11 -0500

Hi Doug,

I appreciate the response and I don't doubt your experience, but I do think there is some value in a more robust study around some of these questions. Really the prevalence of no-doubt well-informed but largely unsubstantiated opinions (to the level of detail that I was trying to infer) is what I am arguing we need to do better than.

Joe

> On Thursday, Nov 28, 2019 at 17:52, Doug Barton <[email-masked] (mailto:[email-masked])> wrote:

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 16:07:13 -0800

Can you please explain why ICANN's work on name collision and the 
ongoing onslaught of queries at the root for un-delegated TLDs are not 
sufficient evidence?

And if not, how do you propose that we study it?

Doug

On 11/28/19 3:58 PM, Joe Abley wrote:
> Hi Doug,
> 
> I appreciate the response and I don't doubt your experience, but I do 
> think there is some value in a more robust study around some of these 
> questions. Really the prevalence of no-doubt well-informed but largely 
> unsubstantiated opinions (to the level of detail that I was trying to 
> infer) is what I am arguing we need to do better than.
> 
> 
> Joe

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 Nov 2019 16:24:18 -0800

On Nov 28, 2019, at 19:07, Doug Barton <[email-masked]> wrote:

> Can you please explain why ICANN's work on name collision and the ongoing onslaught of queries at the root for un-delegated TLDs are not sufficient evidence?

If it's not obvious from the questions I asked, then perhaps not.

> And if not, how do you propose that we study it?

By avoiding words like "onslaught" and building substantiated
conclusions from data.

Joe

---

From: "John R Levine" <[email-masked]>
Date: 28 Nov 2019 20:15:17 -0500

> You, like Ted, are ignoring the fact that ISO can choose to change those 

The user assigned codes are part of the published ISO 3166 standard.  If 
that's not stable enough, neither is any ccTLD.  What if they decided to 
swap .US and .SU?  Jaap assured us they're not going to change, and he 
should know.

> working together with ICANN ...

The politics about this at ICANN are hopeless.  There are still six 
applications for corp, home, and mail who would object loudly if ICANN 
said they were permanently unavailable and who torpedoed Lyman Chapin's 
proposal to add them to the 6761 list.  Fighting that is not a good use of 
anyone's time.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 28 Nov 2019 20:18:45 -0500

> arbitrarily. ...

Part of Roy's pitch was that the reserved two letter codes like .ZZ are 
equally meaningless in most languages.

> insufficient? Or has it just not been received? Could such advice be 

How long have wee been telling people to anchor their private namespace on 
a registered name?  It's on the order of a decade, I believe, and it's 
clear that for whatever reason people want something that's easy to type.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 17:37:13 -0800

On 11/28/19 5:15 PM, John R Levine wrote:
>> You, like Ted, are ignoring the fact that ISO can choose to change 
>> those rules.
> 

I don't doubt Jaap. What I doubt is that any organization as political 
as ISO (or ICANN) will hold preferences stable in the absence of a 
controlling policy.

>> Ok, so if you think there is a risk here, then it should be mitigated 
>> by working together with ICANN ...
> 
> proposal to add them to the 6761 list.  Fighting that is not a good use 
> of anyone's time.

Given the time that's passed this landscape may have changed. But if it 
has not for CORP, HOME, and MAIL; why not open the discussion about 
whatever strings we decide are useful instead?

Doug

---

From: Doug Barton <[email-masked]>
Date: Thu, 28 Nov 2019 17:42:01 -0800

> If it's not obvious from the questions I asked, then perhaps not.

What I'm looking for are specific areas in which the existing volume of 
evidence is lacking. We already have a lot of data which addresses the 
questions you raised. What is it about the existing data which is 
inadequate? What data do you want to see collected instead?

> By avoiding words like "onslaught" and building substantiated

Thank you for defining "study." What I'm looking for is a specific plan. 
If you don't have one in mind, or can't be bothered to create one, then 
this feels like another example of "We have to study the problem more" 
as an excuse not to take action. (I would be very happy to be proven 
wrong though.)

Doug

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 29 Nov 2019 12:14:50 +0100

Doug Barton writes:

 > I don't doubt Jaap.

Thank you.

 > What I doubt is that any organization as political 

Here are some more facts from the trivia corner.

The ISO was started from 1947. The first edition of the 3166 standard
is from 1974 and defined the User assigned codes as:

	The series of letters AA, XA to XZ, and ZZ, and the series AAA to AAZ, XAA
	to XZZ and ZZA to ZZZ respectively, are available for private use, and for
	provisional codes which should be recorded as soon as possible by the
	maintenance agency. An existing alpha-1 code which is in agreement with
	the first letter of the alpha-2 code may be used for an appropriate time
	to be fixed by the agency.

The second edition (1981) said:

	The series of letters AA, OM to QZ,XA to XZ, and ZZ,and the
	series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ
	respectively and the series of numbers 900 to 999, are
	available for individual use.

so it did add the ranges starting with a Q. 

The later editions are all defining the same name space (with sometimes
different wording).

A similar exercise can be done for ICANN en TLD name space but I
leave that up to the reader(s).

However, I cannot help noticing that for years I hear from various
ICANN stakeholders that ICANN should start to use alpha-2 codes as
well. Most recently in the meetings of the GNSO newgtld working
group, subgroup wt-5. The motivation is that then Volkswagen can
have its TLD ".vw" and the Bank of America (why not bank of Albania?)
".ba".

	jaap

PS. [Apparently proponents of ba for a bank don't realize that it
    is assigned to Bosnia and Herzegovina].

---

From: Brian Dickson <[email-masked]>
Date: Fri, 29 Nov 2019 10:52:02 -0800

> at length. It was really well done, and well documented to boot.
As many of the participants in dnsop were actively involved in reviewing
that work, I disagree.
I think the consensus was, and still is, that the work (done by a third
party under contract) was not particularly well done.

My view of that work is that the parameters given to the third party were
myopic, and the methodology was flawed.
The focus was specifically only on a hard-coded list of prospective new
TLDs, and cannot be generalized.

The follow-up proposal for "tasting" new TLDs was equally flawed, and IMHO
did not adequately address a number of major concerns.

Also, as a general comment, I think you are using too many pronouns or
phrases that are ambiguous or not well defined, in this discussion.
E.g. elsewhere you reference market "demand", but not for a demand for
what. Similarly, "the practice" above isn't clear here.

I think one of the reasons Joe raises study, is that there has been no
analysis of data for top-level queries (possible TLDs),
other than those included in the aforementioned report. That would mean no
study has been done on e.g. ".internal" as a TLD string.
The more general question has to do, not with queries for the big three
non-delegated domains identified in the report,
but for other non-delegated top-level labels: are there distinguishable
sets of popular such labels; has the size of the set of
labels been changing, and is it increasing or decreasing; and what is the
trend and proportional volume on those labels.

This is the kind of information that, at a minimum, should be included in a
proposal for a new "private" non-delegated TLD-like label,
i.e. to justify the choice of label(s), and demonstrate non-collision risk
related to using said label(s).

This is the strength of Roy's proposal; there is solid documentation from
the ISO that says these are really private use things. They can be used
today, even if there is a very small chance that the ISO might change that
at some point.

My opinion on the private use TLDs issue is that it makes sense to move
forward in two directions simultaneously: Roy's proposal; and what you
appear to want (one or more private labels reserved by ICANN based on
coordination between the IETF and ICANN).

The market can choose, and you are free to advocate for your preferred
option, but I don't see any legitimate reason to oppose Roy's proposal if
you can get what you want via your proposal. Suggesting that only one
can/should be used is a straw man, and/or bikeshedding.

I know my intention is to use Roy's scheme, in future work within the IETF,
and that based on what Roy and Jaap have documented, I don't think there is
even a need to wait for publication of an RFC to be safe in using one or
more of these labels.

Those of us not interested in pursuing the ICANN direction can avoid any
delays. I fully encourage you to pursue your approach, but do want to
politely caution you to have reasonable expectations on the speed and
likelihood of success.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 29 Nov 2019 11:10:23 -0800

> than a taco stand that didn't have at least one private domains set up.
I don't think anyone doubts that you have tons of experience with lots of
customers.

However, there are very important differences between anecdotes and proper
statistical studies.

There are any number of reasons for why those might differ in meaningful
ways.
There could be populations which, for whatever reason, don't overlap with
your set of clients, with different characteristics.
There could be an inherent selection bias, in how your clients choose you
or how you find your clients.
Certainly, the size of your client set, is not very likely to be anywhere
near large enough to be statistically significant, compared to the number
of domain registrants worldwide (hundreds of millions).

What folks are trying to say is, in order to build rough consensus, which
is how the IETF works, it helps to have something (anything) to support
your assertions, preferably something that can be easily confirmed
([citation needed]).

And, does the use case you are concerned with, actually need to be at the
TLD level? Would something like "internal.zz" not be just as suitable,
assuming you concur with the ".zz" usability? (Substitute arpa for zz if
you prefer.)

Brian