wdiff draft-adpkja-dnsop-special-names-problem-02.txt draft-adpkja-dnsop-special-names-problem-03.txt

Network Working Group J. Abley G. Huston
Internet-Draft Dyn, Inc. APNIC
Intended status: Informational P. Koch
Expires: September 21, November 25, 2016 DENIC eG
A. Durand
ICANN
W. Kumari
Google
March 20,
May 24, 2016

Problem Statement for the Reservation of Top-Level Domains in the
Special-Use Domain Names Registry
draft-adpkja-dnsop-special-names-problem-02
draft-adpkja-dnsop-special-names-problem-03

Abstract

The dominant protocol for name resolution on the Internet is the
Domain Name System (DNS). However, other protocols exist that are
fundamentally different from the DNS, and may or may not share the
same namespace.

When an end-user triggers resolution of a name on a system which that
supports multiple, different protocols (or resolution mechanisms) for
name resolution, mechanisms), it
is desirable that the protocol used is unambiguous, and that requests
intended for one protocol are not inadvertently answered using
another.

RFC 6761 introduced a framework by which, under certain
circumstances, which a particular domain name
could be acknowledged as being special. This framework has been used twice to reserve top-
level domains (.local and .onion) that should not be used within the
DNS, to avoid the possibility of namespace collisions in parallel use
of non-DNS name resolution protocols. Various challenges have
become apparent with this application of the guidance provided in RFC
6761. This document aims to document those challenges in the form of
a problem statement, statement in order to facilitate further discussion of
potential solutions.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 21, November 25, 2016.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Terminology . . . . . . Introduction: DNS, Name space or Name Spaces, Name Resolution
Protocols . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . 2
2. IETF RFC6761 Special Names . . . . . . . . . . . . . . . . . 3
3. RFC Issues with 6761 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural Considerations . . . . . . . . . . . . . . . . 6
5. Technical Considerations . . . . . . . . . . . . . . . . . . 8
6. Organizational Considerations . . . . . . . . . . . . . . . . 9
6.1. External Organizational Considerations . . . . . . . . . 9
6.2. IETF Internal Considerations . . . . . . . . . . . . . . 10
6.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.2. Technical Criteria . . . . . . . . . . . . . . . . . 11
6.2.3. Name Candidate string evaluation . . . . . . . . . . . . . . . . . . . 12
6.3. The and relationship with ICANN process to evaluate names . . . . . . . . . . . 13
7. 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. 6
8.2. Informative References . . . . . . . . . . . . . . . . . 15 7
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 16 7
A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7
A.2. Pithy Quotes from History . . . . . . . . . . . . . . . . 17
A.3. Change History . . . . . . . . . . . . . . . . . . . . . 17
A.3.1. 7
A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 17 7
Appendix B. Change history . . . . . . . . . . . . . . . . . . . 17 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 8

1. Terminology

Clear and unambiguous use of terminology is important for the clear
formulation of any problem statement. The Introduction: DNS, Name space or Name Spaces, Name Resolution
Protocols

For a very long time, DNS protocol suffers from
imprecise and overloaded terminology (for example, see [RFC7719]).
The use of terms and concepts from other naming systems that are
similar (but different) simply confuses matters further.

In the interests of clarity, the following terms used in this
document are to be interpreted as follows:

Registry (n): the Special-Use Domain Names Registry created by
[RFC6761] and published at [IANA-SPECIAL-USE].

[This section to be completed following review and refinement of the
rest of the text.]

2. Introduction

Some systems use the last label in a name to act space have been perceived as a switch to a
different, non-DNS resolution process - examples of such switches
include: .local (to use mDNS) and .onion (to use Tor). This switch
practice is not explicitly documented anywhere,
one and the method for
accomplishing same. However, this varies by implementation. As an interesting
aside, has not always been the full semantics of domain names isn't really documented
anywhere either, although [I-D.lewis-domain-names] is a current
attempt to rectify this.

This technique of using case; in the last label as a switch has a number of
properties which make it attractive to people implementing alternate
past, other name resolution systems, including:

