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

Jeff Schmidt jschmidt at jasadvisors.com
Thu Jun 18 16:36:12 UTC 2020 

As much as I love a good Internet policy wonk debate, we need to keep in mind what we’re trying to accomplish.  We want to help people and solve a problem.  We all want the same noble thing.

The reason we have this problem is we (collectively, the technical community) have done a poor job communicating the “right” way to use private DNS namespaces.  We did a good job with 1918/IP; we did a bad job with DNS.  So, folks made it up themselves, and now we’re here.

Marketers will tell you “meet your customers where they are.”  People expect this to be in a simple and clear RFC, just like 1918.  Tell me what to do and I’ll do it.  If we want to actually solve the problem, it should be a simple and clear RFC.  People will follow that.  Debating the correct policy forum for communicating this for literally years and then burying it in some obscure ICANN or GNSO document (organizations exactly no one outside of our community have actually heard of) won’t solve the problem for the masses.

I don’t pretend to understand the IETF’s reluctance to address this issue, but whatever the reason it hurting the Internet and by taking the ostrich and/or finger pointing approaches the IETF has become complicit in every collisions related problem.

In the spirit of be simple and clear and tell me what to do, I’d offer feedback to Roy et al (and DNSOP) that the 8 June draft is too complicating and actually doesn’t make a clear recommendation.  12 pages of ISO 3161 discussion doesn’t help your average administrator choose a private TLD.  And the 8 June draft doesn’t expressly say “Use .ZZ” rather it leaves it as an exercise to the reader to pick one of 42 codes the ISO, ICAO, WIPO, the World Bank (all folks again exactly no one outside of our unusual circles has actually heard of) don’t seem to want for whatever reason.  Doesn’t meet our customers where they are.  Doesn’t help.

In Section 5, instead of “This document does not recommend any specific ISO 3166-1 alpha-2 user-assigned code as a private use, but instead [offers 12 pages of dense technobabble no one will care about]” it should say “Use .ZZ”  Just like 1918.

Jeff





From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Warren Kumari
Sent: Monday, June 15, 2020 6:53 PM
To: Roy Arends <roy.arends at icann.org>
Cc: ncap-discuss at icann.org
Subject: Re: [NCAP-Discuss] [Ext] Top-level Domains for Private Internets IETF draft

"

On Mon, Jun 15, 2020 at 4:51 PM Roy Arends <roy.arends at icann.org<mailto:roy.arends at icann.org>> wrote:
>
> On 15 Jun 2020, at 14:40, Jeff Neuman <jeff.neuman at comlaude.com<mailto: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).

