draft-ietf-dnsop-sutld-ps-05.txt   draft-ietf-dnsop-sutld-ps-06.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: December 8, 2017 Expires: December 29, 2017
W. Kumari W. Kumari
Google Google
June 6, 2017 June 27, 2017
Special-Use Domain Names Problem Statement Special-Use Domain Names Problem Statement
draft-ietf-dnsop-sutld-ps-05 draft-ietf-dnsop-sutld-ps-06
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 December 8, 2017. This Internet-Draft will expire on December 29, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . 10
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10 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 . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 Names . . . . . . . . . . . . . . . . . . . . . . . . 14
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 . . . . 15 4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 15
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 . . . . . . . . . . . . . . 16
4.2.5. SSAC Advisory on the Stability of the Domain 4.2.5. SSAC Advisory on the Stability of the Domain
Namespace . . . . . . . . . . . . . . . . . . . . . . 16 Namespace . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . 17
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Informative References . . . . . . . . . . . . . . . . . . . 19 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 22 10. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 5, line 7 skipping to change at page 5, line 12
on the relative validity of the various problems that have been on the relative validity of the various problems that have been
enumerated, nor on the organization responsible for addressing each enumerated, nor on the organization responsible for addressing each
individual problem, if it is to be addressed. The sole purposes of individual problem, if it is to be addressed. The sole purposes of
the document are to enumerate those problems, provide the reader with the document are to enumerate those problems, provide the reader with
context for thinking about them and provide a context for future context for thinking about them and provide a context for future
discussion of solutions, regardless of whether such solutions may be discussion of solutions, regardless of whether such solutions may be
work for IETF, ICANN, IANA or some other group. work for IETF, ICANN, IANA or some other group.
This is the list of problems: This is the list of problems:
o No formal coordination process exists between the IETF and ICANN o Although the IETF and ICANN have a liaison relationship through
as they follow their respective name assignment processes (see 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 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
"technical use" [RFC2860] and what cannot, and there is also no "technical use" [RFC2860] and what cannot, and there is also no
consensus within the IETF as to what this term means. consensus within the IETF as to what this term means.
o Not all developers of protocols on the internet agree that o Not all developers of protocols on the internet agree that
authority over the entire Domain Namespace should reside solely authority over the entire Domain Namespace should reside solely
skipping to change at page 8, line 28 skipping to change at page 8, line 32
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 process during any of the review stages for a o There is no formal process during any of the review stages for a
document in which a check is made to ensure that the document does document in which a check is made to ensure that the document does
not unintentionally violate IETF process for adding special-use not unintentionally violate IETF process for adding special-use
domain names to the registry, as was the case, for example, in RFC domain names to the registry, as was the case, for example, in RFC
7788 [RFC7788]. 7788 [RFC7788].
o Use of the registry is inconsistent -- some Special-Use Domain o Use of the registry is inconsistent -- some Special-Use Domain
Name RFCs specify registry entries, some don't; some specify Name RFCs specifically add registry entries, some don't; some
delegation, some don't. specify how and whether special-use name delegations should be
done, 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
applications where the DNS name is never visible to a user. applications where the DNS name is never visible to a user.
skipping to change at page 13, line 6 skipping to change at page 13, line 8
RFC 6761 does not limit Special-Use Domain Names to TLDs. However, RFC 6761 does not limit Special-Use Domain Names to TLDs. However,
at present, all Special-Use Domain Names registered in the IANA at present, all Special-Use Domain Names registered in the IANA
Special-Use Domain Names registry [SDO-IANA-SUDR] are either intended Special-Use Domain Names registry [SDO-IANA-SUDR] are either intended
to be resolved using the DNS protocol, or are TLDs, or both. That to be resolved using the DNS protocol, or are TLDs, or both. That
is, at present there exist no Special-Use Domain Names which require is, at present there exist no Special-Use Domain Names which require
special handling by stub resolvers and which are not at the top level special handling by stub resolvers and which are not at the top level
of the naming hierarchy. of the naming hierarchy.
One point to take from this is that there is already a requirement in One point to take from this is that there is already a requirement in
RFC 6762 that when stub resolvers encounter the special label, RFC 6762 that when a stub resolver encounters the special label,
'.LOCAL' at the top level of a domain name, they can only use the '.LOCAL' at the top level of a domain name, it can only use the mDNS
mDNS protocol be used for resolving that Domain Name. protocol to resolve that Domain Name.
4.1.3. MoU Concerning the Technical Work of the IANA 4.1.3. MoU Concerning the Technical Work of the IANA
There exists a Memorandum of Understanding [RFC2860] between the IETF There exists a Memorandum of Understanding [RFC2860] between the IETF
and ICANN (Internet Corporation for Assigned Names and Numbers) which and ICANN (Internet Corporation for Assigned Names and Numbers) which
discusses how names and numbers will be managed through the IANA discusses how names and numbers will be managed through the IANA
(Internet Assigned Numbers Authority). This document is important to (Internet Assigned Numbers Authority). This document is important to
the discussion of Special-Use Domain Names because, while it the discussion of Special-Use Domain Names because, while it
delegates authority for managing the Domain Name System Namespace delegates authority for managing the Domain Name System Namespace
generally to ICANN, it reserves to the IETF the authority that RFC generally to ICANN, it reserves to the IETF the authority that RFC
skipping to change at page 15, line 16 skipping to change at page 15, line 16
The .onion Special-Use Top-Level Domain Name [RFC7686] is important The .onion Special-Use Top-Level Domain Name [RFC7686] is important
because it is the most recent IETF action on the topic of Special-Use because it is the most recent IETF action on the topic of Special-Use
Domain Names; although it does not set new policy, the mere fact of Domain Names; although it does not set new policy, the mere fact of
its publication is worth thinking about. its publication is worth thinking about.
Two important points to consider about this document are that: Two important points to consider about this document are that:
o The IETF gained consensus to publish it o The IETF gained consensus to publish it
o The situation was somewhat forced, both by the fact of its o Devising a resolution to the situation was constrained by at least
unilateral use by The Tor Project without following the RFC 6761 two factors. First, there was no process for allocating special-
process, and because a deadline had been set by the CA/Browser use domain names at the time that the .onion project started using
Forum [SDO-CABF-INT] after which all .onion PKI certificates would the name, and since at the time the scope of use of the name was
expire and no new certificates would be issued, unless the .onion expected to be very constrained, the developers chose to allocate
Special-Use Top-Level Domain Name were to be recognized by the it unilaterally rather than asking the IETF or some other SDO to
IETF. create a new process.
Second, for some time, the CA/Browser Forum [SDO-CABF] had been
issuing certificates for what they referred to as "internal
names." Internal names are names allocated unilaterally for use
in site-specific contexts. Issuing certificates for such names
came to be considered problematic, since no formal process for
testing the validity of such names existed. Consequently, CA/
Browser Forum decided to phase out the use of such names in
certificates [SDO-CABF-INT], and set a deadline after which no new
certs for such names would be issued [SDO-CABF-DEADLINE]. Because
the .onion name had been allocated unilaterally, it was affected
by this policy.
The IETF's designation of .onion as a Special-Use Top-Level Domain
Name was needed to facilitate the development of a certificate
issuance process specific to .onion domain names
[SDO-CABF-BALLOT144].
4.2.3. Locally Served DNS Zones 4.2.3. Locally Served DNS Zones
Locally Served DNS Zones [RFC6303] describes a particular use case Locally Served DNS Zones [RFC6303] describes a particular use case
for zones that exist by definition, and that are resolved using the for zones that exist by definition, and that are resolved using the
DNS protocol, but that cannot have a global meaning, because the host DNS protocol, but that cannot have a global meaning, because the host
IP addresses they reference are not unique. This applies to a IP addresses they reference are not unique. This applies to a
variety of addresses, including Private IPv4 addresses [RFC1918], variety of addresses, including Private IPv4 addresses [RFC1918],
Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice
was first described) and IANA-Reserved IPv4 Prefix for Shared Address was first described) and IANA-Reserved IPv4 Prefix for Shared Address
skipping to change at page 19, line 10 skipping to change at page 19, line 32
was the key motivating factor in the writing of this document, and he was the key motivating factor in the writing of this document, and he
agreed to co-author it without too much arm-twisting. Warren spent a agreed to co-author it without too much arm-twisting. Warren spent a
lot of time working with us on this document after it was first lot of time working with us on this document after it was first
published, and joined as an author in order to make sure that the published, and joined as an author in order to make sure that the
work got finished; without him the -01 and -02 versions might not work got finished; without him the -01 and -02 versions might not
have happened. have happened.
This document also owes a great deal to Ed Lewis' excellent work on This document also owes a great deal to Ed Lewis' excellent work on
what a "Domain Name" is [I-D.lewis-domain-names]. what a "Domain Name" is [I-D.lewis-domain-names].
9. Informative References 9. RFC Editor Considerations
The authors were unable to find dates for references
[SDO-CABF-DEADLINE] and [SDO-CABF]. Please fix up those references
as appropriate (and remove this section before publication).
10. Informative References
[CORP-SUN-NIS]
Sun Microsystems, "Large System and Network
Administration", March 1990.
[ERRATA-4677]
Internet Architecture Board, "Errata ID: 4677 (RFC7788)",
April 2016, <https://www.rfc-editor.org/errata/eid4677>.
[I-D.chapin-additional-reserved-tlds]
Chapin, L. and M. McFadden, "Additional Reserved Top Level
Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015.
[I-D.grothoff-iesg-special-use-p2p-names]
Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and
L. Ryge, "Special-Use Domain Names of Peer-to-Peer
Systems", draft-grothoff-iesg-special-use-p2p-names-04
(work in progress), January 2015.
[I-D.lewis-domain-names]
Lewis, E., "Domain Names, A Case for Clarifying", draft-
lewis-domain-names-07 (work in progress), June 2017.
[IETF-PRO-51]
Internet Engineering Task Force, "Proceedings of the 51st
IETF", August 2001,
<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, DOI 10.17487/RFC0882, November 1983, RFC 882, DOI 10.17487/RFC0882, November 1983,
<http://www.rfc-editor.org/info/rfc882>. <http://www.rfc-editor.org/info/rfc882>.
[RFC0883] Mockapetris, P., "Domain names: Implementation [RFC0883] Mockapetris, P., "Domain names: Implementation
specification", RFC 883, DOI 10.17487/RFC0883, November specification", RFC 883, DOI 10.17487/RFC0883, November
1983, <http://www.rfc-editor.org/info/rfc883>. 1983, <http://www.rfc-editor.org/info/rfc883>.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
skipping to change at page 21, line 5 skipping to change at page 22, line 13
2015, <http://www.rfc-editor.org/info/rfc7686>. 2015, <http://www.rfc-editor.org/info/rfc7686>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <http://www.rfc-editor.org/info/rfc7719>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>. 2016, <http://www.rfc-editor.org/info/rfc7788>.
[I-D.chapin-additional-reserved-tlds] [SDO-CABF]
Chapin, L. and M. McFadden, "Additional Reserved Top Level CA/Browser Forum, "CA/Browser Forum", ??? ????,
Domains", draft-chapin-additional-reserved-tlds-02 (work <https://cabforum.org>.
in progress), March 2015.
[I-D.grothoff-iesg-special-use-p2p-names] [SDO-CABF-BALLOT144]
Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and CA/Browser Forum, "Ballot 144 - Validation Rules for
L. Ryge, "Special-Use Domain Names of Peer-to-Peer .onion Names", February 2015,
Systems", draft-grothoff-iesg-special-use-p2p-names-04 <https://cabforum.org/2015/02/18/ballot-144-validation-
(work in progress), January 2015. rules-dot-onion-names>.
[I-D.lewis-domain-names] [SDO-CABF-DEADLINE]
Lewis, E., "Domain Names, A Case for Clarifying", draft- CA/Browser Forum, "SSL Certificates for Internal Server
lewis-domain-names-07 (work in progress), June 2017. Names", ??? ????, <https://www.digicert.com/internal-
names.htm>.
[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-IAB-ICANN-LS]
Internet Architecture Board, "Liaison Statement from the
IAB to the ICANN Board on Technical Use of Domain Names",
September 2015, <https://datatracker.ietf.org/
liaison/1351>.
[SDO-IANA-SUDR]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>.
[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-
collision-02aug13-en.pdf>. collision-02aug13-en.pdf>.
[SDO-ICANN-DAG]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>.
[SDO-ICANN-SAC090] [SDO-ICANN-SAC090]
ICANN Security and Stability Advisory Committee, "SSAC ICANN Security and Stability Advisory Committee, "SSAC
Advisory on the Stability of the Domain Namespace", Advisory on the Stability of the Domain Namespace",
December 2016, December 2016,
<https://www.icann.org/en/system/files/files/sac- <https://www.icann.org/en/system/files/files/sac-
090-en.pdf>. 090-en.pdf>.
[SDO-ICANN-SSAC] [SDO-ICANN-SSAC]
ICANN Security and Stability Advisory Committee, "SSAC ICANN Security and Stability Advisory Committee, "SSAC
Advisory on the Stability of the Domain Namespace", Advisory on the Stability of the Domain Namespace",
December 2016, <https://www.icann.org/groups/ssac>. December 2016, <https://www.icann.org/groups/ssac>.
[SDO-IANA-SUDR]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>.
[SDO-ICANN-DAG]
Internet Assigned Numbers Authority, "Special-Use Domain
Names registry", October 2015,
<https://newgtlds.icann.org/en/applicants/agb/guidebook-
full-04jun12-en.pdf>.
[SDO-IAB-ICANN-LS]
Internet Architecture Board, "Liaison Statement from the
IAB to the ICANN Board on Technical Use of Domain Names",
September 2015, <https://datatracker.ietf.org/
liaison/1351>.
[ERRATA-4677]
Internet Architecture Board, "Errata ID: 4677 (RFC7788)",
April 2016, <https://www.rfc-editor.org/errata/eid4677>.
[CORP-SUN-NIS]
Sun Microsystems, "Large System and Network
Administration", March 1990.
[IETF-PRO-51]
Internet Engineering Task Force, "Proceedings of the 51st
IETF", August 2001,
<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: -03 to -04:
o Issue #72: Corrected original text to reflect that RFC 7050 o Issue #72: Corrected original text to reflect that RFC 7050
neglected to request an SUDN registry entry for "ipv4only.arpa", neglected to request an SUDN registry entry for "ipv4only.arpa",
but any inference about the cause for the oversight would be but any inference about the cause for the oversight would be
 End of changes. 20 change blocks. 
71 lines changed or deleted 112 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/