draft-ietf-dnsop-sutld-ps-03.txt   draft-ietf-dnsop-sutld-ps-04.txt 
Network Working Group T. Lemon Network Working Group T. Lemon
Internet-Draft Nominum, Inc. Internet-Draft Nominum, Inc.
Intended status: Informational R. Droms Intended status: Informational R. Droms
Expires: September 14, 2017 Expires: November 16, 2017
W. Kumari W. Kumari
Google Google
March 13, 2017 May 15, 2017
Special-Use Domain Names Problem Statement Special-Use Domain Names Problem Statement
draft-ietf-dnsop-sutld-ps-03 draft-ietf-dnsop-sutld-ps-04
Abstract Abstract
The Special-Use Domain Names IANA registry policy defined in RFC 6761 The Special-Use Domain Names IANA registry policy defined in RFC 6761
has been shown through experience to present unanticipated has been shown through experience to present unanticipated
challenges. This memo presents a list, intended to be comprehensive, challenges. This memo presents a list, intended to be comprehensive,
of the problems that have been identified. In addition it reviews of the problems that have been identified. In addition it reviews
the history of Domain Names and summarizes current IETF publications the history of Domain Names and summarizes current IETF publications
and some publications from other organizations relating to Special- and some publications from other organizations relating to Special-
Use Domain Names. Use Domain Names.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on November 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problems associated with Special-Use Domain Names . . . . . . 4 3. Problems associated with Special-Use Domain Names . . . . . . 4
4. Existing Practice Regarding Special-Use Domain Names . . . . 9 4. Existing Practice Regarding Special-Use Domain Names . . . . 9
4.1. Primary Special-Use Domain Name Documents . . . . . . . . 9 4.1. Primary Special-Use Domain Name Documents . . . . . . . . 9
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 9 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10
4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 11 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 11
4.1.3. MoU Concerning the Technical Work of the IANA . . . . 12 4.1.3. MoU Concerning the Technical Work of the IANA . . . . 13
4.1.4. Liaison Statement on Technical Use of Domain 4.1.4. Liaison Statement on Technical Use of Domain
Names . . . . . . . . . . . . . . . . . . . . . . . . 13 Names . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Secondary documents relating to the Special-Use 4.2. Secondary documents relating to the Special-Use
Domain Name question . . . . . . . . . . . . . . . . . . 14 Domain Name question . . . . . . . . . . . . . . . . . . 14
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 14
4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 14 4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 14
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 15 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 15
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 15 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 15
4.2.5. SSAC Advisory on the Stability of the Domain 4.2.5. SSAC Advisory on the Stability of the Domain
Namespace . . . . . . . . . . . . . . . . . . . . . . 15 Namespace . . . . . . . . . . . . . . . . . . . . . . 15
4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis . . . . . . . . . . . . . . . . . . . . . . 16 Synthesis . . . . . . . . . . . . . . . . . . . . . . 16
4.2.7. Additional Reserved Top Level Domains . . . . . . . . 16 4.2.7. Additional Reserved Top Level Domains . . . . . . . . 16
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
One of the key services required to use the Internet is name One of the key services required to use the Internet is name
resolution. Name resolution is the process of translating a symbolic resolution. Name resolution is the process of translating a symbolic
name into some object or set of objects to which the name refers, name into some object or set of objects to which the name refers,
most typically one or more IP addresses. These names are often most typically one or more IP addresses. These names are often
referred to as Domain Names. When reading this document, care must referred to as Domain Names. When reading this document, care must
be taken to not assume that the term Domain Name implies the use of be taken to not assume that the term Domain Name implies the use of
the Domain Name System [RFC1034] for resolving these names. An the Domain Name System [RFC1034] for resolving these names. An
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Special-Use Domain Names [RFC6761] created an IANA registry for Special-Use Domain Names [RFC6761] created an IANA registry for
Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding
to the registry, and made some suggestions about how those policies to the registry, and made some suggestions about how those policies
might be implemented. Since the publication of RFC 6761, the IETF might be implemented. Since the publication of RFC 6761, the IETF
has been asked to designate several new Special-Use Domain Names in has been asked to designate several new Special-Use Domain Names in
this registry. During the evaluation process for these Special-Use this registry. During the evaluation process for these Special-Use
Domain Names, the IETF encountered several different sorts of issues. Domain Names, the IETF encountered several different sorts of issues.
Because of this, the IETF has decided to investigate the problem and Because of this, the IETF has decided to investigate the problem and
decide if and how the RFC 6761 process can be improved, or whether it decide if and how the RFC 6761 process can be improved, or whether it
should be deprecated. should be deprecated. The IETF DSNOP working group charter was
extended to include conducting a review of the process for adding
names to the registry that is defined in RFC 6761. This document is
a product of that review.
Based on current ICANN and IETF practice, including RFC 6761, there Based on current ICANN and IETF practice, including RFC 6761, there
are several different types of names in the root of the Domain are several different types of names in the root of the Domain
Namespace: Namespace:
o Reserved by the IETF for technical purposes o Reserved by the IETF for technical purposes
o Assigned by ICANN to the public DNS root; some names reserved by o Assigned by ICANN to the public DNS root; some names reserved by
the IETF for technical purposes may appear in the Global DNS root the IETF for technical purposes may appear in the Global DNS root
for reasons pertaining to the operation of the DNS for reasons pertaining to the operation of the DNS
skipping to change at page 4, line 46 skipping to change at page 4, line 49
identified to which Special-Use Domain Names are a solution and identified to which Special-Use Domain Names are a solution and
enumerate all of the problems that have been raised in the process of enumerate all of the problems that have been raised in the process of
trying to use RFC 6761 as it was intended. As some of those problems trying to use RFC 6761 as it was intended. As some of those problems
may fall into both categories, this document makes no attempt to may fall into both categories, this document makes no attempt to
categorize the problems. categorize the problems.
There is a broad diversity of opinion about this set of problems. There is a broad diversity of opinion about this set of problems.
Not every participant agrees that each of the problems enumerated in Not every participant agrees that each of the problems enumerated in
this document is actually a problem. This document takes no position this document is actually a problem. This document takes no position
on the relative validity of the various problems that have been on the relative validity of the various problems that have been
enumerated. Its focused purposes are to enumerate those problems, enumerated. The sole purposes of the document are to enumerate those
provide the reader with context for thinking about them and provide a problems, provide the reader with context for thinking about them and
context for future discussion of solutions. provide a context for future discussion of solutions.
This is the list of problems: This is the list of problems:
o No formal coordination process exists between the IETF and ICANN o No formal coordination process exists between the IETF and ICANN
as they follow their respective name assignment processes (see as they follow their respective name assignment processes (see
Section 4.1.3). The lack of coordination complicates the Section 4.1.3). The lack of coordination complicates the
management of the root of the Domain Namespace and could lead to management of the root of the Domain Namespace and could lead to
conflicts in name assignments [SDO-ICANN-SAC090]. conflicts in name assignments [SDO-ICANN-SAC090].
o There is no explicit scoping as to what can constitute a o There is no explicit scoping as to what can constitute a
skipping to change at page 8, line 14 skipping to change at page 8, line 21
is for the IETF to take responsibility for the name and designate is for the IETF to take responsibility for the name and designate
it for "technical use". There are other potential uses for Domain it for "technical use". There are other potential uses for Domain
Names that should be recorded in the registry, but for which the Names that should be recorded in the registry, but for which the
IETF should not take responsibility. IETF should not take responsibility.
o The IETF may in some cases see the need to document that a name is o The IETF may in some cases see the need to document that a name is
in use without claiming that the use of the name is the IETF's use in use without claiming that the use of the name is the IETF's use
of the name. No mechanism exists in the current registry to mark of the name. No mechanism exists in the current registry to mark
names in this way. names in this way.
o There is no formal mechanism that ensures that we check to make o There is no formal process during any of the review stages for a
sure that a document being considered for publication does not document in which a check is made to ensure that the document does
unintentionally violate the IETF process for adding Special-Use not unintentionally violate IETF process for adding special-use
Domain Names to the registry (e.g., RFC 7788 [RFC7788]). domain names to the registry, as was the case, for example, in RFC
7788 [RFC7788].
o Use of the registry is inconsistent--some Special-Use Domain Name o Use of the registry is inconsistent -- some Special-Use Domain
RFCs specify registry entries, some don't; some specify Name RFCs specify registry entries, some don't; some specify
delegation, some don't. delegation, some don't.
o There exists no safe, non-process-violating mechanism for ad-hoc o There exists no safe, non-process-violating mechanism for ad-hoc
assignment of Special-Use Domain Names. assignment of Special-Use Domain Names.
o It is generally assumed that protocols that need a Special-Use o It is generally assumed that protocols that need a Special-Use
Domain Name need a mnemonic, single-label, human-readable Special- Domain Name need a mnemonic, single-label, human-readable Special-
Use Domain Name, for use in user interfaces such as command lines Use Domain Name, for use in user interfaces such as command lines
or URL entry fields. While this assumption is correct in some or URL entry fields. While this assumption is correct in some
cases, it is likely not correct in all cases; for example, in cases, it is likely not correct in all cases; for example, in
skipping to change at page 9, line 19 skipping to change at page 9, line 26
specific Special-Use Domain Name? specific Special-Use Domain Name?
The problems we have stated here represent the current understanding The problems we have stated here represent the current understanding
of the authors of the document as to the complete set of problems of the authors of the document as to the complete set of problems
that have been identified during discussion by the working group on that have been identified during discussion by the working group on
this topic. The remainder of this document provides additional this topic. The remainder of this document provides additional
context that will be needed for reasoning about these problems. context that will be needed for reasoning about these problems.
4. Existing Practice Regarding Special-Use Domain Names 4. Existing Practice Regarding Special-Use Domain Names
There are three primary and numerous secondary documents to consider There are three primary (see Section 4.1) and numerous secondary
when thinking about the Special-Use Domain Names process. (Section 4.2) documents to consider when thinking about the Special-
Use Domain Names process.
How names are resolved is ambiguous, in the sense that some names are How names are resolved is ambiguous, in the sense that some names are
Special-Use Domain names that require special handling, and some Special-Use Domain names that require special handling, and some
names can be resolved using the DNS protocol with no special names can be resolved using the DNS protocol with no special
handling. handling.
The assignment of Internet Names is not under the sole control of any The assignment of Internet Names is not under the sole control of any
one organization. IETF has authority in some cases, but only with one organization. IETF has authority in some cases, but only with
respect to "technical uses." ICANN at present is the designated respect to "technical uses." ICANN at present is the designated
administrator of the root zone, but generally not of zones other than administrator of the root zone, but generally not of zones other than
the root zone. And neither of these authorities can in any practical the root zone. Neither of these authorities can in any practical
sense exclude the practice of ad-hoc use of names. This can be done sense exclude the practice of ad-hoc use of names. Unauthorized use
by any entity that has control over one or more name servers or of domain names can be accomplished by any entity that has control
resolvers, in the context of any hosts and services that that entity over one or more name servers or resolvers, in the context of any
operates. It can also be done by authors of software who decide that hosts and services that that entity operates. It can also be
a Special-Use Domain Name is the right way to indicate the use of an accomplished by authors of software who decide that a Special-Use
alternate resolution mechanism. Domain Name is the right way to indicate the use of an alternate
resolution mechanism.
4.1. Primary Special-Use Domain Name Documents 4.1. Primary Special-Use Domain Name Documents
The primary documents are considered primary because they directly The primary documents are considered primary because they directly
address the IETF's past thoughts on this topic in a general way, and address the IETF's past thoughts on this topic in a general way, and
also because they describe what the IETF does in practice. Only one also because they describe what the IETF does in practice. Only one
of these documents is an IETF consensus document. of these documents is an IETF consensus document.
4.1.1. IAB Technical Comment on the Unique DNS Root 4.1.1. IAB Technical Comment on the Unique DNS Root
This document [RFC2826] is not an IETF consensus document, and This document [RFC2826] is not an IETF consensus document, and
appears to have been written to address a different problem than the appears to have been written to address a different problem than the
Special-Use Domain Name problem. However, it speaks directly to Special-Use Domain Name problem. However, it speaks directly to
several of the key issues that must be considered, and of course several of the key issues that must be considered, and, coming as it
coming as it does from the IAB, it is rightly treated as having does from the IAB, it is rightly treated as having significant
significant authority despite not being an IETF consensus document. authority despite not being an IETF consensus document.
This document should be considered required reading for IETF This document should be considered required reading for IETF
participants who wish to express an informed opinion on the topic of participants who wish to express an informed opinion on the topic of
Special-Use Domain Names. The main points that appear relevant to Special-Use Domain Names. The main points that appear relevant to
the Special-Use Domain Names problem are: the Special-Use Domain Names problem are:
o The Internet requires a globally unique namespace o The Internet requires a globally unique namespace
o Private networks may operate private namespaces, but still require o Private networks may operate private namespaces, but still require
that names in the public namespace be globally unique. that names in the public namespace be globally unique.
skipping to change at page 10, line 31 skipping to change at page 10, line 40
symbolic references that have local meaning and references that symbolic references that have local meaning and references that
have global meaning. Users may therefore share references that have global meaning. Users may therefore share references that
incorporate Domain Names with no global meaning (for example, a incorporate Domain Names with no global meaning (for example, a
URL of 'http://mysite.example.corp', where 'example.corp' is a URL of 'http://mysite.example.corp', where 'example.corp' is a
domain used privately and informally as described in domain used privately and informally as described in
[SDO-ICANN-COLL]). [SDO-ICANN-COLL]).
o Such references might refer to the object the user intends to o Such references might refer to the object the user intends to
share within that user's context, but either refer to some other share within that user's context, but either refer to some other
object any recipient's context, or might not refer to any object object any recipient's context, or might not refer to any object
at all in a recipient's context. The effect of this is that the at all in a recipient's context. The effect of this reference
user's intended communication will not be able to be understood by escaping the context in which it is valid is that the user's
the recipients of the communication. intended communication will not be able to be understood by the
recipients of the communication.
o This same problem can also occur simply because a single user o This same problem can also occur when a single user copies a name
copies a name from one context in which it has one meaning, into a from one context in which it has one meaning, into a different
different context in which it has a different meaning-- for context in which it has a different meaning -- for example copying
example copying a '.onion' Domain Name out of a Tor Browser [TOR], a '.onion' Domain Name out of a Tor Browser [TOR], where it has
where it has meaning, and pasting this name into an ssh client meaning, and pasting this name into an ssh client that doesn't
that doesn't support connecting over the Tor network. support connecting over the Tor network.
To boil this down even further, we can take the following advice from We can summarize the advice in this document as follows:
this document:
o Domain Names with unambiguous global meaning are preferable to o Domain Names with unambiguous global meaning are preferable to
Domain Names with local meaning which will be ambiguous. Domain Names with local meaning which will be ambiguous.
Nevertheless both globally-meaningful and locally-special names Nevertheless both globally-meaningful and locally-special names
are in use and must be supported. are in use and must be supported.
o At the time of the writing of this document the IAB was of the o At the time of the writing of this document the IAB was of the
opinion that there might well be more than one name resolution opinion that there might well be more than one name resolution
protocol used to resolve Domain Names. protocol used to resolve Domain Names.
4.1.2. Special-Use Domain Names 4.1.2. Special-Use Domain Names
The second important document is "Special-Use Domain Names" The second important document is "Special-Use Domain Names"
[RFC6761]. RFC 6761 represents the current IETF consensus on [RFC6761]. RFC 6761 represents the current IETF consensus on
designating and recording Special-Use Domain Names. The IETF has designating and recording Special-Use Domain Names. The IETF has
experienced problems with the designation process described in RFC experienced problems with the designation process described in RFC
6761; these concerns motivate this document. Again, familiarity with 6761; these concerns motivate this document. Familiarity with RFC
RFC 6761 is a prerequisite for having an informed opinion on the 6761 is a prerequisite for having an informed opinion on the topic of
topic of Special-Use Domain Names. Special-Use Domain Names.
RFC 6761 defines two aspects of Special-Use Domain Names: designating RFC 6761 defines two aspects of Special-Use Domain Names: designating
a Domain Name to have a special purpose and registering that special a Domain Name to have a special purpose and registering that special
use in the Special-Use Domain Names registry. The designation use in the Special-Use Domain Names registry. The designation
process is defined in a single sentence (RFC 6761, section 4): process is defined in a single sentence (RFC 6761, section 4):
If it is determined that special handling of a name is required in If it is determined that special handling of a name is required in
order to implement some desired new functionality, then an IETF order to implement some desired new functionality, then an IETF
"Standards Action" or "IESG Approval" specification [RFC5226] MUST "Standards Action" or "IESG Approval" specification [RFC5226] MUST
be published describing the new functionality. be published describing the new functionality.
This sentence implies that any designation of a Special-Use Domain This sentence requires that any designation of a Special-Use Domain
Name is subject to the same open review and consensus process as used Name is subject to the same open review and consensus process as used
to produce and publish all other IETF specifications. to produce and publish all other IETF specifications.
The registration process is a purely mechanical process, in which the The registration process is a purely mechanical process, in which the
existence of the newly designated Special-Use Domain Name is existence of the newly designated Special-Use Domain Name is
recorded, with a pointer to a section in the relevant specification recorded, with a pointer to a section in the relevant specification
document that defines the ways in which special handling is to be document that defines the ways in which special handling is to be
applied to the name. applied to the name.
RFC 6761 provided the process whereby Multicast DNS [RFC6762] RFC 6761 provided the process whereby Multicast DNS [RFC6762]
skipping to change at page 13, line 43 skipping to change at page 13, line 51
The point here is not to say what the implications of this statement The point here is not to say what the implications of this statement
in the MoU are, but rather to call the reader's attention to the in the MoU are, but rather to call the reader's attention to the
existence of this statement. existence of this statement.
4.1.4. Liaison Statement on Technical Use of Domain Names 4.1.4. Liaison Statement on Technical Use of Domain Names
As a result of processing requests to add names to the Special-Use As a result of processing requests to add names to the Special-Use
Domain Name registry, as documented in Domain Name registry, as documented in
[I-D.chapin-additional-reserved-tlds] and [I-D.chapin-additional-reserved-tlds] and
[I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review [I-D.grothoff-iesg-special-use-p2p-names], a review was chartered of
of the process defined in RFC 6761 for adding names to the registry. the process defined in RFC 6761 for adding names to the registry (as
This review was identified as in the charter of the IETF DNSOP explained earlier). The Liaison Statement [SDO-IAB-ICANN-LS]
working group, and the review has been conducted in that working notified ICANN of the review, affirmed that the discussion would be
group. The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of "open and transparent to participation by interested parties" and
the review, affirmed that the discussion would be "open and explicitly invited members of the ICANN community to participate.
transparent to participation by interested parties" and explicitly
invited members of the ICANN community to participate.
This document is a product of the IETF DNSOP working group review of
the registry process in RFC 6761.
4.2. Secondary documents relating to the Special-Use Domain Name 4.2. Secondary documents relating to the Special-Use Domain Name
question question
In addition to these documents, there are several others with which In addition to these documents, there are several others with which
participants in this discussion should be familiar. participants in this discussion should be familiar.
4.2.1. Multicast DNS 4.2.1. Multicast DNS
Multicast DNS [RFC6762] defines the Multicast DNS protocol, which Multicast DNS [RFC6762] defines the Multicast DNS protocol, which
skipping to change at page 16, line 15 skipping to change at page 16, line 15
4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
[RFC7050] is an example of a document that successfully used the RFC [RFC7050] is an example of a document that successfully used the RFC
6761 process to designate '.ipv4only.arpa' as a Special-Use Domain 6761 process to designate '.ipv4only.arpa' as a Special-Use Domain
Name; in this case the process worked smoothly and without Name; in this case the process worked smoothly and without
controversy. controversy.
Unfortunately, while the IETF process worked smoothly, in the sense Unfortunately, while the IETF process worked smoothly, in the sense
that there was little controversy or delay in approving the new use, that there was little controversy or delay in approving the new use,
it did not work correctly: the name 'ipv4only.arpa' was never added it did not work correctly: the name "ipv4only.arpa" was never added
to the Special-Use Domain Names registry. This appears to have to the Special-Use Domain Names registry. This appears to have
happened because the IAB was able to simply add the name to the .ARPA happened because the document did not explicitly request the addition
zone, which the IAB administers. This is an illustration of one of of an entry for "ipv4only.arpa" in the SUDN registry. This is an
the problems that we have with the 6761 process: it is apparently illustration of one of the problems that we have with the 6761
fairly easy to miss the step of adding the name to the registry. process: it is apparently fairly easy to miss the step of adding the
name to the registry.
4.2.7. Additional Reserved Top Level Domains 4.2.7. Additional Reserved Top Level Domains
Additional Reserved Top Level Domains Additional Reserved Top Level Domains
[I-D.chapin-additional-reserved-tlds] is an example of a document [I-D.chapin-additional-reserved-tlds] is an example of a document
that attempted to reserve several TLDs identified by ICANN as that attempted to reserve several TLDs identified by ICANN as
particularly at risk for collision as Special-Use Domain Names with particularly at risk for collision as Special-Use Domain Names with
no documented use. This attempt failed. no documented use. This attempt did not advance in the IETF process.
Although this document failed to gain consensus to publish, the need Although this document failed to gain consensus to publish, the need
it was intended to fill still exists. Unfortunately, although a fair it was intended to fill still exists. Unfortunately, although a fair
amount is known about the use of these names, no document exists that amount is known about the use of these names, no RFC documents how
documents how they are used, and why it would be a problem to they are used, and why it would be a problem to delegate them.
delegate them. Additionally, to the extent that the uses being made Additionally, to the extent that the uses being made of these names
of these names are valid, no document exists indicating when it might are valid, no document exists indicating when it might make sense to
make sense to use them, and when it would not make sense to use them. use them, and when it would not make sense to use them.
RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the
default name for name resolution relative to a home network context. default name for name resolution relative to a home network context.
Although, as defined in RFC 7788, ".home" is a Special-Use Domain Although, as defined in RFC 7788, ".home" is a Special-Use Domain
Name, RFC 7788 did not follow the process in RFC 6761 and request the Name, RFC 7788 did not follow the process in RFC 6761 and request the
addition of ".home" to the IANA Special-Use Domain Name registry. addition of ".home" to the IANA Special-Use Domain Name registry.
Additionally, ".home" is an example of an attempt to reuse a Domain Additionally, ".home" is an example of an attempt to reuse a Domain
Name that has already been put into use for other purposes without Name that has already been put into use for other purposes without
following established processes[SDO-ICANN-COLL], which further following established processes[SDO-ICANN-COLL], which further
complicates the situation. At the time this document was written, complicates the situation. At the time this document was written,
skipping to change at page 21, line 12 skipping to change at page 21, line 12
Domains", draft-chapin-additional-reserved-tlds-02 (work Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015. in progress), March 2015.
[I-D.grothoff-iesg-special-use-p2p-names] [I-D.grothoff-iesg-special-use-p2p-names]
Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and
L. Ryge, "Special-Use Domain Names of Peer-to-Peer L. Ryge, "Special-Use Domain Names of Peer-to-Peer
Systems", draft-grothoff-iesg-special-use-p2p-names-04 Systems", draft-grothoff-iesg-special-use-p2p-names-04
(work in progress), January 2015. (work in progress), January 2015.
[I-D.lewis-domain-names] [I-D.lewis-domain-names]
Lewis, E., "Domain Names", draft-lewis-domain-names-05 Lewis, E., "Domain Names, A Case for Clarifying", draft-
(work in progress), February 2017. lewis-domain-names-06 (work in progress), March 2017.
[SDO-CABF-INT] [SDO-CABF-INT]
CA/Browser Forum, "Guidance on the Deprecation of Internal CA/Browser Forum, "Guidance on the Deprecation of Internal
Server Names and Reserved IP Addresses", June 2012, Server Names and Reserved IP Addresses", June 2012,
<https://www.digicert.com/internal-names.htm>. <https://www.digicert.com/internal-names.htm>.
[SDO-ICANN-COLL] [SDO-ICANN-COLL]
Interisle Consulting Group, LLC, "Name Collisions in the Interisle Consulting Group, LLC, "Name Collisions in the
DNS", August 2013, DNS", August 2013,
<https://www.icann.org/en/system/files/files/name- <https://www.icann.org/en/system/files/files/name-
skipping to change at page 22, line 19 skipping to change at page 22, line 19
[IETF-PRO-51] [IETF-PRO-51]
Internet Engineering Task Force, "Proceedings of the 51st Internet Engineering Task Force, "Proceedings of the 51st
IETF", August 2001, IETF", August 2001,
<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>. <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[TOR] The Tor Project, "Tor", 2017, [TOR] The Tor Project, "Tor", 2017,
<https://www.torproject.org>. <https://www.torproject.org>.
Appendix A. Change Log. Appendix A. Change Log.
-03 to -04:
o Issue #72: Corrected original text to reflect that RFC 7050
neglected to request an SUDN registry entry for "ipv4only.arpa",
but any inference about the cause for the oversight would be
speculation.
o Issue #69: Edited Joel's suggested text.
o Issue #67: Minor change to Joel's suggested text.
o Issue #66: Edited second text update suggested by Joel and
reverted third change back to the original text.
o Issue #64: Minor changes to text suggested by Joel.
o Issue #61: Minor edit based on authors' consensus in response to
Joel's comment.
o Addressed Joel / Benoit's AD comments. See GH issues
-02 to -03 (in Github): -02 to -03 (in Github):
Passes idnits except for errors resulting from a reference to an Passes idnits except for errors resulting from a reference to an
RFC 2119 keyword and a citation of RFC 5226 with no matching RFC 2119 keyword and a citation of RFC 5226 with no matching
reference in quoted text at line 493. reference in quoted text at line 493.
Issue #60: Add new section "6. Summary" -- Petr Spacek
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/60
Issue #57: Document needs an "Security Considerations" section Issue #57: Document needs an "Security Considerations" section
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/57 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/57
Numerous editorial changes for consistency; e.g. use "Special-Use Numerous editorial changes for consistency; e.g. use "Special-Use
Domain Names" throughout. Domain Names" throughout.
Issue #58: Document needs an "IANA Considerations" section Issue #58: Document needs an "IANA Considerations" section
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/58 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/58
Issue #39: Overlapping bullets in Section 3, with proposed Issue #39: Overlapping bullets in Section 3, with proposed
restructuring -- Russ Housley https://github.com/Abhayakara/draft- restructuring -- Russ Housley https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/39 tldr-sutld-ps/issues/39
 End of changes. 28 change blocks. 
69 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/