RFC relevance of structure

As per Relevance of the word structure, we have this rfc below:

Network Working Group J. Klensin, Ed
Request for Comments: 3245
Category: Informational March 2002

The History and Context of Telephone Number Mapping (ENUM
Operational Decisions: Informational Documents
to ITU-T Study Group 2 (SG2)

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

RFC 2916 assigned responsibility for a number of administrative
operational details of Telephone Number Mapping (ENUM) to the IAB
It also anticipated that ITU would take responsibility
determining the legitimacy and appropriateness of applicants
delegation of "country code"-level subdomains of the top-level
domain. Recently, three memos have been prepared for the ITU-T
Group 2 (SG2) to explain the background of, and reasoning for,
relevant decisions. The IAB has also supplied a set of
instructions to the RIPE NCC for implementation of their part of
model. The content of the three memos is provided in this
for the information of the IETF community

Table of

1. Introduction: ENUM Background Information ..................... 2
2. Why one and only one domain is used in ENUM ................... 2
3. Why .ARPA was selected as the top level domain for ENUM ....... 4
4. The selection of an operator for E164.ARPA .................... 7
5. Procedures to be followed by RIPE NCC ......................... 8
6. References .................................................... 8
6.1. Normative references ........................................ 8
6.2. Informative and explanatory references ...................... 8
7. Security Considerations ....................................... 9
8. IANA Considerations ........................................... 9
9. Authors' Addresses ............................................ 9
10. Full Copyright Statement ..................................... 10

Klensin Informational [Page 1]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

1. Introduction: ENUM Background

In January 2002, in response to questions from the ITU-T Study
2 (referred to just as "SG2", below), specifically its group
on "Questions 1 and 2", and members of the IETF
telecommunications communities, Scott Bradner, as Area
responsible for the ENUM work and ISOC Vice President for Standards
initiated an effort to produce explanations of the decisions made
the IETF about ENUM administration. The effort to produce and
those documents eventually involved him, Patrik Faltstrom (author
RFC 2916), and several members of the IAB

The documents have now been contributed to ITU-T, and are
published as internal SG2 documents. This document provides the
community a copy of the information provided to SG2. Section 2
contains the same content as COM 2-11-E, section 3 contains the
content as COM 2-12-E, and section 4 contains the same content as SG
document COM 2-10-E. The documents being published within SG2
their source as "THE INTERNET SOCIETY ON BEHALF OF THE IETF",
is a formality deriving from the fact that ISOC holds an ITU
membership on behalf of the IETF

2. Why one and only one domain is used in

2.1.

This contribution is one of a series provided by the IETF to ITU-
SG2 to provide background information about the IETF's ENUM
Group deliberations and decisions. This particular
addresses the IETF's decision that only a single domain could
supported in ENUM

2.2. The need for a single root in the

In the Domain Name System (DNS), each domain name is globally unique
This is a fundamental fact in the DNS system and
mathematically from the structure of that system as well as
resource identification requirements of the Internet. Which
server is authoritative for a specific domain is defined
delegations from the parent domain, and this is repeated
until the so-called root zone, which is handled by a well-known
of DNS servers. Note that words like "authoritative"
"delegation" and their variations are used here in their specific
technical, DNS sense and may not have the same meanings they
would in an ITU context

Klensin Informational [Page 2]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

Given that one starts with the well-known root zone, every
querying the DNS system will end up at the same set of servers
the same domain, regardless of who is sending the query, when
query is sent and where in the network the query is initiated.
May 2000 the IAB published a document on the need for a single
in the DNS. This document explores the issues in greater detail
See RFC 2826 (http://www.ietf.org/rfc/rfc2826.txt).

2.3. Storing E.164 numbers in the

An E.164 number is also globally unique, and because of that it
most of the same properties as a domain name. This was the
why storing E.164 numbers in the DNS system is technically a
mapping. ENUM is just that, a way to store E.164 numbers in the DNS
Multiple ENUM trees in the DNS hierarchy would have the
equivalent of permitting every carrier to assign a different
to an E.164 country code, with each one potentially mapping a
number to a different circuit or rejecting it entirely. For
Internet, if there were multiple trees, there would be no way
determine which domains might contain ENUM records. Thus,
application that uses ENUM facilities would have to be
configured with a list of domains to be searched. This would
the same problems of scaling and updates that led to the
of the DNS

The goal with ENUM is that one party should be able to look
information in DNS, which another party has stored in DNS. This
be possible with only the E.164 number as input to the algorithm

If the party storing information in DNS has two (or more) places
choose from, and chooses one of them, how is a second party
up things to know what place was selected? An analogy would be
one knew only www.whitehouse, and not the TLD, and ask people to
to that website. Is the correct domain name www.whitehouse.gov
www.whitehouse.com or www.whitehouse.se? It should be noted
www.whitehouse.com exists and is a pornography site

Thus, the only way of knowing where to look up E.164/ENUM numbers
DNS is to use one and only one domain, and have everyone agree
what that domain is. Note that ENUM is a system for use with E.164
numbers in their general, global, context. Nothing technical can,
should, try to prevent parties that wish to use ENUM-like mechanisms
or other systems that have the same general structure as
numbers, from working out private, out of band, agreements to
those applications. However, such applications are neither E.164
ENUM, any more than internal extension numbers in a PBX are
considered to be part of either

Klensin Informational [Page 3]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

3. Why .ARPA was selected as the top level domain for

3.1.

This memo is one of a series provided by the IETF to SG2 to
background information about the IETF's ENUM Working
deliberations and decisions. This particular memo addresses
IETF's decision that the ENUM DNS tree would use the .ARPA top
domain

3.2. IAB Statement on Infrastructure Domain and

(Taken from http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt,
2000.)

Over the last several months, the IAB has been reviewing,
discussing with ICANN and other parties, the handling of
Internet Protocol-related infrastructure components that
community has concluded should be placed into the DNS

Historically, the most visible infrastructure domain has been
IPv4 address reverse-mapping domain. This domain was placed in "in
addr.arpa" as part of the initial ARPANET transition strategy
host table naming (see RFC 881-http://www.ietf.org/rfc/ rfc0881.txt).
Other than the IPv4 reverse-mapping subdomain, it became the
active subdomain of that domain as the .ARPA
that were also part of the transition were gradually removed.
infrastructure domains were, in the past, placed under the "INT"
and various organizational names

It is in the interest of general Internet stability, to pay
attention to the placement of secondary DNS servers,
administrative cleanliness, to start rationalizing this situation
locating new infrastructure subdomains in a single domain
migrating existing ones to it as appropriate. It appears that
original infrastructure domain "ARPA", redesignated from
abbreviation for "ARPANET" to an acronym for "Address and
Parameters Area" is best suited for this purpose

3.3. Infrastructure

Operationally, it is easier to ensure good stability for DNS
general if we have as few DNS zones as possible that are used
parameters for infrastructure purposes. Today, new
domains are put in ARPA and old assignments which were made in
domains are being migrated to ARPA. Currently, ARPA is used for in
addr.arpa (for reverse mapping of IPv4 addresses), ip6.arpa, (

Klensin Informational [Page 4]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

reverse mapping of IPv6 addresses), and e164.arpa, (the subject
this memo). In the future, URI schemes, URN namespaces and other
address families will be stored in ARPA

Theoretically, each set of infrastructure parameters could be
in a separate domain as a TLD. (For example, .URI, .UNI, .IPV6,
TLD, which only can be created via the ICANN process (which
take a year or more) and would unnecessarily and undesirably
the DNS tree. It is much easier to have one TLD with easily
new subdomains (2nd level domains), one for each parameter. Thus
was logical to store E.164 numbers in ARPA

3.4. The ARPA domain (derived from RFC 3172, September 2001)

The "arpa" domain was originally established as part of the
deployment of the DNS, to provide a transition mechanism from
Host Tables that were previously standard in the ARPANET. It
also used to provide a permanent home for IPv4 address to
mappings ("reverse mappings") which were previously also
using the Host Table mechanism. The Internet Architecture
(IAB), in cooperation with the Internet Corporation for
Names and Numbers (ICANN), is currently responsible for managing
Top Level Domain (TLD) name "arpa". This arrangement is
in Appendix A of RFC 3172. This domain name provides the root of
name hierarchy of the reverse mapping of IP addresses to
names. More generally, this domain name undertakes a role as
limited use domain for Internet infrastructure applications,
providing a name root for the mapping of particular protocol
to names of service entities. This domain name provides a name
for the mapping of protocol values into lookup keys to
operationally critical protocol infrastructure data records
objects for the Internet

The IAB may add other infrastructure uses to the "arpa" domain in
future. Any such additions or changes will be in accordance with
procedures documented in Section 2.1 and Section 3 of this document
[referring to RFC 3172] This domain is termed an "
domain", as its role is to support the operating infrastructure
the Internet. In particular, the "arpa" domain is not to be used
the same manner (e.g., for naming hosts) as other generic Top
Domains are commonly used

The operational administration of this domain, in accordance with
provisions described in this document, shall be performed by the
under the terms of the MoU between the IAB and ICANN concerning
IANA [RFC 2860].

Klensin Informational [Page 5]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

3.5. Assignment of the .ARPA top level

As documented in appendix A of RFC 3172, on April 28, 2000 the
Department of Commerce, acting under the authority of its
order with ICANN, directed ICANN to operate the .ARPA TLD under
guidance of the IAB, as a limited use domain for
infrastructure applications

3.6. Name Server Requirements for .ARPA (from RFC 3172)

As this domain is part of the operationally critical
of the Internet, the stability, integrity and efficiency of
operation of this domain is a matter of importance for all
users

The "arpa" domain is positioned as a top level domain in order
avoid potential operational instabilities caused by multiple
lookups spanning several operational domains that would be
to locate the servers of each of the parent names of a more
nested infrastructure name. The maximal lookup set for ARPA is
lookup of the name servers for the "arpa" domain from a root server
and the query agent is then provided with a list of
"arpa" name servers

The efficient and correct operation of the "arpa" domain
considered to be sufficiently critical that the
requirements for the root servers apply to the
requirements of the "arpa" servers. All operational
noted in RFC 2870, as they apply to the operational requirements
the root servers, shall apply to the operation of the "arpa" servers
Any revision to RFC 2870 in relation to the operation of the
servers shall also apply to the operation of the "arpa" servers

Many of the servers that are authoritative for the root zone (or
"." zone) also currently serve as authoritative for the "arpa" zone
As noted in RFC 2870, this arrangement is likely to change in
future

3.7. Summary: ENUM use of .

The ARPA domain is the preferred TLD for infrastructure and
use. The ENUM structure should be placed in a single domain
(see separate contribution, COM 2-11), and is expected to evolve
important Internet infrastructure, and hence should be placed there
This decision is facilitated by the MOU between ICANN and IETF
the instructions from the US Government to ICANN, which provide
IAB supervision of that domain. Despite some confusion with the
of a US Department of Defense agency, DARPA, these uses

Klensin Informational [Page 6]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

consistent with all of the historical uses of the ARPA domain,
have been for infrastructure purposes (initially when
hierarchical DNS was created to replace the old flat namespace
ARPANET): the domain was never used for any internal or
DARPA purpose. Recognizing the potential difficulties with
infrastructure domains, the Internet Architecture Board concluded
May 2000 that all new infrastructure information was to be stored
the ARPA domain and existing infrastructure subtrees migrated
as feasible. http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.
provides additional context for these decisions

The ENUM Working Group decided to follow that recommendation

4. The selection of an operator for E164.

4.1.

This contribution is one of a series provided by the IETF to SG2
provide background information about the IETF's ENUM Working
deliberations and decisions. This particular contribution
the IETF's selection of an operator for the E164.ARPA domain

4.2. Name server operator

RFC 2870 (http://www.ietf.org/rfc/rfc2780.txt) describes
requirements for operating DNS root servers. Important DNS-
infrastructure services require that their servers be operated
the same level of attention to reliability and security that the
servers require. In addition, for an infrastructure service such
E164.ARPA some additional requirements were felt by the IAB to
important. Organizations that operate core services such as IN
ADDR.ARPA and E164.ARPA must have a history of reliable operation
DNS servers and be highly respected and known for both their
technical skills and their fairness and impartiality. In addition
the IAB felt that the organization that operates such
domains must be a non-profit and public-service-oriented one
remove any incentive for exploitative behavior based on
motives that depend on, e.g., the number of records in the
even if some reasonable registration fee is charged to recover costs
The IAB also felt that they wanted an organization with good (
extensive) experience working with governments when necessary and
with experience working with the IAB and the IETF more generally

Klensin Informational [Page 7]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

4.3. Evaluating possible

The IAB researched various options for operators and came to
conclusion that the regional IP address registries (RIRs) met all
the criteria. They all had extensive experience providing
supporting infrastructure services reliably and securely and
three of them had a long history of working with the IETF

4.4. Selecting a particular

Given that all of the RIRs would have met the criteria, the
of a particular RIR required looking at other factors. The
concluded that RIPE NCC would be the best operator for E164.ARPA
based largely on their somewhat greater experience in running
servers and on their location in a neutral legal jurisdiction

4.5. Country administration of cc

Of course, once a subdomain associated with a country code
assigned for registration and operations to an appropriately
designated entity for the associated country or numbering plan
administration of that subdomain is entirely a National Matter,
no involvement anticipated from the IAB/IETF, the E164.ARPA registry
or from the ITU

5. Procedures to be followed by RIPE

The IAB and the RIPE NCC have agreed on procedures for the latter
follow in making ENUM registrations at the country code level.
instructions are expected to evolve as experience is accumulated
Current versions will be posted on the IAB and/or RIPE NCC web sites

6.

6.1. Normative

None. This document is intended to be self-contained and
informational

6.2. Informative and explanatory references

[RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum
Understanding Concerning the Technical Work of
Internet Assigned Numbers Authority", RFC 2860, June 2000.

[RFC 2870] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "
Name Server Operational Requirements", BCP 40, RFC 2870,
June 2000.

Klensin Informational [Page 8]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

[RFC 2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
2000.

[RFC 3172] Huston, G., Ed., "Management Guidelines &
Requirements for the Address and Routing Parameter
Domain ('arpa')", BCP 52, RFC 3172, September 2001.

7. Security

This document provides information only and raises no new
issues. The security issues associated with the underlying
are described in RFC 2916.

8. IANA

There are no IANA considerations regarding this document. Sections 3
and 4 contain a record of actions already performed by IANA
partial explanations for them

9. Authors'

Internet Architecture Board EMail: iab@iab.

Membership at time this document was completed

Harald
Ran
Rob
Fred
Steve
Brian
Jon
Leslie
Steve
Sally
Geoff
John
Henning

Scott
EMail: sob@harvard.

Patrik
EMail: paf@cisco.

Klensin Informational [Page 9]

RFC 3245 History and Context of ENUM Operational Decisions March 2002

10. Full Copyright

Copyright (C) The Internet Society (2002). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Klensin Informational [Page 10]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX