[NCAP-Discuss] [Ext] Top-level Domains for Private Internets IETF draft

[Roy Arends]

On 15 Jun 2020, at 14:40, Jeff Neuman <jeff.neuman at comlaude.com> wrote:
> 
> Roy,
> 
> Why have you chosen to take this through the IETF track as opposed to taking it through the ICANN process. Seems to me that this is all about policy and very little about technical information in this Informational RFC.
> 
> These are the very things that should be dealt with in the ICANN policy processes.  The notion of creating namespaces for private use is purely policy and therefore dealing with this through the IETF, in my opinion, is not how we should be thinking about this.  Sure, it may be easier to get this type of thing through the IETF, but we should be more focused on improving the multi-stakeholder model to allow these types of discussions rather than trying to circumvent it.

Jeff,

I reject the notion that I am trying to circumvent the ICANN multi-stakeholder model. Your thinking that “this type of thing” may be easier to get “through the IETF” is a bit naive, If it was easy, it would have been done by now, and folks sure have tried.

To answer your question of why the IETF:

1) In RFC 8499, the IETF makes a distinction between what it considers the Global DNS (ICANN’s remit) and Private DNS (IETF remit).
2) This Internet Draft is about Private DNS.
3) There is no designated Private DNS Top Level Domain
4) In absence of guidance from the IETF, ICANN or any other organisations, some labels have become the de facto status quo for private use, such as .home and .corp
5) While the IETF, ICANN and other organisations agree that such status quo is undesirable, it stopped short of recommending a Private DNS top level domain.
6) This document is trying to fix that.
7) Attempts have been made, in the IETF, to allocate a space for private use, only to be referred to ICANN, as the proposed labels at the time clearly fall into ICANN’s remit (such as .alt and .internal).

To answer your question of why not ICANN:

While there is no intent to circumvent ICANN, The ICANN PDP, The ICANN Stakeholders and wider Community, I did do my research:

1) The ISO/TC46/WG2 refers to the ISO3166 Maintenance Agency (MA) for the assignment (Reserved, Assigned, Re-Assigned, Deleted) of two letter codes to country names.
2) The ISO/TC46/WG2 has referred the User-Assigned two letter codes to users (not to the MA!)
3) The ISO3166/MA has no authority over the User-Assigned two letter codes.
4) in RFC1591, (pre ICANN) the IANA (Jon Posted) stated that "The IANA is not in the business of deciding what is and what is not a country.” and subsequently referred to the ISO3166 list for country codes
5) in RFC3071, (post-natal ICANN) Klensin reflected that aligning IANA ccTLD assignments with ISO3166/MA assignments is a good thing
6) when ISO3166 user-assigned codes are assigned by IANA, it violates the principles in RFC1591 and RFC3071. In other words, it would be an astonishingly bad idea to do so.
7) when ISO3166 user-assigned codes are reassigned by ISO/TC46/WG2 to the MA as available codes for assignment to country names, an incredible amount of damage would have to be fixed by others [1] since they are all using the User Assigned codes as intended.
8) it is thus highly unlikely for these reserved two character codes will be delegated.

In other words, users can use these safely. I want to avoid that organisations can legitimately argue that absent any guidance, they can use .home or .corp in their deployments.

Note that these last 8 points about "why not ICANN" does not motivate the need to discuss-this-at-ICANN-instead-of-IETF. I will not stand in the way of any organisation or committee that feels the need to develop policy over this. 

Happy to discuss with you any of the points above in detail.

Lastly,

I am discussing this with the ICANN community. My first stop is the ccNSO Tech Day (apologies if I have the term wrong) Monday the 15th of June. I am very happy to discuss this in public. 

> Has this been submitted to the GNSO?

Not that I am aware of. 

Warmly,

Roy

[1] such as ISO standards ISO3901, ISO4217, ISO6166, ICAO, WIPO, the UN (UNLOCODE), Worldbank, interpol, the CA Browser Forum, the IETF (BCP47, RFC5890), etc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3931 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200615/188126e0/smime.p7s>