o The names protocols were popular. One can follow remember
NIS, NIS+, host files, UUCP addresses... Most of those have been
obsoleted by the common DNS syntax in the late 1990s. More information on the
history of LDH labels,
separated by dots. This means that these names and namespaces can be entered found in
any application which takes existing DNS names.

o The switch to the
[I-D.lewis-domain-names].

More recently, new name resolution process can be implemented in protocols have been proposed, each
addressing a
number of ways, such as custom application code, particular need or a shim in particular community. For example,
the
normal DNS resolution process, or on DONA handle system has been used by the system's configured DNS
servers.

o publication industry.
The names "look" like names Apple "Bonjour" set of protocols, inspired by what was available
on Appletalk networks, has been developed to users.

Note that [RFC6303] defines "locally served zones". perform automatic name
resolution on a local IP network. The important
difference TOR project is that in [RFC6303], the names get registered for special
treatment if they are already special: they are not declared special
by the registration.

[RFC6761] defines ways to reserve domain names. This could be read
to augment the technical uses exemption made in [RFC2860] (also
called "the IETF-ICANN MoU"). [RFC2860] says:

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

The framework in [RFC6761] has recently been used onion
system to reserve obfuscate communications, the
.onion label, allowing it GNU Name System (GNS) system
is using block chains to be used as build a switch decentralized name system to the Tor offer
"privacy and censorship resistance". Many more have been proposed.

Those alternate name resolution process, as described in [RFC7686]. Because the .onion
label in the IANA "Special-Use Domain Names" registry
[IANA-SPECIAL-USE], the Tor Project can be assured that there will protocols do not be a .onion TLD created in the IANA rooted DNS, and thus the
possibility of collisions in the namespace will be avoided.

The discussions in the DNSOP Working Group (WG) and the IETF Last
Call processes for the .onion registration exist in the Special Use Domain
Names registry (1,200 messages) a vacuum.
Application developers have made it apparent that clarity
about if and how to treat this "protocol switching" practice would
help expressed a lot strong desire to build their
software so it will function in deciding the merit of future similar applications.

One possible outcome any of those universes with minimal
changes. Doing so means that the discussion would be to decline software has to recognize such usage
deterministically what kind of domain names in the architecture; another
possible outcome is to formalize name it is dealing with and better understand the issues
that come associate
it with it.

An additional consideration is that names which follow the DNS syntax
(including those which use alternate corresponding name resolutions processes to
the DNS) are in the same namespace as names in the DNS. This means
that currently both the IETF (through [RFC6761]) and ICANN are making
allocations or reservations from a shared namespace. If resolution protocol. Because of this
continues to be the case, in order
desired lack of explicit signaling, an algorithmic solution
frequently chosen by application developers consists simply to avoid conflict, close
coordination between use a
special tag padded at the two organizations is necessary.

3. RFC 6761

Section 5 end of [RFC6761] describes seven questions to be answered to
justify how and why a particular domain name is special. These seven
questions can be broadly categorized as follows:

1. impact on end-users;

2. impact on applications;

3. impact on to indicate an alternate name
resolution APIs and libraries;

4. impact on recursive resolvers;

5. impact on authoritative DNS servers;

6. impact on DNS server operators;

7. impact on DNS registries and registrars.

The intent of those seven questions was originally to serve as the
justifications for why a proposed special-use registration should be
granted, demonstrating that it (a) provides a result that the
community judges to be good, and (b) the aforementioned good result
cannot reasonably be achieved in another way. The rough consensus
from significant discussion was that .onion did satisfy both (a) and
(b), but this was not clearly demonstrated by the answers to the
"seven questions". Furthermore, it is unclear method. Examples: if and how these
questions could reliably and unambiguously be used to make the
determination, leading to the conclusion that they are generally
inadequate for making the determination whether a particular domain name qualifies as requiring special/different treatment.
Applications which follow the [RFC6761] process are likely to devolve
into a "beauty contest". Moreover, the answers to the seven
questions are not available ends in a machine readable form to
applications that want to follow [RFC6761].

