Internet DRAFT - draft-dutcher-enum-root-domain
draft-dutcher-enum-root-domain
Internet Engineering Task Force William Dutcher
Internet-Draft Verisign, Inc.
February 20, 2002
Kevin McCandless
Illuminet, Inc.
Expires: August 20, 2002
Category: Informational
ENUM Root Domain
<draft-dutcher-enum-root-domain-01.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full confor-
mance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engi-
neering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use
Internet Drafts as reference material or to cite them other
than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/lid-abstracts.html.
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html.
2. Abstract
RFC 2916 specifies that the domain e164.arpa is the root
domain for the DNS storage for NAPTR records for ENUMs.
This document proposes that the root domain referenced in
RFC 2916 be changed from e164.arpa to a generic domain, such
as e164.foo. This would give developers of ENUM applica-
tions a greater degree of flexibility in configuring DNS
structures for ENUM. ENUM will still have only one root.
3. Discussion
RFC 2916 specifies that the domain e164.arpa be used as the
root domain for the DNS storage hierarchy for NAPTR records
for ENUMs. However, several contributions have been made to
the ITU-T Study Group 2 proposing alternative roots, as well
as alternative DNS hierarchies.
This document proposes that the root domain referenced in
RFC 2916 be changed from e164.arpa to a generic domain.
-2-
This would allow the developers of ENUM applications, as
well as the providers of DNS infrastructures that support
ENUM, a greater degree of flexibility in configuring DNS
structures that will be used by ENUM. This change will also
allow the RFC to guide the technical specifications of ENUM,
rather than describe policy.
It should be clear that this proposal is not suggesting that
RFC 2916 be updated to allow for multiple values for that
generic domain. In adherence to the goal of RFC 2916, there
still should be one and only one domain at the root of the
ENUM system. This document is simply suggesting that in any
update to RFC 2916 that the value 'e164.arpa' be easily
changeable to another value; especially in light of ongoing
discussions between the IAB and the ITU. The relative merits
of how that generic value is designated are discussed below.
According to RFC 2916, the only DNS domain in which ENUM
NAPTR records should be stored is the e164.arpa domain. The
RFC is specific in this regard, as indicated in the Section
2 of the RFC:
"2. E.164 Numbers and DNS
The domain e164.arpa is being populated in order to provide
the infrastructure in DNS for storage of E.164 numbers. In
order to facilitate distributed operations, this domain is
divided into subdomains. Holders of E.164 numbers, which
want to be listed in DNS, should contact the appropriate
zone administrator in order to be listed, by examining the
SOA resource record associated with zone, just like in nor-
mal DNS operations."
In specifying the use of the e164.arpa domain for ENUM DNS
records, the RFC may force designers of ENUM applications
and systems into using a DNS root domain that does not meet
the operational requirements of an ENUM application. For
example, it may be more practical for an ENUM application to
be in a different root-level domain. Several contributions
to the ENUM Forum and to ITU-T Study Group 2 have suggested
various tiered architectures, each of which may be more
efficient and more practical if they are not tied by the RFC
to the e164.arpa domain.
Since RFC 2916 specifies .arpa as the TLD, it has created a
policy decision rather than a technical decision. As a
result, policy agencies are struggling with the .arpra issue
instead of deciding whether or not global ENUM is an appro-
priate approach. If this policy recommendation is removed
from RFC 2916, these agencies will be able to address the
TLD for ENUM without the burden of the TLD decision having
been presupposed.
Furthermore, the U.S. government supports a domain-neutral
-3-
approach to ENUM implementation. Removing the reference to
the e164.arpa domain for ENUM DNS systems will create a
domain-neutral position in the RFC, and remove a mandate
that may inhibit the flexibility of the design and develop-
ment of ENUM systems.
4. Recommendation
The recommendation is that the references to the e164.arpa
domain in RFC 2916 be changed to refer to a generic domain,
such as e164.foo. Further more, when policy agencies and
industry reach a decision on the root for ENUM, then an
informational draft can be published documenting the agree-
ments.
5. IANA Considerations
There are no IANA issues to consider in this draft. This is
an informational draft.
6. Security Considerations
There are no security considerations in this draft. This is
an informational draft.
7. References
RFC 2915 M. Mealling and R. Daniel, The Naming Authority
Pointer (NAPTR) DNS Resource Record, September 2000.
RFC 2916 P.Faltstrom, E.164 number and DNS, September 2000.
8. Authors Addresses
William Dutcher
VeriSign, Inc.
21355 Ridgetop Circle
Sterling, VA 20166 United States
Phone: +1-703-948-4457
Fax: +1-703-948-4457
Email: bdutcher@verisign.com
Kevin McCandless
Illuminet, Inc.
7400 West 129th Street
Overland Park, KS 66213 United States
Phone: +1-913-814-6397
Fax: +1-913-814-6505
Email: kmccandless@illuminet.com
A. Full Copyright Statement
-4-
Copyright (C) The Internet Society 2002. All Rights
Reserved.
This document and translations of it may be copied and fur-
nished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the
above copyright notice and this paragraph are included on
all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which
case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to trans-
late it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is pro-
vided on an AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR-
RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by
the Internet Society.
