draft-ietf-dnsop-sutld-ps-06.txt   draft-ietf-dnsop-sutld-ps-07.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 29, 2017 Expires: January 4, 2018
W. Kumari W. Kumari
Google Google
June 27, 2017 July 3, 2017
Special-Use Domain Names Problem Statement Special-Use Domain Names Problem Statement
draft-ietf-dnsop-sutld-ps-06 draft-ietf-dnsop-sutld-ps-07
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 29, 2017. This Internet-Draft will expire on January 4, 2018.
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 40 skipping to change at page 2, line 40
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 . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . 19 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19
10. Informative References . . . . . . . . . . . . . . . . . . . 19 10. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 10 skipping to change at page 5, line 10
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, 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. This is not an ordered list, it is
numbered merely to facilitate referencing specific problems:
o Although the IETF and ICANN have a liaison relationship through
which special-use allocations can be discussed, there exists no
formal process for coordinating these allocations (see
Section 4.1.3). The lack of coordination complicates the
management of the root of the Domain Namespace and could lead to
conflicts in name assignments [SDO-ICANN-SAC090].
o There is no explicit scoping as to what can constitute a 1. Although the IETF and ICANN have a liaison relationship through
"technical use" [RFC2860] and what cannot, and there is also no which special-use allocations can be discussed, there exists no
consensus within the IETF as to what this term means. formal process for coordinating these allocations (see
Section 4.1.3). The lack of coordination complicates the
management of the root of the Domain Namespace and could lead to
conflicts in name assignments [SDO-ICANN-SAC090].
o Not all developers of protocols on the internet agree that 2. There is no explicit scoping as to what can constitute a
authority over the entire Domain Namespace should reside solely "technical use" [RFC2860] and what cannot, and there is also no
with the IETF and ICANN. consensus within the IETF as to what this term means.
o Although IETF and ICANN nominally have authority over this 3. Not all developers of protocols on the internet agree that
namespace, neither organization can enforce that authority over authority over the entire Domain Namespace should reside solely
any third party who wants to just start using a subset of the with the IETF and ICANN.
namespace. Such parties may observe that the IETF has never
asserted control or authority over what protocols are "allowed" on
the internet, and that the principle of "permissionless
innovation" suggests there should be a way for people to include
new uses of domain names in new protocols and applications.
o Organizations do in fact sometimes use subsets of the Domain 4. Although IETF and ICANN nominally have authority over this
Namespace without following established processes. Reasons a namespace, neither organization can enforce that authority over
third party might do this include: any third party who wants to just start using a subset of the
namespace. Such parties may observe that the IETF has never
asserted control or authority over what protocols are "allowed"
on the internet, and that the principle of "permissionless
innovation" suggests there should be a way for people to include
new uses of domain names in new protocols and applications.
* Unaware that a process exists for assigning such names 5. Organizations do in fact sometimes use subsets of the Domain
Namespace without following established processes. Reasons a
third party might do this include:
* Intended use is covered by gTLD process [SDO-ICANN-DAG], but no 1. Unaware that a process exists for assigning such names
gTLD process is ongoing
* Intended use is covered by gTLD process, but the third party 2. Intended use is covered by gTLD process [SDO-ICANN-DAG], but
doesn't want to pay a fee no gTLD process is ongoing
* Intended use is covered by some IETF process, but the third 3. Intended use is covered by gTLD process, but the third party
party doesn't want to follow the process doesn't want to pay a fee
* Intended use is covered by ICANN or IETF process, but third 4. Intended use is covered by some IETF process, but the third
party expects that the outcome will be refusal or non-action party doesn't want to follow the process
* Unaware that a name intended to be used only locally may 5. Intended use is covered by ICANN or IETF process, but third
nevertheless leak party expects that the outcome will be refusal or non-action
* Unaware that a name used locally with informal allocation may 6. Unaware that a name intended to be used only locally may
subsequently be allocated formally, creating operational nevertheless leak
problems
o There is demand for more than one name resolution protocol for 7. Unaware that a name used locally with informal allocation
Domain Names. Domain Names contain no metadata to indicate which may subsequently be allocated formally, creating operational
protocol to use to resolve them. Domain name resolution APIs do problems
not provide a way to specify which protocol to use.
o When a Special-Use Domain Name is added to the Special-Use Domain 6. There is demand for more than one name resolution protocol for
Names registry, not all software that processes such names will Domain Names. Domain Names contain no metadata to indicate
understand the special use of that name. In many cases, name which protocol to use to resolve them. Domain name resolution
resolution software will use the Domain Name System for resolution APIs do not provide a way to specify which protocol to use.
of names not known to have a special use. Consequently, any such
use will result in queries for Special-Use Domain Names being sent
to Domain Name System authoritative servers. These queries may
constitute an operational problem for operators of root zone
authoritative name servers. These queries may also inadvertently
reveal private information through the contents of the query,
which is a privacy consideration.
o The RFC 6761 process is sufficiently uncertain that some protocol 7. When a Special-Use Domain Name is added to the Special-Use
developers have assumed they could not get a name assigned; the Domain Names registry, not all software that processes such
process of assigning the first new name ('.local') using the RFC names will understand the special use of that name. In many
6761 process took more than ten years from beginning to end: cases, name resolution software will use the Domain Name System
longer by a factor of ten than any other part of the protocol for resolution of names not known to have a special use.
development process (largely because this ten years included time Consequently, any such use will result in queries for Special-
to develop the process as well as use it). Other uses of the Use Domain Names being sent to Domain Name System authoritative
process have proceeded more smoothly, but there is a reasonably servers. These queries may constitute an operational problem
justified perception that using this process is likely to be slow for operators of root zone authoritative name servers. These
and difficult, with an uncertain outcome. queries may also inadvertently reveal private information
through the contents of the query, which is a privacy
consideration.
o There is strong resistance within the IETF to assigning Domain 8. The RFC 6761 process is sufficiently uncertain that some
Names to resolution systems outside of the DNS, for a variety of protocol developers have assumed they could not get a name
reasons: assigned; the process of assigning the first new name ('.local')
using the RFC 6761 process took more than ten years from
beginning to end: longer by a factor of ten than any other part
of the protocol development process (largely because this ten
years included time to develop the process as well as use it).
Other uses of the process have proceeded more smoothly, but
there is a reasonably justified perception that using this
process is likely to be slow and difficult, with an uncertain
outcome.
* Requires a mechanism for identifying which of a set of 9. There is strong resistance within the IETF to assigning Domain
resolution processes is required in order to resolve a Names to resolution systems outside of the DNS, for a variety of
particular name. reasons:
* Assertion of authority: there is a sense that the Domain 1. Requires a mechanism for identifying which of a set of
Namespace is "owned" by the IETF or by ICANN, and so, if a name resolution processes is required in order to resolve a
is claimed outside of that process, the person or entity that particular name.
claimed that name should suffer some consequence that would,
presumably, deter future circumvention of the official process.
* More than one name resolution protocol is bad, in the sense 2. Assertion of authority: there is a sense that the Domain
that a single protocol is less complicated to implement and Namespace is "owned" by the IETF or by ICANN, and so, if a
deploy. name is claimed outside of that process, the person or
entity that claimed that name should suffer some consequence
that would, presumably, deter future circumvention of the
official process.
* The semantics of alternative resolution protocols may differ 3. More than one name resolution protocol is bad, in the sense
from the DNS protocol; DNS has the concept of RRtypes; other that a single protocol is less complicated to implement and
protocols may not support RRtypes, or may support some entirely deploy.
different data structuring mechanism.
* If there is an IETF process through which a TLD can be assigned 4. The semantics of alternative resolution protocols may differ
at zero cost other than time, this process will be used as an from the DNS protocol; DNS has the concept of RRtypes; other
alternative to the more costly process of getting the name protocols may not support RRtypes, or may support some
registered through ICANN. entirely different data structuring mechanism.
* A name might be assigned for a particular purpose when a more 5. If there is an IETF process through which a TLD can be
general use of the name would be more beneficial. assigned at zero cost other than time, this process will be
used as an alternative to the more costly process of getting
the name registered through ICANN.
* If the IETF assigns a name that some third party or parties 6. A name might be assigned for a particular purpose when a
believes belongs to them in some way, the IETF could become more general use of the name would be more beneficial.
embroiled in an expensive dispute with those parties.
o If there were no process for assigning names for technical use 7. If the IETF assigns a name that some third party or parties
through the IETF, there is a concern that protocols that require believes belongs to them in some way, the IETF could become
such names would not be able to get them. embroiled in an expensive dispute with those parties.
o In some cases where the IETF has made assignments through the RFC 10. If there were no process for assigning names for technical use
6761 process, technical mistakes have been made due to through the IETF, there is a concern that protocols that require
misunderstandings as to the actual process that RFC 6761 specifies such names would not be able to get them.
(e.g., treating the list of suggested considerations for assigning
a name as a set of requirements all of which must be met). In
other cases, the IETF has made de facto assignments of Special-Use
Domain Names without following the RFC 6761 process.
o There are several Domain Name TLDs that are in use without due 11. In some cases where the IETF has made assignments through the
process for a variety of purposes. The status of these names need RFC 6761 process, technical mistakes have been made due to
to be clarified and recorded to avoid future disputes about their misunderstandings as to the actual process that RFC 6761
use [SDO-ICANN-COLL]. specifies (e.g., treating the list of suggested considerations
for assigning a name as a set of requirements all of which must
be met). In other cases, the IETF has made de facto assignments
of Special-Use Domain Names without following the RFC 6761
process.
o In principle, the RFC 6761 process could be used to document the 12. There are several Domain Name TLDs that are in use without due
existence of Domain Names that are not safe to assign, and provide process for a variety of purposes. The status of these names
information on how those names are used in practice. However, need to be clarified and recorded to avoid future disputes about
attempts to use RFC 6761 to accomplish this documentation have not their use [SDO-ICANN-COLL].
been successful (for example, see "Additional Reserved Top Level
Domains [I-D.chapin-additional-reserved-tlds] and Section 4.2.7).
One side effect of the lack of documentation is that any 13. In principle, the RFC 6761 process could be used to document the
mitigation effect on the root name servers or on privacy existence of Domain Names that are not safe to assign, and
considerations has been missed. provide information on how those names are used in practice.
However, attempts to use RFC 6761 to accomplish this
documentation have not been successful (for example, see
"Additional Reserved Top Level Domains
[I-D.chapin-additional-reserved-tlds] and Section 4.2.7). One
side effect of the lack of documentation is that any mitigation
effect on the root name servers or on privacy considerations has
been missed.
o A Domain Name can be identified as either a DNS name by placing it 14. A Domain Name can be identified as either a DNS name by placing
in the DNS zone(s) or as a Special-Use Domain Name by adding it to it in the DNS zone(s) or as a Special-Use Domain Name by adding
the IANA registry. Some names are in both places; for example, it to the IANA registry. Some names are in both places; for
some locally served zone names are in DNS zones and documented in example, some locally served zone names are in DNS zones and
the Special-Use Domain Names registry. At present, the only way a documented in the Special-Use Domain Names registry. At
Domain Name can be added to the Special-Use Domain Name registry present, the only way a Domain Name can be added to the Special-
is for the IETF to take responsibility for the name and designate Use Domain Name registry is for the IETF to take responsibility
it for "technical use". There are other potential uses for Domain for the name and designate it for "technical use". There are
Names that should be recorded in the registry, but for which the other potential uses for Domain Names that should be recorded in
IETF should not take responsibility. the registry, but for which the IETF should not take
responsibility.
o The IETF may in some cases see the need to document that a name is 15. The IETF may in some cases see the need to document that a name
in use without claiming that the use of the name is the IETF's use is in use without claiming that the use of the name is the
of the name. No mechanism exists in the current registry to mark IETF's use of the name. No mechanism exists in the current
names in this way. registry to mark names in this way.
o There is no formal process during any of the review stages for a 16. 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
not unintentionally violate IETF process for adding special-use does not unintentionally violate IETF process for adding
domain names to the registry, as was the case, for example, in RFC special-use domain names to the registry, as was the case, for
7788 [RFC7788]. example, in RFC 7788 [RFC7788].
o Use of the registry is inconsistent -- some Special-Use Domain 17. Use of the registry is inconsistent -- some Special-Use Domain
Name RFCs specifically add registry entries, some don't; some Name RFCs specifically add registry entries, some don't; some
specify how and whether special-use name delegations should be specify how and whether special-use name delegations should be
done, some don't. done, some don't.
o There exists no safe, non-process-violating mechanism for ad-hoc 18. 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 19. 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
Use Domain Name, for use in user interfaces such as command lines Special-Use Domain Name, for use in user interfaces such as
or URL entry fields. While this assumption is correct in some command lines or URL entry fields. While this assumption is
cases, it is likely not correct in all cases; for example, in correct in some cases, it is likely not correct in all cases;
applications where the DNS name is never visible to a user. for example, in applications where the DNS name is never visible
to a user.
o RFC 6761 uses the term "Domain Name" to describe the thing for 20. RFC 6761 uses the term "Domain Name" to describe the thing for
which special uses are registered. This creates a great deal of which special uses are registered. This creates a great deal of
confusion because some readers take "Domain Name" to imply the use confusion because some readers take "Domain Name" to imply the
of the DNS protocol. use of the DNS protocol.
o The use of DNSSEC with Special-Use Domain Names is an open issue. 21. The use of DNSSEC with Special-Use Domain Names is an open
There is no consensus or guidance about how to use DNSSEC with issue. There is no consensus or guidance about how to use
various classes of Special-Use Domain Names. Considerations in DNSSEC with various classes of Special-Use Domain Names.
the use of DNSSEC with Special-Use Domain Names include: Considerations in the use of DNSSEC with Special-Use Domain
Names include:
* What class of Special-Use Domain Name is under consideration: 1. What class of Special-Use Domain Name is under
non-DNS, locally served zone, other? consideration: non-DNS, locally served zone, other?
* Does the Special-Use Domain Name require a delegation in the 2. Does the Special-Use Domain Name require a delegation in the
root zone; if so, should that delegation be signed or not? If root zone; if so, should that delegation be signed or not?
there is no delegation, then this will be treated by validating If there is no delegation, then this will be treated by
resolvers as a secure denial of existence for that zone. This validating resolvers as a secure denial of existence for
would not be appropriate for a name being resolved using the that zone. This would not be appropriate for a name being
DNS protocol. resolved using the DNS protocol.
* A process would be required through which the IETF can cause a 3. A process would be required through which the IETF can cause
delegation in the root zone to be instantiated. a delegation in the root zone to be instantiated.
* What are the recommended practices for using DNS with the 4. What are the recommended practices for using DNS with the
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 (see Section 4.1) and numerous secondary There are three primary (see Section 4.1) and numerous secondary
skipping to change at page 9, line 48 skipping to change at page 10, line 8
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. 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. Unauthorized use sense exclude the practice of ad-hoc use of names. Unauthorized use
of domain names can be accomplished by any entity that has control of domain names can be accomplished by any entity that has control
over one or more name servers or resolvers, in the context of any over one or more name servers or resolvers, in the context of any
hosts and services that that entity operates. It can also be hosts and services that entity operates. It can also be accomplished
accomplished by authors of software who decide that a Special-Use by authors of software who decide that a Special-Use Domain Name is
Domain Name is the right way to indicate the use of an alternate the right way to indicate the use of an alternate resolution
resolution mechanism. 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
skipping to change at page 15, line 32 skipping to change at page 15, line 36
create a new process. create a new process.
Second, for some time, the CA/Browser Forum [SDO-CABF] had been Second, for some time, the CA/Browser Forum [SDO-CABF] had been
issuing certificates for what they referred to as "internal issuing certificates for what they referred to as "internal
names." Internal names are names allocated unilaterally for use names." Internal names are names allocated unilaterally for use
in site-specific contexts. Issuing certificates for such names in site-specific contexts. Issuing certificates for such names
came to be considered problematic, since no formal process for came to be considered problematic, since no formal process for
testing the validity of such names existed. Consequently, CA/ testing the validity of such names existed. Consequently, CA/
Browser Forum decided to phase out the use of such names in Browser Forum decided to phase out the use of such names in
certificates [SDO-CABF-INT], and set a deadline after which no new certificates [SDO-CABF-INT], and set a deadline after which no new
certs for such names would be issued [SDO-CABF-DEADLINE]. Because certificates for such names would be issued [SDO-CABF-DEADLINE].
the .onion name had been allocated unilaterally, it was affected Because the .onion name had been allocated unilaterally, it was
by this policy. affected by this policy.
The IETF's designation of .onion as a Special-Use Top-Level Domain The IETF's designation of .onion as a Special-Use Top-Level Domain
Name was needed to facilitate the development of a certificate Name was needed to facilitate the development of a certificate
issuance process specific to .onion domain names issuance process specific to .onion domain names
[SDO-CABF-BALLOT144]. [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
skipping to change at page 19, line 40 skipping to change at page 19, line 40
what a "Domain Name" is [I-D.lewis-domain-names]. what a "Domain Name" is [I-D.lewis-domain-names].
9. RFC Editor Considerations 9. RFC Editor Considerations
The authors were unable to find dates for references The authors were unable to find dates for references
[SDO-CABF-DEADLINE] and [SDO-CABF]. Please fix up those references [SDO-CABF-DEADLINE] and [SDO-CABF]. Please fix up those references
as appropriate (and remove this section before publication). as appropriate (and remove this section before publication).
10. Informative References 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", STD
STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
<http://www.rfc-editor.org/info/rfc959>. <http://www.rfc-editor.org/info/rfc959>.
[RFC1002] NetBIOS Working Group in the Defense Advanced Research [RFC1002] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-to-End Projects Agency, Internet Activities Board, and End-to-End
Services Task Force, "Protocol standard for a NetBIOS Services Task Force, "Protocol standard for a NetBIOS
service on a TCP/UDP transport: Detailed specifications", service on a TCP/UDP transport: Detailed specifications",
STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987,
<http://www.rfc-editor.org/info/rfc1002>. <http://www.rfc-editor.org/info/rfc1002>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
skipping to change at page 21, line 15 skipping to change at page 20, line 35
[RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain [RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain
Names", RFC 2352, DOI 10.17487/RFC2352, May 1998, Names", RFC 2352, DOI 10.17487/RFC2352, May 1998,
<http://www.rfc-editor.org/info/rfc2352>. <http://www.rfc-editor.org/info/rfc2352>.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
2000, <http://www.rfc-editor.org/info/rfc2826>. 2000, <http://www.rfc-editor.org/info/rfc2826>.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, Internet Assigned Numbers Authority", RFC 2860, DOI
DOI 10.17487/RFC2860, June 2000, 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>. <http://www.rfc-editor.org/info/rfc2860>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <http://www.rfc-editor.org/info/rfc4193>.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC
RFC 6303, DOI 10.17487/RFC6303, July 2011, 6303, DOI 10.17487/RFC6303, July 2011,
<http://www.rfc-editor.org/info/rfc6303>. <http://www.rfc-editor.org/info/rfc6303>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
2012, <http://www.rfc-editor.org/info/rfc6598>. 2012, <http://www.rfc-editor.org/info/rfc6598>.
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
to Replace the AppleTalk Name Binding Protocol (NBP)", to Replace the AppleTalk Name Binding Protocol (NBP)", RFC
RFC 6760, DOI 10.17487/RFC6760, February 2013, 6760, DOI 10.17487/RFC6760, February 2013,
<http://www.rfc-editor.org/info/rfc6760>. <http://www.rfc-editor.org/info/rfc6760>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013, RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>. <http://www.rfc-editor.org/info/rfc6761>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013, DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
RFC 7050, DOI 10.17487/RFC7050, November 2013, 7050, DOI 10.17487/RFC7050, November 2013,
<http://www.rfc-editor.org/info/rfc7050>. <http://www.rfc-editor.org/info/rfc7050>.
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use
Domain Name", RFC 7686, DOI 10.17487/RFC7686, October Domain Name", RFC 7686, DOI 10.17487/RFC7686, October
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>.
[SDO-CABF] [I-D.chapin-additional-reserved-tlds]
CA/Browser Forum, "CA/Browser Forum", ??? ????, Chapin, L. and M. McFadden, "Additional Reserved Top Level
<https://cabforum.org>. Domains", draft-chapin-additional-reserved-tlds-02 (work
in progress), March 2015.
[SDO-CABF-BALLOT144] [I-D.grothoff-iesg-special-use-p2p-names]
CA/Browser Forum, "Ballot 144 - Validation Rules for Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and
.onion Names", February 2015, L. Ryge, "Special-Use Domain Names of Peer-to-Peer
<https://cabforum.org/2015/02/18/ballot-144-validation- Systems", draft-grothoff-iesg-special-use-p2p-names-04
rules-dot-onion-names>. (work in progress), January 2015.
[SDO-CABF-DEADLINE] [I-D.lewis-domain-names]
CA/Browser Forum, "SSL Certificates for Internal Server Lewis, E., "Domain Names, A Case for Clarifying", draft-
Names", ??? ????, <https://www.digicert.com/internal- lewis-domain-names-08 (work in progress), June 2017.
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] [SDO-CABF-DEADLINE]
Internet Architecture Board, "Liaison Statement from the CA/Browser Forum, "SSL Certificates for Internal Server
IAB to the ICANN Board on Technical Use of Domain Names", Names", ??? ????, <https://www.digicert.com/internal-
September 2015, <https://datatracker.ietf.org/ names.htm>.
liaison/1351>.
[SDO-IANA-SUDR] [SDO-CABF]
Internet Assigned Numbers Authority, "Special-Use Domain CA/Browser Forum, "CA/Browser Forum", ??? ????,
Names registry", October 2015, <https://cabforum.org>.
<http://www.iana.org/assignments/special-use-domain-names/
special-use-domain-names.xhtml>. [SDO-CABF-BALLOT144]
CA/Browser Forum, "Ballot 144 - Validation Rules for
.onion Names", February 2015,
<https://cabforum.org/2015/02/18/ballot-144-validation-
rules-dot-onion-names>.
[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.
-06 to -07:
o Issue #88: Bulleted list should be numbered, not unordered -
Updated the list of problems to be numbered, instead of unordered.
This is to allow future documents to refer to specific issues.
o Misc: Removed duplicate word ("that that" -> "that")
o Backfilled the "Change Log" to reflect the issues addressed
between Version -05 and -06.
-05 to -06:
o Issue #87: Section 4.2.2: expand "certs" to "certificates"
o Issue #86: Stephane Bortzmeyer: lying DNS resolvers
o Issue #85: Stephane Bortzmeyer: unilateral use
o Issue #84: Stephane Bortzmeyer: Use of the registry is
inconsistent
o Issue #83: Stephane Bortzmeyer: IETF-ICANN have a liaison
relationship
o Issue #82: Bob Harold: extra "be used"
o Issue #81: Editorial changes from Benoit Claise AD review
o Issue #80: Section 3 - Clarify citation of SDO-ICANN-COLL
o Issue #79: Update reference to "Special-Use Domain Names registry"
(?)
o Issue #78: Section 4.2.7 - add citation of Errata correcting use
of ".home" in RFC 7788
o Issue #77: Section 2 - correct citation of definition of gTLD
o Issue #76: Section 3 - clarify that problems are listed regardless
of validity or ownership,
o Issue #74, #75: Meaning versus binding (Andrew McConachie),
global/local (Andrew McConachie)
o Issue #73: Editorial improvements, Section 4.2.7
-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
speculation. speculation.
o Issue #69: Edited Joel's suggested text. o Issue #69: Edited Joel's suggested text.
o Issue #67: Minor change to Joel's suggested text. o Issue #67: Minor change to Joel's suggested text.
skipping to change at page 23, line 48 skipping to change at page 25, line 4
o Issue #66: Edited second text update suggested by Joel and o Issue #66: Edited second text update suggested by Joel and
reverted third change back to the original text. reverted third change back to the original text.
o Issue #64: Minor changes to text suggested by Joel. o Issue #64: Minor changes to text suggested by Joel.
o Issue #61: Minor edit based on authors' consensus in response to o Issue #61: Minor edit based on authors' consensus in response to
Joel's comment. Joel's comment.
o Addressed Joel / Benoit's AD comments. See GH issues 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 o 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 o Issue #60: Add new section "6. Summary" -- Petr Spacek
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/60 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/60
Issue #57: Document needs an "Security Considerations" section o 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 o Numerous editorial changes for consistency; e.g. use "Special-Use
Domain Names" throughout. Domain Names" throughout.
Issue #58: Document needs an "IANA Considerations" section o 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 o 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
Issue #55: Editorial improvement to Section 3 (4) -- John o Issue #55: Editorial improvement to Section 3 (4) -- John
Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/ Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/55 issues/55
Issue #34: Separate two problems in paragraph that begins "No o Issue #34: Separate two problems in paragraph that begins "No
mechanism exists for adding a name to the registry...." (2 issues) mechanism exists for adding a name to the registry...." (2 issues)
-- Suzanne Woolf https://github.com/Abhayakara/draft-tldr-sutld- -- Suzanne Woolf https://github.com/Abhayakara/draft-tldr-sutld-
ps/issues/34 ps/issues/34
Issue #52: Editorial improvement to Section 3 (1) -- John o Issue #52: Editorial improvement to Section 3 (1) -- John
Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/ Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/52 issues/52
Issue #51: Clarification in Introduction -- John Dickinson o Issue #51: Clarification in Introduction -- John Dickinson
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51
Issue #49: Should cite https://datatracker.ietf.org/liaison/1351 o Issue #49: Should cite https://datatracker.ietf.org/liaison/1351
-- George Michaelson https://github.com/Abhayakara/draft-tldr- -- George Michaelson https://github.com/Abhayakara/draft-tldr-
sutld-ps/issues/49 sutld-ps/issues/49
Issue #50: IETF precedence in Special-Use names registry -- Ted o Issue #50: IETF precedence in Special-Use names registry -- Ted
Lemon https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/50 Lemon https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/50
Issue #48: 4.1.2 cites sub-domains of .ARPA arguing for special o Issue #48: 4.1.2 cites sub-domains of .ARPA arguing for special
use TLD -- George Michaelson https://github.com/Abhayakara/draft- use TLD -- George Michaelson https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/48 tldr-sutld-ps/issues/48
Issue #47: 4.3 should be made more prominent -- George Michaelson
o Issue #47: 4.3 should be made more prominent -- George Michaelson
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47
Issue #43: Spell out SUDN and SUTLDN rather than use acronyms -- o Issue #43: Spell out SUDN and SUTLDN rather than use acronyms --
Russ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/ Russ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/43 issues/43
Issue #41: Reword bullet in Section 3 regarding Domain Name TLDs o Issue #41: Reword bullet in Section 3 regarding Domain Name TLDs
that have been commandeered, as reported in SDO-ICANN-COLL -- Russ that have been commandeered, as reported in SDO-ICANN-COLL -- Russ
Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/41 issues/41
Issue #40: Note that time to publish spec for .local included o Issue #40: Note that time to publish spec for .local included
inventing SUDN registry -- Russ Housley inventing SUDN registry -- Russ Housley
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/41 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/41
Issue #37: Title should be "Special-Use Domain Names Problem o Issue #37: Title should be "Special-Use Domain Names Problem
Statement" -- Russ Housley https://github.com/Abhayakara/draft- Statement" -- Russ Housley https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/37 tldr-sutld-ps/issues/37
Issue #36: Expand on desire for Special-Use names to be human- o Issue #36: Expand on desire for Special-Use names to be human-
readable -- Suzanne Woolf https://github.com/Abhayakara/draft- readable -- Suzanne Woolf https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/36 tldr-sutld-ps/issues/36
Issue #35: Clarify "No process exists [...]" to include both IETF o Issue #35: Clarify "No process exists [...]" to include both IETF
process and other process -- Suzanne Woolf process and other process -- Suzanne Woolf
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/35 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/35
Issue #31: Add justification for concern about IETF's ability to o Issue #31: Add justification for concern about IETF's ability to
assign names for technical use -- Suzanne Woolf assign names for technical use -- Suzanne Woolf
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/31 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/31
Issue #12: Add DNSSEC to text -- John Levine o Issue #12: Add DNSSEC to text -- John Levine
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/12 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/12
Issue #6: Without a process, we just have chaos -- Stuart Cheshire o Issue #6: Without a process, we just have chaos -- Stuart Cheshire
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6
Issue #32: Have assignments through RFC 6761 really had "technical o Issue #32: Have assignments through RFC 6761 really had "technical
mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft- mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/32 tldr-sutld-ps/issues/32
Issue #29: Add a reason to bypass external process: expectation o Issue #29: Add a reason to bypass external process: expectation
for use of new name to be restricted to local scope -- Suzanne for use of new name to be restricted to local scope -- Suzanne
Wolff https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/29 Wolff https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/29
Issue #27: Is "technical use" really ambiguous; too inclusive for
o Issue #27: Is "technical use" really ambiguous; too inclusive for
some people and too limited for others -- Suzanne Wolff some people and too limited for others -- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/27 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/27
Issue #24: Replacement for "commandeer" (2 issues)-- Suzanne Wolff o Issue #24: Replacement for "commandeer" (2 issues)-- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/24 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/24
Issue #22: Clarify importance of the "root of the Domain o Issue #22: Clarify importance of the "root of the Domain
Namespace" -- Suzanne Wolff https://github.com/Abhayakara/draft- Namespace" -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/22 tldr-sutld-ps/issues/22
Issue #21: Section 3 - clarify paragraphs 2 and 3 -- Suzanne Wolff o Issue #21: Section 3 - clarify paragraphs 2 and 3 -- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/21 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/21
Issue #20: Section 3: Clarify sentences beginning "Solutions to o Issue #20: Section 3: Clarify sentences beginning "Solutions to
these problems..." -- Suzanne Wolff https://github.com/Abhayakara/ these problems..." -- Suzanne Wolff https://github.com/Abhayakara/
draft-tldr-sutld-ps/issues/20 draft-tldr-sutld-ps/issues/20
Issue #19: Define "default" or "assumed" use of domain names to be o Issue #19: Define "default" or "assumed" use of domain names to be
within DNS -- Suzanne Wolff https://github.com/Abhayakara/draft- within DNS -- Suzanne Wolff https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/19 tldr-sutld-ps/issues/19
Issue #18: Cite definition of RFC 7719 and domain names draft in o Issue #18: Cite definition of RFC 7719 and domain names draft in
definition of "domain name" -- Suzanne Wolff definition of "domain name" -- Suzanne Wolff
https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/18 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/18
Issue #45: Correct usages of Tor Browser and Tor -- Russ Housley o Issue #45: Correct usages of Tor Browser and Tor -- Russ Housley
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/45) (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/45)
Issue #46: Reformat citation of RFC 2860 -- Russ Housley o Issue #46: Reformat citation of RFC 2860 -- Russ Housley
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46) (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46)
Issue #44: Clean up reference to SDO-ICANN-DAG in first bullet in o Issue #44: Clean up reference to SDO-ICANN-DAG in first bullet in
section 3 -- Russ Housley (https://github.com/Abhayakara/draft- section 3 -- Russ Housley (https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/44) tldr-sutld-ps/issues/44)
Issue #42: Add reference to SDO-ICANN-SAC090 in section 4.2.5 -- o Issue #42: Add reference to SDO-ICANN-SAC090 in section 4.2.5 --
Russ Housley (https://github.com/Abhayakara/draft-tldr-sutld-ps/ Russ Housley (https://github.com/Abhayakara/draft-tldr-sutld-ps/
issues/42) issues/42)
Issue #30: Leaked queries aren't an operational problem in o Issue #30: Leaked queries aren't an operational problem in
practice -- Suzanne Wolf (https://github.com/Abhayakara/draft- practice -- Suzanne Wolf (https://github.com/Abhayakara/draft-
tldr-sutld-ps/issues/30) tldr-sutld-ps/issues/30)
Address some of the simpler issues, including: o Address some of the simpler issues, including:
Issue #13: Spelling of Tor -- Jeremy Rand o Issue #13: Spelling of Tor -- Jeremy Rand
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13) (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13)
Issue #14: Change SDO to "organizations" -- Suzanne Woolf
o Issue #14: Change SDO to "organizations" -- Suzanne Woolf
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14) (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)
Issue #16: Match number of "policies" and "that policy" -- Suzanne o Issue #16: Match number of "policies" and "that policy" -- Suzanne
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16) (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16)
Issue #17: Clarify sentence beginning with "In support of the o Issue #17: Clarify sentence beginning with "In support of the
particular set of problems described here...." -- Suzanne. particular set of problems described here...." -- Suzanne.
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14) (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14)
Issue #23: Match number of "names" and "a TLD" -- Suzanne. o Issue #23: Match number of "names" and "a TLD" -- Suzanne.
(https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/23) (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/23)
-01 to -02: -01 to -02:
Language cleanup from Ted. o Language cleanup from Ted.
-00 to -01: -00 to -01:
Improved the terminology. o Improved the terminology.
Included reference to SAC090. o Included reference to SAC090.
Added ICANN Reserved Names (e.g .icann, .iesg, .arin) to types of o Added ICANN Reserved Names (e.g .icann, .iesg, .arin) to types of
names. names.
Improved background. o Improved background.
Noted that semantics may differ between resolution contexts. o Noted that semantics may differ between resolution contexts.
Pointer to .home / .corp / .mail, other "toxic" names o Pointer to .home / .corp / .mail, other "toxic" names
Readability fixes. o Readability fixes.
-04 to ietf-00 -04 to ietf-00
Document adopted by WG. o Document adopted by WG.
Significant changes from CfA integrated, please refer to diff. o Significant changes from CfA integrated, please refer to diff.
-03 to -04: -03 to -04:
o Replaced 'Internet Names' with 'Domain Names' - suggestion by John o Replaced 'Internet Names' with 'Domain Names' - suggestion by John
Levine. Levine.
-02 to -03: -02 to -03:
o Readability fixes, small grammar updates. o Readability fixes, small grammar updates.
 End of changes. 115 change blocks. 
297 lines changed or deleted 353 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/