So .local, the answers to these seven questions can better be seen as
providing guidance to software
uses the corresponding seven audiences Apple Bonjour protocol based on how to
handle a special-use domain name once it has been reserved by
inclusion in multicast DNS; if the Registry, and not as entrance filters for inclusion name
ends in .onion, it uses the registry.

The answers to TOR protocol; if the seven questions specify desired behavior name ends in .gnu,
it uses the
internet for handling a particular domain name, not the basis for
deciding whether the effort to implement special behavior across all
of those audiences is worth the cost. This indifference GNS protocol, etc... One noteworthy exception to costs is
not necessarily scalable for making future decisions about potential
inclusion in the registry.

The justification in [RFC6761] this
approach is concerned with the rationale of
reserving a domain name DONA system that precludes its subsequent use as a top
level domain name. However, the document fails to offer such a
rationale, exists independently and instead requires has
developed its own interoperability solution with the justification DNS.

A result of the reserved
name to include the provision of guidance to above is that a number of audiences
(users, application developers, DNS resolver applications, DNS
resolution service operators, and name registries and registrars) as
to how to handle names applications have been
developed (and massively distributed) that are listed in this registry. But this
guidance is not, in and of itself, an adequate rationale for the
selection of have encoded their
favorite "tag" as a particular name value to be reserved in this registry.

What is missing DNS TLD in [RFC6761] is the consideration of the name itself.
If one were to contrast the procedures relating to the admission of a
name to the free-for-all, beginning their
existence squatting on that DNS space... .local, .gnu, .onion
started out like that.

2. IETF RFC6761 Special Use Name registry to the processes
associated with the New gTLD Program operated by ICANN [NEW-GTLD],
then it is evident that the Names

The IETF process does not admit many
considerations which appear to be areas of evaluation in used a provision from the New gTLD
program. More on this in IETF/ICANN MoU [RFC2860] section Section 6.3.

This document proposes to categorize considerations related to the
usage
4.3 that says that "(a) assignments of the [RFC6761] registry domain names for protocol switches in 3
categories: Architectural, Technical and Organizational. This
document then lists a number of questions to drive the discussion.
The list of issues discussed here technical
uses" is non-exhaustive.

However, some people have noted that [RFC6761] describes other
alternative special handling aside from protocol switches. That
alternative special handling must to be considered carefully at the time
of publication of the defining RFC, regardless of the nature purview of the
special use.

4. Architectural Considerations

The first thing to consider in this discussion is that not all names
(or domain names) are part IETF (as in, outside of the Domain Name System. See
[I-D.lewis-domain-names] for an in-depth discussion on this topic.

At the time
scope of writing, two top-level domain names reserved by
inclusion in the Registry went through the [RFC6761] process and are
used by name resolution protocols other than the DNS:

.local is used by the Multicast DNS protocol specified ICANN) in
[RFC6762] which is similar in some respects to the DNS, but which
uses a different well-known port number and is limited order to create a
particular multicast scope;

.onion is used way to construct reserve such names that designate services
reachable via the Tor network using onion routing.

These two name resolution protocols are, to varying degrees,
different from the DNS, and the namespaces used in each naming scheme
are also different. The top-level label is effectively being used as a name resolution protocol identifier. At the core of the issue is
that different "strings" that look like "domain names" (i.e. are
within the same name space) but are not DNS names are used
interchangeably in the URI (or URN).

In particular, DNS imposes constraints on name syntax. An example
list of
such constraints "special names". That process is the 63 octet limit per label. Strings used documented in
the .onion domain do [RFC6761]
(which curiously does not have that constraint.

It could be argued that in directly refer the absence of a more elegant alternative,
a pragmatic choice to embed protocol selectors as namespace tokens
has effectively already been made. The running code IETF/ICANN MoU). It was
first applied for .local and effective
consensus more recently for .onion. When that
process was put in how place, it should was thought it would only be used by significant user bases should
not be discounted. Although the reservation a
handful of names in the DNS
namespace can be times. However, a large number of applications have since
been made at any level, the two examples above
demonstrate use-cases for reservation at to the top-level, and hence
that case must be considered. IETF. The underlying discussion here is the tussle between the applications .onion evaluation took almost a year and
has started a massive (and often heated) discussion in the network. Application architects see using IETF.

