[NCAP-Discuss] [Ext] Top-level Domains for Private Internets IETF draft
Warren Kumari
warren at kumari.net
Mon Jun 15 23:52:39 UTC 2020
"
On Mon, Jun 15, 2020 at 4:51 PM Roy Arends <roy.arends at icann.org> wrote:
>
> 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).
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 FindingsFinding 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
RecommendationsRecommendation 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 namein 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, thetwo-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 harmlesslydiscarded 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
> 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/20200615/6e8af099/attachment-0001.html>
More information about the NCAP-Discuss
mailing list