rfc3245.txt

RFC 的详细文档！


RFC 3245   History and Context of ENUM Operational Decisions  March 2002


3.5. Assignment of the .ARPA top level domain

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

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

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

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

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

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

3.7. Summary: ENUM use of .ARPA

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



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

   The ENUM Working Group decided to follow that recommendation.

4. The selection of an operator for E164.ARPA

4.1. Introduction

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

4.2. Name server operator requirements

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

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

4.4. Selecting a particular operator

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

4.5. Country administration of cc subdomains

   Of course, once a subdomain associated with a country code is
   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, with
   no involvement anticipated from the IAB/IETF, the E164.ARPA registry,
   or from the ITU.

5. Procedures to be followed by RIPE NCC

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

6. References

6.1. Normative references

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

6.2.  Informative and explanatory references.

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

   [RFC 2870] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
              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, September
              2000.

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

7. Security Considerations

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

8. IANA Considerations

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

9.  Authors' Addresses

   Internet Architecture Board EMail:  [e-mail]

      Membership at time this document was completed:

      Harald Alvestrand
      Ran Atkinson
      Rob Austein
      Fred Baker
      Steve Bellovin
      Brian Carpenter
      Jon Crowcroft
      Leslie Daigle
      Steve Deering
      Sally Floyd
      Geoff Huston
      John Klensin
      Henning Schulzrinne

   Scott Bradner
   EMail: [e-mail]

   Patrik Faltstrom
   EMail: [e-mail]







Klensin                      Informational                      [Page 9]

RFC 3245   History and Context of ENUM Operational Decisions  March 2002


10. Full Copyright Statement

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

   This document and translations of it may be copied and furnished 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
   document 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 translate 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 provided 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 WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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



















Klensin                      Informational                     [Page 10]