This [RFC6761] process to reserve special name tags
(such as .onion) as an easy way to get new features deployed. They
consider the hurdles of deploying new URI schemes such as
http:/onion/onion-name as too onerous and too slow to deploy for
their needs. Network architects worry of overloading the semantics
of DNS names and/or creating has a name space number of
issues, that is larger than the DNS
namespace. They refer to bad precedents such as .uucp and .bitnet.

The fundamental point to consider here is can be grouped in two categories:

o Issues with [RFC6761] itself, including issues discovered during
the unicity (or
multiplicity) evaluation of the name space. Are we talking about one namespace .onion

o Higher level issues regarding candidate string evaluation and
relationship with different resolution protocols or independent name spaces? ICANN

3. Issues with 6761

1. It might it can be helpful use to point out that the property of interest
here is the assurance of uniqueness of a name, and another way of
thinking about the question is whether it applies across domain names
as people expect or need reserve any names, not just TLDs. For example,
it to? None of this would matter if people
didn't expect names constructed according to whatever rules they're
following to could potentially be unique across used to forbid a set of registrar to register
specific names that spans multiple
operating environments and resolution protocols.

In [RFC2826] the IAB noted that

"To remain a global network, the Internet requires the existence
of a globally unique public name space. The DNS name space is a
hierarchical name space derived from a single, globally unique
root."

"Maintaining a globally-unique public namespace that supports
different name resolution protocols is hence an architectural
requirement, and some facility for reservation of top-level
domains in the DNS is necessary."

If we were to accept the notion that the last label of a domain name
is actually a protocol switch, we are actually building a catalog of
all top level domains and what resolution protocol each one invokes.
Note that such a catalog any TLD.

2. [RFC6761] does not formally exist today, because
[RFC6761] is an exception list to mention if the general case protocol for which it is supposed
requested to use regular DNS as resolution protocol. Such a catalog may remain reserve a concept to guide this discussion or string should be implemented published as an actual
IANA registry [IANA-SPECIAL-USE]. In effect, it would associate TLDs
with indications on how RFC
document. Most applications and resolvers should treat them.
However, such an approach would leave open the question of not-yet-
defined TLDs. No resolution mechanism could be associated with those
in advance have, so that systems would have to continue to assume that such
names are part of far, come from outside
organizations, and the DNS. For reasons of completeness it is noted described protocols that suggestions have not been made to help the distinction
developed by using
special labels (as in IDNs).

It should also be noted that there are choices for a protocol switch
other than reserving labels. In particular, a proposal to move those
protocol switches under a specific top level domain has been
discussed (.ALT). If that architecture choice is made, some of the
questions listed in the sections below would become moot.

Note: IETF.

3. [RFC6761] mentions the reserved names could be any label in a
domain name, does not just provide clear enough direction as to what
party is responsible for carrying out the rightmost one (or ones). However, this
creates a number of complications evaluation.

4. There are ambiguities and has not seen much support in no formal criteria on how the community as IETF can
(or even whether the IETF should) evaluate the merits of now.

5. Technical Considerations

Each
applicants to [RFC6761] reservations. Section 5 of the [RFC6761]
describes seven questions posed to be answered by an applicant for
[RFC6761] has status. However, running this process for the potential to
describe why it may be necessary .onion
application showed that those seven questions are inadequate for special handling of
making the
requested name(s) in applications by determination for whether a particular audience. However,
aside from reserving the name, it is not entirely clear what any of
those audiences might further expect strings
qualifies as requiring special/different treatment.

5. Placing a result of a successful
request to add a top-level domain to the Registry.

For example, reservation of a top-level domain by string in the IETF [RFC6761] registry does not guarantee
that DNS queries for names within a reserved domain will not be
sent over the Internet. The requirements of the operators of
recursive resolvers in As such, the DNS applicant for [RFC6761]
status cannot be relied upon guaranteed that leakage will not occur and will
need to be
implemented; the impact on take this into account in the operators protocol design. Useful
reservations of DNS authoritative servers
hence cannot be reliably assumed to top-level domains should be zero. In the case accompanied by
documentation of
[RFC7686], leakage realistic expectations of .onion queries on the Internet might lead to
disclosure each of private information that, in some cases, might pose a
risk to the personal safety seven
audiences, and the evaluation of end-users.