Can you please point to *where* in RFC 8499 ("DNS Terminology", https://datatracker.ietf.org/doc/rfc8499/) that distinction is made? I certainly didn't interpret that document as saying this, and would be surprised/dismayed if it did. We have some very carefully worded documents such as the IETF-ICANN MoU which outline this sort of thing, and I certainly didn't think that this RFC reinterpreted these -- if it *did*, I think that I, as responsible AD for the document, made a mistake that will need to be rectified.


There is RFC2860 - "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" (https://tools.ietf.org/html/rfc2860) and the matching "IETF-ICANN Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" (https://www.icann.org/resources/unthemed-pages/ietf-icann-mou-2000-03-01-en). This RFC contains:
"4.3. Two particular assigned spaces present policy issues in addition
   to the technical considerations specified by the IETF: the assignment
   of domain names, and the assignment of IP address blocks. These
   policy issues are outside the scope of this MOU.

   Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4. "


There is RFC6761 - "Special-Use Domain Names" (https://tools.ietf.org/html/rfc6761) which "describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so."

This process was used to add .onion to the Special-Use Domain Names registry (https://ietf.org/blog/onion/), but went on to say: "However, subsequent to this action, the IESG believes RFC 6761 needs action, and substantial community input. It needs to be open for review and modification because the current process is unscalable. Several other names had also been submitted for consideration as special names, and the RFC may not give adequate guidance about how when names should be identified as special names. Special names should also be, as the name implies – special and rare. The DNSOP working group is chartered to address this RFC 6761 review."

This was the impetus behind RFC8244 -  "Special-Use Domain Names Problem Statement" (https://tools.ietf.org/html/rfc8244), which says (amongst many other things) that
  "The policy defined in RFC 6761 for IANA registrations in the
   "Special-Use Domain Names" registry has been shown, through
   experience, to present challenges that were not anticipated when RFC
   6761 was written.  This memo presents a list, intended to be
   comprehensive, of the problems that have since been identified.
...
The list of problems is not presented in order of importance; numbers
   are assigned so that each problem can easily be referenced by number,
   not to indicate priority.  The list of problems is as follows:

   1.   Although the IETF and ICANN have a liaison relationship through
        which special-use allocations can be discussed, there exists no
        formal process for coordinating these allocations (see
        Section 4.1.3).  The lack of coordination complicates the
        management of the root of the Domain Namespace and could lead to
        conflicts in name assignments [SDO-ICANN-SAC090].

   2.   There is no explicit scoping as to what can constitute a
        "technical use" [RFC2860] and what cannot; there is also no
        consensus within the IETF as to what this term means."

DNSOP did not update / revise RFC 6761 after this.


"SAC090 - SSAC Advisory on the Stability of the Domain Namespace" (https://www.icann.org/en/system/files/files/sac-090-en.pdf) says, amongst other things:
3 Findings
Finding 1: The SSAC finds that uncoordinated use of the domain namespace in overlapping environments can lead to ambiguity when those environments overlap and their names collide. This ambiguity threatens the stability of the domain namespace when processing agents cannot reliably determine “what to do” when presented with an identifier that is a syntactically valid domain name.

Finding 2: More specifically, the SSAC finds that the lack of adequate coordination among the activities of several different groups contributes to the domain namespace instability identified in Finding 1:
• ICANN, in its role as coordinator of the allocation and assignment of names in the root zone of the Domain Name System,17 by inviting applications for new toplevel domains without specifying unambiguous criteria for determining whether a given string may or may not be (or potentially become) a top-level domain name label;
• the Internet Engineering Task Force (IETF), in its role as the Standards Development Organization for the DNS protocol, by reserving some domain names for special use;18 and
• other individuals and organizations, by using independently selected domain names in environments that cannot reliably be distinguished from the environment in which domain names are resolved by reference to the global DNS root
...
4 Recommendations
Recommendation 1: The SSAC recommends that the ICANN Board of Directors take appropriate steps to establish definitive and unambiguous criteria for determining whether or not a syntactically valid domain name label could be a top-level domain name
in the global DNS.

2: Recommendation 2: The SSAC recommends that the scope of the work presented in Recommendation 1 include at least the following issues and questions:
1) In the Applicant Guidebook for the most recent round of new generic Top Level Domain (gTLD) applications, ICANN cited or created several lists of strings that could not be applied-for new gTLD names, such as the “reserved names” listed in Section 2.2.1.2.1, the “ineligible strings” listed in Section 2.2.1.2.3, the
two-character ISO 3166 codes proscribed by reference in Section 2.2.1.3.2 Part III, and the geographic names proscribed by reference in Section 2.2.1.4. More recently, the IETF has placed a small number of potential gTLD strings into a Special-Use Domain Names Registry.
2) As described in RFC 6761, a string that is placed into this registry is expected to be processed in a defined “special” way that is different from the normal process of DNS resolution. Should ICANN formalize in policy the status of the names on these lists? If so:
i) How should ICANN respond to changes that other parties may make to lists that are recognized by ICANN but are outside the scope of ICANN’s direct influence?
ii) How should ICANN respond to a change in a recognized list that occurs during a round of new gTLD applications?
2) The IETF is an example of a group outside of ICANN that maintains a list of “special use” names. What should ICANN’s response be to groups outside of ICANN that assert standing for their list of special names?
3) Some names that are not on any formal list are regularly presented to the global DNS for resolution as TLDs. These so-called “private use” names are independently selected by individuals and organizations that intend for them to be resolved only within a defined private context. As such they are harmlessly
discarded by the global DNS—until they collide with a delegated use of the same name as a new ICANN-recognized gTLD. Should ICANN formalize in policy the status of “private use” names? If so:
i) How should ICANN deal with private use names such as .corp, .home, and .mail that already are known to collide on a large scale with formal applications for the same names as new ICANN-recognized gTLDs?
ii) How should ICANN discover and respond to future collisions between private use names and proposed new ICANN-recognized gTLDs?
Recommendation 3: Pursuant to its finding that lack of adequate coordination among the activities of different groups contributes to domain namespace instability, the SSAC recommends that the ICANN Board of Directors establish effective means of collaboration on these issues with relevant groups outside of ICANN, including the IETF.

Recommendation 4: The SSAC recommends that ICANN complete this work before making any decision to add new TLD names to the global DNS.

I would note that SAC090 Recommandation 2.1 specifically mentions the "two-character ISO 3166 codes", and recommends that the ICANN BoD include this in the criteria.


RFC 8499 **does** say:
"Private DNS:  Names that use the protocol described in [RFC1035] but that do not rely on the global DNS root zone or names that are otherwise not generally available on the Internet but are using the protocol described in [RFC1035].
    Note that domain names that do not appear in the DNS, and that are intended never to be looked up using the DNS protocol, are not part of the global DNS or a private DNS even though they are domain names."


I don't think that that is nearly as clear cut as "the Global DNS (ICANN’s remit) and Private DNS (IETF remit)" - that would make the IETF in charge of anything which hadn't been delegated (yet), but which is being used - e.g .corp. The IETF/ICANN MOU (a founding document) was very carefully worded and I do not think that it can be so easily reinterpreted.


> 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).

.alt was not referred to ICANN. In fact, we held a joint webinar with ICANN where this was discussed and it was agreed that, as it is specifically used for non-DNS protocols, it was fine in the IETF.
.internal *was* referred to ICANN; when I presented it at the IETF, it was pointed out that this falls into the ICANN policy realm, and so I brought it to ICANN SSAC.

I think you are saying that RFC8499 says that the IETF is responsible for everything that is not in the global DNS (private DNS), and I could not interpret it like that. If indeed it does say that, then I believe this is an error that needs to be corrected. Otherwise we run the risk of uncoordinated allocations from the same namespace and a lack of clarity as to who is responsible for names that can show up in the root.


W

>
> 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_______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org<mailto:NCAP-Discuss at icann.org>
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.



--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200618/4f59d262/attachment-0001.html>

More information about the NCAP-Discuss mailing list