< draft-stw-6761ext-00.txt   draft-stw-6761ext-01.txt >
Network Working Group S. Woolf Network Working Group S. Woolf
Internet-Draft October 22, 2018 Internet-Draft March 11, 2019
Intended status: Informational Intended status: Informational
Expires: April 25, 2019 Expires: September 12, 2019
Guidelines for Use of the Special Use Names Registry Guidelines for Use of the Special Use Names Registry
draft-stw-6761ext-00 draft-stw-6761ext-01
Abstract Abstract
RFC 6761 requires that proponents document how a specific name is to RFC 6761 requires that proponents document how a specific name is to
be treated within the DNS protocol, public database, and be treated within the DNS protocol, public database, and
administrative infrastructure, but doesn't provide any guidance to administrative infrastructure, but doesn't provide any guidance to
help the community figure out whether a particular registration is help the community figure out whether a particular registration is
otherwise beneficial. This limited guidance in RFC 6761 provides otherwise beneficial. This limited guidance in RFC 6761 provides
flexibility in a difficult area-- the use of domain names in the flexibility in standardizing the use of domain names in the modern
modern Internet outside of conventional DNS protocol or the public Internet outside of conventional DNS protocol or the public DNS
DNS database-- which has been useful from time to time but has also database. This flexibility has been useful from time to time but has
caused significant confusion (see RFC 8244). also caused significant confusion (see RFC 8244).
This document attempts to define guidelines for the IESG and the IETF This document attempts to define guidelines for the IESG and the IETF
community on the interpretation of RFC 6761 and the use of the community on the interpretation of RFC 6761 and the use of the
special use names registry. special use names registry.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Current SUNR Use Cases . . . . . . . . . . . . . . . . . . . 4
3. Specific guidelines . . . . . . . . . . . . . . . . . . . . . 5 3. Guidelines for Special Use Name registration . . . . . . . . 5
4. More on Domain Name Hierarchy and the Special Case of Top- 4. The Special Case of Top-Level Domains . . . . . . . . . . . . 6
Level Domains . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. Informative References . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
From time to time, networking protocols need to be able to name From time to time, networking protocols need to be able to name
things used within the protocol, and resolve the names created or things used within the protocol, and resolve the names created or
referenced. Such identifiers may also need to be persistent in time, referenced. Such identifiers may also need to be persistent in time,
across administrative and operational realms, or through other across administrative and operational realms, or through other
transformations. Necessary operations tend to include creating, transformations. Necessary operations tend to include creating,
modifying, and deleting names, and accessing values and relationships modifying, and deleting names, and accessing values and relationships
that correspond to them. that correspond to them.
It's common for protocol designers to try to use domain names as the It's common for protocol designers to try to use domain names as the
starting point for their systems of names, and the DNS as the starting point for their systems of names, and the DNS as the
starting point for name resolution. This is completely starting point for name resolution. This is completely
understandable-- domain names, and DNS resolution, are well- understandable-- domain names, and DNS resolution, are well-
established in the expectations of network users and developers. established in the expectations of network users and developers, with
They're also well-supported by fielded software and a large public many advantages in deployment and operation. They're also well-
database of names and values, with many use cases already represented supported by fielded software and a large public database of names
by example. and values, with many use cases already represented by example.
However, there are some risks when the protocol designer attempts to However, there are some risks when the protocol designer attempts to
re-use domain names and DNS, even (or especially) with modifications, re-use domain names and DNS, even (or especially) with modifications,
to support a specific use case or protocol design or deployment to support a specific use case or protocol design or deployment
constraint. These have been touched upon in several RFCs, and in the constraint. These have been touched upon in several RFCs, and in the
evolution of DNS protocol itself and the use of domain names as new evolution of DNS protocol itself and the use of domain names as new
needs and constraints appear. See in particular RFC 6055 ("IAB needs and constraints appear. See in particular RFC 6055 ("IAB
Thoughts on Encodings for Internationalized Domain Names"), RFC 6950 Thoughts on Encodings for Internationalized Domain Names"), RFC 6950
("Architectural Considerations on Application Features in the DNS"), ("Architectural Considerations on Application Features in the DNS"),
and RFC 6943 ("Issues in Identifier Comparison for Security and RFC 6943 ("Issues in Identifier Comparison for Security
Purposes"). Purposes").
Most recently, some of these questions have become prominent in the Most recently, some of these questions have become prominent in the
course of requests for new entries in the special use names registry course of requests for new entries in the special use names registry
as established by RFC 6761 ("Special Use Domain Names"). The topic (or SUNR) as established by RFC 6761 ("Special Use Domain Names").
raises contention in a number of areas, including risks of collision The topic raises contention in a number of areas, including risks of
between different authorities and different uses of names within the collision between different authorities and possible confusion among
abstract domain namespace, which have been considered in the DNSOP WG different uses of names within the abstract domain namespace. Issues
over the last few years and are cataloged in RFC 8244 ("Special-Use around the use of the abstract domain namespace have been considered
Domain Names Problem Statement") at greater length than this document in the DNSOP WG over the last few years and are cataloged in RFC 8244
will do. ("Special-Use Domain Names Problem Statement") at greater length than
this document will do.
There are compelling questions that a protocol designer or software There are compelling questions that protocol designers or software
developer should ask themselves about what behavior they want from developers should ask themselves about what behavior they want from
the names they use in the context of a new protocol or scope for the names they use in the context of a new protocol or scope for
names. However, rather than boiling that particular ocean, this names. However, rather than boiling that particular ocean, this
document attempts the more practical task of of providing guidance to document attempts the more practical task of of providing guidance to
the IESG and the community to determine, in broad terms, the benefits the IESG and the community to determine, in broad terms, the benefits
and risks of a particular registration in the special use names and risks of a particular registration in the special use names
registry. registry.
RFC 6761 establishes the use of domain names in ways that may be RFC 6761 establishes the use of domain names in ways that may be
separate to their use in the DNS, but it's somewhat "DNS-centric," in separate to their use in the DNS, but it's somewhat "DNS-centric," in
that it doesn't discuss the use of domain names in the DNS or the that it doesn't question the default assumption that domain names and
default assumption that domain names and DNS-like semantics are DNS-like semantics are desirable or even necessarily acceptable for
desirable or even necessarily acceptable for new naming needs. It's new naming needs. It also doesn't discuss how one might decide
left to the protocol designer to decide whether this DNS-centric whether a particular string is appropriate for use as a domain name
focus is appropriate for their use case. So a proponent of a special in a particular protocol. The only thing it really requires is a
use name might discover, in the course of review, that domain names description of how the proposed reserved string should be treated as
will not meet the constraints at hand. But even if domain names seem "special" by DNS resolvers, domain name registrars, and so on.
like a good fit for the problem, there's also no guidance in RFC 6761
to deciding what names might or might not be appropriate for the Primarily RFC 6761 discusses how to make domain names and DNS-like
particular need. semantics for other networking protocols compatible with the global
public DNS. It's left to the protocol designer to decide whether
this DNS-centric focus is appropriate for their use case.
Trying to specify how special use domain names interact with the DNS
is both necessary for interoperability and helpful in thinking
through the proposed "special use". So a proponent of a special use
name might discover, in the course of specifying the "special use"
for the SUNR, that domain names will not meet the constraints at
hand. But even if domain names seem like a good fit for the problem,
there's also no guidance in RFC 6761 to deciding what names might or
might not be appropriate for the particular need.
The broader discussion of the general applicability of domain names The broader discussion of the general applicability of domain names
to new needs is useful to consider, and owes a great deal to the RFCs to new needs is useful to consider, and owes a great deal to the RFCs
already mentioned, especially RFC 6950, which "provides guidance to already mentioned, especially RFC 6950, which "provides guidance to
application designers and application protocol designers looking to application designers and application protocol designers looking to
use the DNS to support features in their applications." The use the DNS to support features in their applications." The
consideration there of how to structure domain names and associated consideration there of how to structure domain names and associated
data is invaluable. For a different, and sometimes more data is invaluable. For a different, and sometimes more
comprehensive, view on some of the accumulated stresses on the DNS comprehensive, view on some of the accumulated stresses on the DNS
design, see also RFC 8324 ("DNS Privacy, Authorization, Special Uses, design, see also RFC 8324 ("DNS Privacy, Authorization, Special Uses,
skipping to change at page 4, line 4 skipping to change at page 4, line 16
to new needs is useful to consider, and owes a great deal to the RFCs to new needs is useful to consider, and owes a great deal to the RFCs
already mentioned, especially RFC 6950, which "provides guidance to already mentioned, especially RFC 6950, which "provides guidance to
application designers and application protocol designers looking to application designers and application protocol designers looking to
use the DNS to support features in their applications." The use the DNS to support features in their applications." The
consideration there of how to structure domain names and associated consideration there of how to structure domain names and associated
data is invaluable. For a different, and sometimes more data is invaluable. For a different, and sometimes more
comprehensive, view on some of the accumulated stresses on the DNS comprehensive, view on some of the accumulated stresses on the DNS
design, see also RFC 8324 ("DNS Privacy, Authorization, Special Uses, design, see also RFC 8324 ("DNS Privacy, Authorization, Special Uses,
Encoding, Characters, Matching, and Root Structure: Time for Another Encoding, Characters, Matching, and Root Structure: Time for Another
Look?") Look?")
This document acknowledges that there may be a need to separate This document acknowledges that there may be a need to separate
domain names from DNS protocol in the analysis of new protocol needs. domain names from DNS protocol in the analysis of new protocol needs.
RFC 6950 primarily assumes that the namespace, the database of For example, RFC 6950 primarily assumes that the namespace, the
instantiated names, and the protocol for lookup and retrieval are all database of instantiated names, and the protocol for lookup and
of a piece, while it's become the case recently that people are retrieval are inextricably linked. But more recently, some people
attempting to separate the namespace from specific resolution are attempting to separate the namespace from specific resolution
protocol or even a specific instance of a database of names (namely, protocol or even a specific instance of a database of names (namely,
the global public Internet DNS), with varying degrees of drama and the global public Internet DNS). This poses a lot of potential
varying degrees of success. interoperability risk because assumptions about DNS and domain names
are so deeply embedded in the internet infrastrcuture, and it's
meeting with varying degrees of drama and varying degrees of success.
Recommended reading on the larger questions includes draft-lewis- Recommended reading on the larger questions includes draft-lewis-
domain-names.txt, [RFC1034], [RFC2826], [RFC2860], [RFC6950], domain-names.txt, [RFC1034], [RFC2826], [RFC2860], [RFC6950],
[RFC6055], [RFC6943], [RFC6761], [RFC8244] and [RFC8324]However, this [RFC6055], [RFC6943], [RFC6761], [RFC8244] and [RFC8324]However, this
document will consider them out of scope for the immediate problem of document will consider them out of scope for the immediate problem of
providing guidance on the situation we're already in: RFC 6761 is an providing guidance on the situation we're already in: RFC 6761 is an
IETF standards-track document, the special use names registry has IETF standards-track document, the special use names registry has
been defined, people want to use it, and some uses pose more risk to been defined, people want to use it, and some uses pose more risk to
the interoperability of the Internet than others. the interoperability of the Internet than others.
This document is attempting to address the case where the protocol This document is attempting to address the case where the protocol
designer believes that something like a domain name is suitable for designer believes that something like a domain name is suitable for
their protocol, but the use case can't be satisfied by "normal" DNS-- their protocol, but the use case can't be satisfied by "normal" DNS--
the DNS wire protocol and globally-scoped domain names, resolvable in the DNS wire protocol and globally-scoped domain names, resolvable in
the public DNS database-- so some additional analysis and the public DNS database-- so some additional analysis and
specification is needed. specification is needed.
2. Use Cases 2. Current SUNR Use Cases
Some specific use cases have arisen since the special use names Some specific use cases have arisen since the special use names
registry was established: registry was established:
1. Proponents wish to reserve a name to serve a specific purpose in 1. Proponents wish to reserve a name to serve a specific purpose in
an IETF protocol, discussed as part of protocol definition in an an IETF protocol, discussed as part of protocol definition in an
IETF working group. Resolution of the name may be intended for a IETF working group. Resolution of the name may be intended for a
limited scope (homenet) or outside of the DNS altogether (mDNS, limited scope (homenet) or outside of the DNS altogether (mDNS,
DNSSD) DNSSD)
2. Proponents wish to reserve a name as used in a protocol developed 2. Proponents wish to reserve a name as used in a protocol developed
outside of the IETF, in order to avoid potential collisions with outside of the IETF, in order to avoid potential collisions with
others uses of the namespace such as future IETF protocols or other uses of the namespace. Possible sources of such collisions
ICANN's policies for delegation of top-level domains. (.onion, include future IETF protocols or ICANN's policies for delegation
RFC 7686) of top-level domains. (.onion, RFC 7686)
3. Proponents wish to reserve a name from any use in the public DNS, 3. Proponents wish to reserve a name from any use in the public DNS,
in order to support interoperability and avoid collision or abuse in order to support interoperability and avoid collision or abuse
("localhost," or draft-chapin-additional-reserved-tlds) ("localhost," or draft-chapin-additional-reserved-tlds)
3. Specific guidelines 3. Guidelines for Special Use Name registration
The use cases and constraints described suggest some specific The use cases and constraints described suggest some specific
guidelines for the IESG and the IETF community regarding the use of guidelines for the IESG and the IETF community regarding the use of
the special use names registry: the special use names registry:
1. Location of a name in the namespace is a consideration. A 1. Location of a name in the namespace is a consideration. A
single-label name or "top level domain" can be attractive at single-label name or "top level domain" can be attractive at
first glance: they can be short and human-friendly, and there's first glance: they can be short and human-friendly, and there's
no obvious need to coordinate the use of a top-level label with a no obvious need to coordinate the use of a top-level label with a
TLD operator by, for example, purchasing the use of a second- TLD operator by, for example, purchasing the use of a second-
level domain such as example.org. But the reservation of a TLD level domain such as example.org. But the reservation of a TLD
also poses a unique challenge, whether the proponent is asking also poses a unique challenge, whether the proponent is asking
for it to be reserved from use in the DNS root zone, or asking for it to be reserved from use in the DNS root zone, or asking
for it to be added to the root zone: the IETF administers the for it to be added to the root zone: the IETF administers the
special use name registry, but does not control the root zone. SUNR, but does not control the root zone. Under RFC 2860, ICANN
Under RFC 2860, ICANN has that authority. More discussion on has that authority. More discussion on this point can be seen
this point can be seen below, but for now the important below, but as a practical matter, IETF Working Groups should not
observation is this: RFC 6761 claims that the registry is based make such requests without compelling justification, and the IESG
on a "protocol rule" with unchallengeable precednce over ICANN should not advance them without asking what other options might
policy. However, it's not clear exactly what this means in be available to satisfy relevant technical requirements. (Case:
practice. There's no process for making such a request, and it home.arpa, RFC 8375)
seems likely that the effort of inventing one and coordinating it
with ICANN would not be justified unless there was a compelling
need that couldn't be met any other way. IETF Working Groups
should not make such requests, and the IESG should not advance
them, without such a need. (Case: home.arpa, RFC 8375)
1. Compatibility with an installed base *might* be a compelling 1. Compatibility with an installed base might be a compelling
need to reserve a specific string as a single label or TLD, need to reserve a specific string as a single label or TLD.
but the bar should be *very* high, because of the imposed This does impose a burden of coordination on ICANN, the IETF,
burden of coordination on ICANN, the IETF, and the IAB. and the IAB, and adds to possible confusion for developers
There needs to be significant benefit to interoperability, at and operators across the wider internet, so the bar to
the very least. (Case: .onion, .bit, etc.) proceeding in this way should be high. There should be
significant benefit to interoperability, at the very least.
(Case: .onion, .bit, etc.)
2. Preventing ICANN from delegating a name is *not*, by itself, 2. Preventing ICANN from delegating a name is not, by itself, a
a compelling reason to reserve it. There's no written policy compelling reason to reserve it in the SUNR. There's no
or agreement that says it would work, and ICANN may have no written policy or agreement that says it would work, and
process or policy under which it could determine whether such ICANN may have no process or policy under which it could
a reservation should be granted. Risking name collision determine whether such a reservation should be granted.
under different policies fro different authorities seems Risking name collision under different policies from
unwise, but so does using standards action in one body to different authorities seems unwise, but so does using
constrain policy in another. (Case: home/corp/mail, draft- standards action in one body to constrain policy in another.
chapin-additional-tlds) (Case: home/corp/mail, draft-chapin-additional-tlds)
2. For names reserved as part of an IETF protocol, in a standards- 2. For names reserved as part of an IETF protocol, in a standards-
track RFC coming out of an IETF WG, proponents should consider track RFC coming out of an IETF WG, proponents should consider
using .arpa (see the IAB note on home.arpa, and RFC 3172). This using .arpa (see the IAB note on home.arpa, and RFC 3172). This
can work whether the name is supposed to be instantiated in the can work whether the name is supposed to be instantiated in the
DNS or not, since the IAB sets policy for .arpa. (Case: DNS or not, since the IAB sets policy for .arpa. (Case:
home.arpa) home.arpa)
3. Reserved domain names that aren't TLDs require less work for the 3. Reserved domain names that aren't TLDs require less work for the
community because they don't have to be coordinated with another community because they don't have to be coordinated with another
body. All such names, however, should be thought out as far as body. All such names, however, should be carefully considered
the characteristics discussed above: do they need to exist in the regarding the characteristics discussed above: do they need to
public DNS, or just be valid in a limited scope, or be reserved exist in the public DNS, or just be valid in a limited scope, or
for another protocol? do they need to be human-friendly? etc. be reserved for another protocol? do they have semantic meaning
This may require adding some new questions to the RFC 6761 list, outside of the specific protocol or scope? do they need to be
which talks about how the names are treated by DNS but otherwise human-friendly? etc. This may require adding some new questions
not much about why they're being reserved or how they're being to the RFC 6761 list, which talks about how the names are treated
used. (Case: home.arpa) by DNS but otherwise not much about why they're being reserved or
how they're being used. (Case: home.arpa)
4. For names initially reserved or used outside of the IETF, for 4. For names initially reserved or used outside of the IETF, for
which a proponent wants to add a special use name registry entry, which a proponent wants to add a special use name registry entry,
the bar should be just as high. For single labels in particular, the bar should be just as high. For single labels in particular,
the IESG and the community should require both a stable the IESG and the community should require both a stable
specification and some assurance that a one-time delegation won't specification and some assurance that a one-time delegation won't
multiply as the protocol evolves or the community forks. This multiply as the protocol evolves or the community forks. This
may require a standards-track update to RFC 6761. may require a standards-track update to RFC 6761.
4. More on Domain Name Hierarchy and the Special Case of Top-Level 4. The Special Case of Top-Level Domains
Domains
One key question for all use cases is where in the domain name space One key question for all use cases is where in the domain name space
a given name should go. This is true regardless of whether the name a given name should go. This is true regardless of whether the name
is intended for resolution in the DNS or as a "protocol switch" to is intended for resolution in the DNS or as a "protocol switch" to
invoke another resolution mechanism. invoke another resolution mechanism.
As noted above, all of the cases described in this document are more As noted above, all of the cases described in this document are more
difficult if the proponents are attempting to reserve a single label difficult if the proponents are attempting to reserve a single label
domain name, or "TLD". This is because the IETF delegated authority domain name, or "TLD". This is because the IETF delegated authority
some time ago to ICANN for the contents of the root zone of the DNS some time ago to ICANN for the contents of the root zone of the DNS
(see RFC 2860). (see RFC 2860).
RFC 6761 claims that the SUNR is based on a "protocol rule" with
unchallengeable precedence over ICANN policy. However, it's not
clear exactly what this means in practice. There's no process for
making a request to ICANN to add a TLD to the root zone, or a string
to the list of names ICANN commits won't be delegated, and it seems
likely that the effort of inventing one and coordinating it with
ICANN would not be justified unless there was a compelling need that
couldn't be met any other way.
ICANN has its own community and its own mechanisms for deciding what ICANN has its own community and its own mechanisms for deciding what
names should be allowed (or not) in the DNS root zone, and with what names should be allowed (or not) in the DNS root zone, and with what
constraints. The IETF is not in a position to dictate ICANN's constraints. The IETF is not in a position to dictate ICANN's
decisions about what names to delegate in the root zone, or even decisions about what names to delegate in the root zone, or even
ICANN's policies on what names must not be delegated in the root ICANN's policies on what names must not be delegated in the root
zone. It can be argued that while ICANN is not an SDO, its zone. It can be argued that while ICANN is not an SDO, its
relationship to the IETF is not unlike that of an SDO with an relationship to the IETF is not unlike that of an SDO with an
overlapping interest in a protocol: while neither can dictate process overlapping interest in a protocol: while neither can dictate process
or policy to the other, an accomodation can generally be found when or policy to the other, an accomodation can generally be found when
potential conflicts appear. In the case of the IETF and ICANN, there potential conflicts appear. In the case of the IETF and ICANN, there
are several possible mechanisms. The simplest is probably the IETF are several possible mechanisms. The simplest is probably the IETF
liaison to the ICANN Board of Directors, for which the IAB appoints liaison to the ICANN Board of Directors, for which the IAB appoints
the liaison manager (https://www.iab.org/2018/02/07/call-for- the liaison manager (https://www.iab.org/2018/02/07/call-for-
nominations-ietf-liaison-to-icann-board-of-directors-2/). nominations-ietf-liaison-to-icann-board-of-directors-2/).
In the case of a TLD that the IETF wishes to reserve for "technical In the case of a TLD that the IETF wishes to reserve for "technical
use" (per RFC 2860), there's no established guarantee that ICANN use" (per RFC 2860), there's no clear, mutual understanding of what
won't in the future delegate that name in the public root zone for it means. There's also no established guarantee that ICANN won't in
the DNS. Such a commitment could be requested by the IAB via the the future delegate that name in the public root zone for the DNS.
IETF liaison or some other means, but there's no assurance it would Such a commitment could be requested by the IAB via the IETF liaison
be obtained, or that the reserved name would be equally useful or some other means, but there's no assurance it would be obtained,
without such a commitment. or that the reserved name would be equally useful without such a
commitment.
It may also be the case that the IETF wishes ICANN to delegate a TLD It may also be the case that the IETF wishes ICANN to delegate a TLD
in the root zone, with specific characteristics, for "technical use" in the root zone, with specific characteristics, for "technical use"
within the DNS-- such as the requirement seen in discussion of within the DNS-- such as the requirement seen in discussion of
home.arpa, originally specified as .home, that the name should exist home.arpa, originally specified as .home, that the name should exist
in the root zone so that DNSSEC would work as expected in local in the root zone so that DNSSEC would work as expected in local
environments. Again, such a request could be made, but would place environments. Again, such a request could be made, but would place
an even larger burden on ICANN's policies and processes than a an even larger burden on ICANN's policies and processes than a
request that they commit to not delegating a name at all. There is request that they commit to not delegating a name at all. There is
no way to project how long it would take or whether it would no way to project how long it would take or whether it would
ultimately succeed. ultimately succeed.
For these reasons, the bar for the IESG and the IETF community to For these reasons, the bar for the IESG and the IETF community to
agree to request a TLD in the special use names registry-- either agree to request a TLD in the SUNR-- either that it should never be
that it should never be delegated, or that it should be delegated delegated, or that it should be delegated accordingto conditions set
accordingto conditions set by the IETF-- should be very high indeed. by the IETF-- should be very high indeed. The IESG SHOULD NOT make
The IESG SHOULD NOT make such requests without a compelling reason such requests without a compelling reason that cannot, as a matter of
that cannot, as a matter of technical necessity, be met by a special technical necessity, be met by a special use name elsewhere in the
use name elsewhere in the domain name space. domain name space.
5. Acknowledgements 5. Acknowledgements
This draft is the outcome of many conversations over many months, This draft is the outcome of many conversations over many months,
including discussions in the DNSOP WG, the IAB, and the ICANN SSAC. including discussions in the DNSOP WG, the IAB, and the ICANN SSAC.
Particular thanks to Ed Lewis, Wendy Seltzer, Ralph Droms, Warren Particular thanks to Ed Lewis, Wendy Seltzer, Ralph Droms, Warren
Kumari, Lyman Chapin, Dave Thaler, Brian Trammell, Ted Lemon, David Kumari, Lyman Chapin, Dave Thaler, Olaf Kolkman, Brian Trammell, Ted
Conrad, Andrew Sullivan, Ted Hardie, John Klensin, and everyone who's Lemon, David Conrad, Andrew Sullivan, Ted Hardie, John Klensin, and
expressed exasperation to the author with respect to the issues everyone who's expressed exasperation to the author with respect to
discussed here. the issues discussed here.
6. Informative References 6. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
 End of changes. 26 change blocks. 
102 lines changed or deleted 123 lines changed or added

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