At particular requests should
consider the time practical likelihood of writing, those expectations being met
and the implications if they are not.

6. The [RFC6761] registry lists the reserved names but does not
include direct guidance guidance, neither in free text form nor in machine
readable instructions, for any of the seven audiences, relying
instead upon a reference for each entry in the Registry to the
document that requested its insertion. Such documents might well
be opaque to many readers; [RFC6762] is a seventy-page protocol
specification, for example, which is arguably not the most
effective way to set expectations of non-technical end-users).

Useful reservations of top-level domains should be accompanied by
documentation of realistic expectations of each of the seven
audiences, and the end-users

4. Candidate string evaluation of particular requests should consider
the practical likelihood of those expectations being met and the
implications if they are not.

Here is a non-exhaustive list of additional questions that have
surfaced in discussion of requests for names to be added to the
Special Use Names registry:

What does it mean to have a "non-DNS" entry in the registry
described above?

Are applications supposed to check that registry to know what to
do?

Can, or should, applications do this check dynamically?

What if an application makes this dynamic check and discovers the
name contains a switch it relationship with ICANN

1. IETF does not know how to handle?

Similar questions applies to resolvers (DNS and non-DNS); what is the
expected behavior?

One particular avenue of investigation would be to see if such
considerations could be encoded in machine understandable code in an
extension of the current [RFC6761] registry.

6. Organizational Considerations

This section gives two categories of organizational considerations:
external and internal.

6.1. External Organizational Considerations

The policy surrounding the implementation and management of top-level
domains in the DNS has been developed using a multi-stakeholder have process convened by ICANN according to evaluate the MoU between ICANN and IETF
[RFC2860]. It is out of scope for this document proposed strings
candidate to revisit that MoU.

While discussing the particular attributes that make a domain name
special, [RFC6761] notes that "the act of defining such a special status for things like trademark, IPR,
name creates a higher-level protocol rule, above ICANN's management
of allocatable names on collision, etc.. Instead, the public Internet."

[RFC2860] draws a line between what is policy and what is technical.
A variety of opinions have been expressed regarding whether [RFC6761]
blurs this line. In particular, [HUSTON] has one viewpoint IETF relies on the
topic. As noted earlier, it is out of scope for this document to
analyse this issue beyond noting that such a variety of views exist.

Taking a different perspective, it has been argued that [RFC6761]
specifically extends the DNS protocol to include special treatment
for names in the registry,
reviews, working group and that there's nothing in [RFC2860] at
all that limits the IETF's authority to change IETF-wide last call, and ultimately a
decision is made by the protocol.

However, it should IESG. That decision can be noted that, if the IETF were appealed,
first to formalize the
concept of protocol/name switch in the Internet architecture,
coordination would be require between ICANN IAB and IETF on such names.
Using the analogy described above of a catalog/registry of such
switches, care must be taken second to make sure we do not end up with two
process streams allowed to create entries without complete
synchronization.

6.2. IETF Internal Considerations

6.2.1. Process

[RFC6761] specifies the way in which "an ISOC board of trusties.

2. The IETF 'Standards Action' or
'IESG Approval' document" should present answers to the questions
described above (see Section 2), but does not describe the "review" process by
which the answers to those questions should be evaluated.

For example, it is not clear who is responsible for carrying out an
evaluation. A foolproof. [RFC7788] describing
the "home networking control protocol" was recently published.
That document which requests additions includes text instructing devices to the Registry
might be performed by the IESG, by the IAB, use names
terminating by default with the DNSOP WG, by an
ad-hoc working group, by expert review or any combination of those
approaches. .home suffix. [RFC7788] did not
reference [RFC6761] provides anywhere and had no direction.

As an illustration of the inconsistency that has been observed
already, [RFC6762] IANA sections about this
reservation. It was published as an AD-sponsored individual
submission in the INT area, and the IESG evaluation record does not
reveal any discussion of the reservation of the .local top-level
domain in without anyone noticing this
during the DNS. [RFC7686], however, entire review process. The issue was published as a working
group document through caught after the DNSOP WG,
publication, and an extensive discussion by
both the participants of the DNSOP WG and the IESG on the merits of
the request took place. The evaluation process, in the absence of
clear direction, is demonstrably inconsistent.

We should point to [RFC5226] and explicitly quote the definition of
"Standards Action" or "IESG Approval":

IESG Approval is not intended to be used often or as a "common
case"; indeed, it has seldom been used in practice during the
period RFC 2434 errata was in effect. Rather, it is intended published.

3. There exists now at least 2 streams to be
available in conjunction with other policies as a fall-back
mechanism in the case where one take strings out of the other allowable approval
mechanisms cannot be employed in a timely fashion or for some
other compelling reason. IESG Approval is not intended to
circumvent the public review processes implied by other policies
that could have been employed for a particular assignment. IESG
Approval would be appropriate, however, in cases where expediency
is desired
global namespace: IETF RFC6761 "special names" and there is strong consensus for making the assignment
(e.g., WG consensus).

So, while it ICANN "gTLD
program" (see [NEW-GTLD]). It is very interesting important to note observed that [RFC6761] was an AD
sponsored individual submission in spite of two active DNS related
WGs, [RFC6762] is probably clean: it defines the protocol and is
itself on standards track.

[RFC7686] however, while on standards track, does not define the TOR
protocol, so it was used to fulfill the 'standards action'
requirement by the letter. It contains normative references to non-
IETF protocols, which is noteworthy.

A comparison of the two "seven question forms" from [RFC6761] reveals
that RFC6761 reservations could happen in a ad-hoc fashion at least the responses to questions 2, 3, and 4, differ
significantly any
time, while there is no defined way to communicate the
difference to the affected software entities.

An alternate view has been expressed with regard to the protocol
evaluation. It states that the authority belongs to the IESG to seek
whatever support it likes, within the established process, ICANN delegations typically happen in making
standards decisions, including delegating evaluation of a specific
registry change proposal to a WG or a directorate. The IESG might
have varied what guidance it sought, but that does not constitute
"inconsistency" under the process. That being said, more complete
evaluation guidance would be helpful to the IESG batches, and
the community.

6.2.2. Technical Criteria

Regardless of the actual name being proposed as protocol and/or
namespace switch, it latest gTLD round is also not clear what technical criteria the
evaluation body should use to examine closed. Note: the merit of an ICANN gTLD
application for
such a reserved name/protocol switch. For example, process is large scale
prior deployment an acceptable criteria? A number of people have
clearly answered "no" to that question as it would only encourage
"squatting" on names.

However, in the case of .local and .onion, those particular domain
names were already in use by a substantial population of end-users at
the time they were requested to be added to the Registry. Rightly or
not, the practical cost of a transition away from the requested
strings was argued as a justification for their inclusion described in the
registry.

6.2.3. Name evaluation

With regard to the actual choice of name, [RFC6761] is silent. applicant guide book
[GUIDEBOOK].

4. The
answers to the seven questions are expected to tell how a name,
presumably already chosen outside of the process, might be handled if
it is determined to be a "special use" name. However, it major risk is silent
on how to choose a name or how to evaluate having a specific proposed name.

Going back to conflict when both the IETF process used for the evaluation of .local and
.onion, one might ask the following questions:

For example, what consideration have there been in the
intellectual property rights in the reservation of a name in this
Special Use Name registry, and what procedures should be followed
in the case of a dispute over the rights ICANN
want to use a name in this
manner? Also, to what extent could such a reservation of a name
in this Special Use Names registry be used to block competing
interests and/or competing technologies? What are the competition
and consumer issues that need to be considered if the reservation
of a name in this registry causes some form of exclusive access
and reduced competitive access, same or where there is no ability for
consumers to exercise choice in a situation where providers
compete in the offering of services?

A related consideration is that the current process of admission
to the Special Use Name registry appears to admit similar strings. There exist no formal
assessment of environmental impact. Is the name that is proposed
to be entered into this registry already being used in local
contexts, with or without an association with DNS name resolution,
such that its use as a reserved name through an entry in this
registry, and its continued use in local contexts could cause harm
to users? To what extent can this impact be assessed, and what
level of impact is considered acceptable?

While the "seven questions" relate to altered behaviors by
specific audiences defined
cooperation between ICANN and users of names there is no explicit
consideration of the security in this process. Is the
registration of such a name a "safe" action for the IETF to take?
To what extent could the use of avoid this reserved name problem.

5. There might be used in a
hostile or malicious manner? What measures have been taken to
mitigate or otherwise address such potential vulnerabilities?

ICANN has created an entire set of groups, organizations, committees,
processes and procedures to deal with the evaluation of applied for
new TLDs, complete with a cadre of lawyers and policy people. Unless
the limited concerns if IETF were willing to do the same, it would have a hard time
performing evaluation of the strings themselves, distinct from the
evaluation of the technology behind the name resolution system.

An alternate view has been expressed that such a process is not
necessary because the IESG is the body that makes the decision on a
specific name reserved by [RFC6761], and the IETF has reserve a workable
appeal process to deal with any potential issues. However, looking
at the level of contention created in the ICANN process around the
choice of certain names, serious doubts have been expressed to the
scalability and ultimate viability string
outside of such an appeal process.

6.3. The ICANN process to evaluate names

Section 4.3 of [RFC2860] says:

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.

This remains as true today as when it was written (2000). Domain
names have a number of considerations that have complex policy issues
that ICANN deals with and which the IETF may not be well equipped to
handle. gTLD round. The next ICANN process applicant have to go through to get a name is
described in the gTLD applicant guide
book [GUIDEBOOK], which is a 338
page document. It should however be noted that the current round of
gTLD application is closed and rules may differ in the next round if
and when it happens.

Considerations include, but are not limited to:

Geographical During the most recent round of new gTLD applications,
there were a number of applications for so call "geographic"
terms. These included applications for .amazon and .patagonia.
The .amazon application in particular was controversial - the
governments of Brazil and Peru requested that ICANN's Governmental
Advisory Committee (GAC) to issue a warning that granting .amazon
to Amazon would "prevent the use of this domain for purposes of
public interest related to the protection, promotion, and
awareness raising on issues related simply refer to the Amazon biome." The
IETF existing list at publication time.
However, there is not well suited to evaluating this sort of issue.

Brands / Trademark law If Wile E. Coyote approached the IETF
requesting that the IETF reserve .acme, a trademark held by a
large corporation making anvils and giant slingshots, the IETF
could become embroiled in trademark lawsuit - and even possibility of conflict if the an IETF
reservation were not, we have enough armchair lawyers that the discussions
would be extremely annoying :-). Closely related to this issue is
"protected designation of origin (PDO)" - for example, Champagne.

String similarity ICANN has happen during an entire process for evaluating the
string similarity / confusability between applied for (and
current) strings - for example, under what conditions would the
IETF ICANN gTLD round. A
hypothetical case study could be able to make somebody trying a determination if someone attempted to use
[RFC6761] to reserve .c0m?

International Organization Names Certain names and organizations get
additional protection under trademark law - well known examples denial of
this are the RedCross/RedCrescent and the International Olympic
Committee (IOC). Whether or not this should be
service attack early in the case is well
outside anything that ICANN application process by asking
the IETF should have an opinion on but,
undoubtedly, there are many within the community who will have an
opinion (and will want to argue it at length).

Offensive Terms There are reserved a huge range of these, from the obscure /
archaic (waesucks, gadsbudlikins) to the more obvious and current.
Certain terms are sufficiently offensive that the IETF would have string sought after by a hard time coming to any useful consensus (other then "Eeeew!")

7. competitor.

5. Security Considerations

This document aims to provide a problem statement that will inform
future work. While security and privacy are fundamental
considerations, this document expects that future work will include
such analysis, and hence no attempt is made to do so here. See among
other places [SAC-057]

Reserving names has been presented as a way to prevent leakage into
the DNS. However, instructing resolvers to not forward the queries
(and/or by instructing authoritative servers not to respond) is not a
guarantee that such leakage will be prevented. The security (or
privacy) of an application MUST NOT rely on names not being exposed
to the Internet DNS resolution system.

6. IANA Considerations

This document has no IANA actions.

7. Acknowledgements

Thanks to Paul Hoffman for a large amount of editing.

10.

8. References

10.1.

8.1. Normative References

[IANA-SPECIAL-USE]
IANA, "Special-Use Domain Names", 2016,
<https://www.iana.org/assignments/special-use-domain-
names>.

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.

[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860,
DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>.

[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>.

[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.

[RFC7686] Appelbaum, J.

[RFC7788] Stenberg, M., Barth, S., and A. Muffett, "The ".onion" Special-Use
Domain Name", P. Pfister, "Home Networking
Control Protocol", RFC 7686, 7788, DOI 10.17487/RFC7686, October
2015, <http://www.rfc-editor.org/info/rfc7686>.

10.2. 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>.

8.2. Informative References

[GUIDEBOOK]
ICANN, "gTLD Application Guidebook", June 2012,
<https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>.

[HUSTON] Huston, G., "What's in a Name?", December 2015,
<http://www.circleid.com/posts/20151222_whats_in_a_name/>.

[I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-02
(work in progress), January 2016.

[NEW-GTLD]
ICANN, "New Generic Top-Level Domains", 2016,
<https://newgtlds.icann.org/>.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.

[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <http://www.rfc-editor.org/info/rfc2826>.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.

[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>.

[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>.

[SAC-057] ICANN Security and Stability Advisory Committee, "SSAC
Advisory on Internal Name Certificates", March 2013,
<https://www.icann.org/en/system/files/files/sac-
057-en.pdf>.

Appendix A. Editorial Notes

This section (and sub-sections) to be removed prior to publication.

A.1. Venue

An appropriate forum for discussion of this draft is for now the
DNSOP WG.

A.2. Pithy Quotes from History

The question has arisen as to how the toplevel naming authority
decides who gets a toplevel name and who must get by with a non-
toplevel name. The suggestion was made by MOCKAPETRIS@USC-ISIF
that perhaps the existing toplevel nameholders might vote on
whether the applicant for a new toplevel name should be granted,
with a majority needed for approval. It seems to me this might
produce a clique whereby whoever initially gains power will hold
it and prevent its "enemies" from getting in too. This will make
the toplevel rather less than universal.

(E-mail from Robert Elton Maas to the namedroppers mailing list on 9
November 1983)

My basic point is that as a world-wide network evolves it is
ridiculous to force people to name resources in terms of one
static hierarchy which very closely resembles the current
internetwork topology (as the current scheme does). What we are
eventually going to require is a distributed expert for making
sense out of a name someone hands it. There will be no simple
algorithm to be written on one page of an RFC that will suffice to
resolve a name. Rather, a number of heuristics will let a
resolver make sense out of a given name by querying other experts
which it suspects may be more knowledgeable about the name than it
is, or by forwarding a piece of mail to an expert which is at
least one level closer to the destination in some hierarchy.

(E-mail from Peter Karp to the namedroppers mailing list on 8
February 1984)

A.3. Change History

A.3.1.

A.2.1. draft-adpkja-special-names-problem-00

Initial draft circulated for comment.

Appendix B. Change history

[ RFC Editor: Please remove this section before publication]

-01 to -02:

o A very large number of readability / grammar / reference fixes
from Paul Hoffman.

-00 to -01:

o Significant readability changes.

-00:

o Initial draft circulated for comment.

Authors' Addresses

Joe Abley
Dyn, Inc.
103-186 Albert Street
London, ON N6A 1M1
Canada

Phone: +1 519 670 9327

Geoff Huston
APNIC

Email: jabley@dyn.com gih@apnic.net

Peter Koch
DENIC eG
Kaiserstrasse 75-77
Frankfurt 60329
Germany

Email: pk@denic.de

Alain Durand
ICANN

Email: alain.durand@icann.org

Warren Kumari
Google

Email: warren@kumari.net