Network Working Group J. Klensin, Ed.
Request for Comments: 3245 IAB
Category: Informational March 2002
Network Working Group J. Klensin, Ed.
Request for Comments: 3245 IAB
Category: Informational March 2002
The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2)
电话号码映射（ENUM）操作决策的历史和背景：向ITU-T研究小组2（SG2）提供的信息性文件
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB. It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T Study Group 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community.
RFC 2916指定负责IAB电话号码映射（ENUM）的许多管理和操作细节。它还预计，国际电联将负责确定申请授权顶级ENUM域名的“国家代码”级子域的合法性和适当性。最近，为ITU-T研究小组2（SG2）编写了三份备忘录，以解释相关决定的背景和理由。IAB还向成熟的NCC提供了一套程序说明，以实施其模型部分。本文件提供了三份备忘录的内容，供IETF社区参考。
Table of Contents
目录
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
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
In January 2002, in response to questions from the ITU-T Study Group 2 (referred to just as "SG2", below), specifically its group working on "Questions 1 and 2", and members of the IETF and telecommunications communities, Scott Bradner, as Area Director responsible for the ENUM work and ISOC Vice President for Standards, initiated an effort to produce explanations of the decisions made by the IETF about ENUM administration. The effort to produce and refine those documents eventually involved him, Patrik Faltstrom (author of RFC 2916), and several members of the IAB.
2002年1月，针对ITU-T第2研究组（以下简称“SG2”）提出的问题，特别是其“问题1和2”工作组以及IETF和电信界成员提出的问题，Scott Bradner作为负责ENUM工作的区域主任和ISOC标准副总裁，开始努力对IETF关于ENUM管理的决定做出解释。他、帕特里克·法尔茨特罗姆（RFC2916的作者）和IAB的几名成员最终参与了制作和完善这些文件的工作。
The documents have now been contributed to ITU-T, and are being published as internal SG2 documents. This document provides the IETF community a copy of the information provided to SG2. Section 2 below contains the same content as COM 2-11-E, section 3 contains the same content as COM 2-12-E, and section 4 contains the same content as SG2 document COM 2-10-E. The documents being published within SG2 show their source as "THE INTERNET SOCIETY ON BEHALF OF THE IETF", which is a formality deriving from the fact that ISOC holds an ITU sector membership on behalf of the IETF.
这些文件现已提交ITU-T，并作为内部SG2文件发布。本文件向IETF社区提供了一份提供给SG2的信息副本。以下第2节包含与COM 2-11-E相同的内容，第3节包含与COM 2-12-E相同的内容，第4节包含与SG2文件COM 2-10-E相同的内容。SG2内发布的文件显示其来源为“代表IETF的互联网协会”，这是一种形式，源于ISOC代表IETF持有ITU部门成员资格这一事实。
This contribution is one of a series provided by the IETF to ITU-T SG2 to provide background information about the IETF's ENUM Working Group deliberations and decisions. This particular contribution addresses the IETF's decision that only a single domain could be supported in ENUM.
本文件是IETF向ITU-T SG2提供的一系列文件之一，旨在提供IETF ENUM工作组审议和决定的背景信息。这一特殊贡献解决了IETF的决定，即ENUM中只能支持单个域。
In the Domain Name System (DNS), each domain name is globally unique. This is a fundamental fact in the DNS system and follows mathematically from the structure of that system as well as the resource identification requirements of the Internet. Which DNS server is authoritative for a specific domain is defined by delegations from the parent domain, and this is repeated recursively until the so-called root zone, which is handled by a well-known set of DNS servers. Note that words like "authoritative" and "delegation" and their variations are used here in their specific, technical, DNS sense and may not have the same meanings they normally would in an ITU context.
在域名系统（DNS）中，每个域名都是全局唯一的。这是DNS系统中的一个基本事实，并从数学上遵循该系统的结构以及Internet的资源标识要求。对于特定域，哪个DNS服务器是权威的由来自父域的委托定义，并且递归地重复此操作，直到所谓的根区域，该区域由一组众所周知的DNS服务器处理。请注意，“权威”和“授权”等词及其变体在此处的具体、技术、DNS含义中使用，可能与ITU上下文中通常使用的含义不同。
Given that one starts with the well-known root zone, every party querying the DNS system will end up at the same set of servers for the same domain, regardless of who is sending the query, when the query is sent and where in the network the query is initiated. In May 2000 the IAB published a document on the need for a single root in the DNS. This document explores the issues in greater detail. See RFC 2826 (http://www.ietf.org/rfc/rfc2826.txt).
假设从众所周知的根区域开始，查询DNS系统的每一方都将在同一域的同一组服务器上结束，而不管是谁发送查询、何时发送查询以及在网络中的何处发起查询。2000年5月，IAB发布了一份关于DNS中需要单个根目录的文件。本文档将更详细地探讨这些问题。见RFC 2826(http://www.ietf.org/rfc/rfc2826.txt).
An E.164 number is also globally unique, and because of that it has most of the same properties as a domain name. This was the reason why storing E.164 numbers in the DNS system is technically a simple 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 telephony equivalent of permitting every carrier to assign a different meaning to an E.164 country code, with each one potentially mapping a given number to a different circuit or rejecting it entirely. For the Internet, if there were multiple trees, there would be no way to determine which domains might contain ENUM records. Thus, each application that uses ENUM facilities would have to be manually configured with a list of domains to be searched. This would incur the same problems of scaling and updates that led to the development of the DNS.
E.164编号也是全局唯一的，因此它具有与域名相同的大部分属性。这就是为什么在DNS系统中存储E.164号码在技术上是一个简单的映射。ENUM就是这样，一种在DNS中存储E.164号码的方法。DNS层次结构中的多个ENUM树在电话方面相当于允许每个运营商为E.164国家代码分配不同的含义，每个运营商都可能将给定的数字映射到不同的电路或完全拒绝它。对于Internet，如果有多个树，则无法确定哪些域可能包含枚举记录。因此，每个使用枚举功能的应用程序都必须手动配置要搜索的域列表。这将引发与DNS开发相同的扩展和更新问题。
The goal with ENUM is that one party should be able to look up information in DNS, which another party has stored in DNS. This must be possible with only the E.164 number as input to the algorithm.
ENUM的目标是一方应该能够在DNS中查找另一方存储在DNS中的信息。只有将E.164号作为算法的输入，才能实现这一点。
If the party storing information in DNS has two (or more) places to choose from, and chooses one of them, how is a second party looking up things to know what place was selected? An analogy would be if one knew only www.whitehouse, and not the TLD, and ask people to go to that website. Is the correct domain name www.whitehouse.gov, www.whitehouse.com or www.whitehouse.se? It should be noted that www.whitehouse.com exists and is a pornography site.
如果在DNS中存储信息的一方有两个（或多个）位置可供选择，并选择其中一个，那么第二方如何查找信息以了解选择的位置？打个比方，如果一个人只知道www.whitehouse，而不知道TLD，并要求人们访问该网站。正确的域名是www.whitehouse.gov、www.whitehouse.com还是www.whitehouse.se？应该注意的是，www.whitehouse.com是一个色情网站。
Thus, the only way of knowing where to look up E.164/ENUM numbers in DNS is to use one and only one domain, and have everyone agree on what that domain is. Note that ENUM is a system for use with E.164 numbers in their general, global, context. Nothing technical can, or should, try to prevent parties that wish to use ENUM-like mechanisms, or other systems that have the same general structure as telephone numbers, from working out private, out of band, agreements to support those applications. However, such applications are neither E.164 nor ENUM, any more than internal extension numbers in a PBX are normally considered to be part of either.
因此，知道在DNS中从何处查找E.164/ENUM编号的唯一方法是使用一个且仅使用一个域，并让每个人都同意该域是什么。请注意，ENUM是一个在通用、全局上下文中与E.164数字一起使用的系统。任何技术手段都不能也不应该试图阻止希望使用类似于ENUM的机制或与电话号码具有相同总体结构的其他系统的各方制定支持这些应用程序的专用带外协议。然而，这类应用既不是E.164也不是ENUM，就像PBX中的内部分机号码通常被认为是其中的一部分一样。
This memo 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 memo addresses the IETF's decision that the ENUM DNS tree would use the .ARPA top level domain.
本备忘录是IETF向SG2提供的一系列备忘录之一，旨在提供IETF ENUM工作组审议和决定的背景信息。此特定备忘录涉及IETF的决定，即ENUM DNS树将使用.ARPA顶级域。
(Taken from http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt, May 2000.)
（摘自http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt，2000年5月）
Over the last several months, the IAB has been reviewing, and discussing with ICANN and other parties, the handling of various Internet Protocol-related infrastructure components that the community has concluded should be placed into the DNS.
在过去的几个月里，IAB一直在审查并与ICANN和其他各方讨论各种互联网协议相关基础设施组件的处理，社区认为这些组件应该放在DNS中。
Historically, the most visible infrastructure domain has been the IPv4 address reverse-mapping domain. This domain was placed in "in-addr.arpa" as part of the initial ARPANET transition strategy from host table naming (see RFC 881-http://www.ietf.org/rfc/ rfc0881.txt). Other than the IPv4 reverse-mapping subdomain, it became the only active subdomain of that domain as the <host-table-name>.ARPA names that were also part of the transition were gradually removed. Other infrastructure domains were, in the past, placed under the "INT" TLD and various organizational names.
历史上，最明显的基础结构域是IPv4地址反向映射域。这个域被放置在“in addr.arpa”中，作为从主机表命名到初始ARPANET转换策略的一部分（参见RFC 881）-http://www.ietf.org/rfc/ rfc0881.txt）。除了IPv4反向映射子域之外，它成为该域的唯一活动子域，因为<host table name>。同时也是转换的一部分的ARPA名称被逐渐删除。过去，其他基础设施域被置于“INT”TLD和各种组织名称之下。
It is in the interest of general Internet stability, to pay adequate attention to the placement of secondary DNS servers, and administrative cleanliness, to start rationalizing this situation by locating new infrastructure subdomains in a single domain and migrating existing ones to it as appropriate. It appears that our original infrastructure domain "ARPA", redesignated from an abbreviation for "ARPANET" to an acronym for "Address and Routing Parameters Area" is best suited for this purpose.
为了维护互联网的整体稳定性，应充分注意二级DNS服务器的位置和管理的清洁度，通过在单个域中定位新的基础设施子域并将现有子域迁移到该子域（视情况而定），开始合理化这种情况。我们最初的基础设施领域“ARPA”，从“ARPANET”的缩写改为“地址和路由参数区域”的首字母缩略词，似乎最适合这一目的。
Operationally, it is easier to ensure good stability for DNS in general if we have as few DNS zones as possible that are used for parameters for infrastructure purposes. Today, new infrastructure domains are put in ARPA and old assignments which were made in other domains are being migrated to ARPA. Currently, ARPA is used for in-addr.arpa (for reverse mapping of IPv4 addresses), ip6.arpa, (for
从操作上讲，如果我们有尽可能少的用于基础设施参数的DNS区域，则通常更容易确保DNS的良好稳定性。今天，新的基础设施域被放入ARPA，在其他域中进行的旧分配正在迁移到ARPA。目前，ARPA用于in-addr.ARPA（用于IPv4地址的反向映射），ip6.ARPA（用于
reverse mapping of IPv6 addresses), and e164.arpa, (the subject of this memo). In the future, URI schemes, URN namespaces and other new address families will be stored in ARPA.
IPv6地址的反向映射）和e164.arpa（本备忘录主题）。将来，URI方案、URN名称空间和其他新地址系列将存储在ARPA中。
Theoretically, each set of infrastructure parameters could be stored in a separate domain as a TLD. (For example, .URI, .UNI, .IPV6, new TLD, which only can be created via the ICANN process (which might take a year or more) and would unnecessarily and undesirably flatten the DNS tree. It is much easier to have one TLD with easily created new subdomains (2nd level domains), one for each parameter. Thus it was logical to store E.164 numbers in ARPA.
理论上，每一组基础设施参数都可以作为TLD存储在单独的域中。（例如，.URI、.UNI、.IPV6、新TLD，只能通过ICANN流程创建（可能需要一年或更长时间），并且会不必要且不必要地平坦DNS树。使用一个TLD和易于创建的新子域（二级域）要容易得多），每个参数一个。因此，在ARPA中存储E.164数字是合乎逻辑的。
The "arpa" domain was originally established as part of the initial deployment of the DNS, to provide a transition mechanism from the Host Tables that were previously standard in the ARPANET. It was also used to provide a permanent home for IPv4 address to name mappings ("reverse mappings") which were previously also handled using the Host Table mechanism. The Internet Architecture Board (IAB), in cooperation with the Internet Corporation for Assigned Names and Numbers (ICANN), is currently responsible for managing the Top Level Domain (TLD) name "arpa". This arrangement is documented in Appendix A of RFC 3172. This domain name provides the root of the name hierarchy of the reverse mapping of IP addresses to domain names. More generally, this domain name undertakes a role as a limited use domain for Internet infrastructure applications, by providing a name root for the mapping of particular protocol values to names of service entities. This domain name provides a name root for the mapping of protocol values into lookup keys to retrieve operationally critical protocol infrastructure data records or objects for the Internet.
“arpa”域最初是作为DNS初始部署的一部分建立的，以提供一种从以前在ARPANET中是标准的主机表的转换机制。它还用于为IPv4地址到名称映射（“反向映射”）提供一个永久的主位置，以前也使用主机表机制处理这些映射。互联网体系结构委员会（IAB）与互联网名称和数字分配公司（ICANN）合作，目前负责管理顶级域名“arpa”。该安排记录在RFC 3172附录A中。此域名提供IP地址到域名反向映射的名称层次结构的根。更一般地说，该域名通过为特定协议值到服务实体名称的映射提供名称根，作为Internet基础设施应用程序的有限使用域发挥作用。此域名提供了一个名称根，用于将协议值映射到查找键中，以检索Internet的操作关键协议基础结构数据记录或对象。
The IAB may add other infrastructure uses to the "arpa" domain in the future. Any such additions or changes will be in accordance with the procedures documented in Section 2.1 and Section 3 of this document. [referring to RFC 3172] This domain is termed an "infrastructure domain", as its role is to support the operating infrastructure of the Internet. In particular, the "arpa" domain is not to be used in the same manner (e.g., for naming hosts) as other generic Top Level Domains are commonly used.
IAB将来可能会在“arpa”域中添加其他基础设施用途。任何此类添加或更改将符合本文件第2.1节和第3节中记录的程序。[参考RFC 3172]该领域被称为“基础设施领域”，因为其作用是支持互联网的运营基础设施。特别是，“arpa”域的使用方式与通常使用的其他通用顶级域不同（例如，用于命名主机）。
The operational administration of this domain, in accordance with the provisions described in this document, shall be performed by the IANA under the terms of the MoU between the IAB and ICANN concerning the IANA [RFC 2860].
根据本文件所述规定，IANA应根据IAB与ICANN之间关于IANA的谅解备忘录[RFC 2860]的条款执行该领域的运营管理。
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.
如RFC 3172附录A所述，2000年4月28日，美国商务部根据其与ICANN的采购订单授权，指示ICANN在IAB的指导下运营.ARPA TLD，作为互联网基础设施应用的有限使用域。
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.
“arpa”域被定位为顶级域，以避免由于跨多个操作域的多个DNS查找而导致的潜在操作不稳定，而这些操作域是定位更深入嵌套的基础结构名称的每个父名称的服务器所必需的。ARPA的最大查找集是从根服务器查找“ARPA”域的名称服务器，然后向查询代理提供权威的“ARPA”名称服务器列表。
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.
“arpa”域的有效和正确运行被认为是非常关键的，根服务器的运行要求适用于“arpa”服务器的运行要求。RFC 2870中所述的所有操作要求适用于根服务器的操作要求，应适用于“arpa”服务器的操作。与根服务器操作相关的RFC 2870的任何修订也应适用于“arpa”服务器的操作。
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.
许多对根区域（或“.”区域）具有权威性的服务器目前也对“arpa”区域具有权威性。如RFC 2870所述，这种安排在未来可能会发生变化。
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
ARPA域是基础设施和参数使用的首选TLD。ENUM结构应该放在一个域子树中（参见单独的贡献，COM 2-11），并有望发展成为重要的互联网基础设施，因此应该放在那里。ICANN和IETF之间的谅解备忘录以及美国政府向ICANN发出的指示促进了这一决定，其中规定了IAB对该领域的监督。尽管与美国国防部机构DARPA的名称有些混淆，但这些用途仍然存在
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.
与ARPA域的所有历史用途一致，ARPA域一直用于基础设施用途（最初创建分层DNS以取代旧的ARPANET平面名称空间时）：该域从未用于任何内部或特定DARPA用途。认识到多个基础设施领域可能存在的困难，互联网体系结构委员会于2000年5月得出结论，所有新的基础设施信息都将存储在ARPA领域，现有的基础设施子树将尽可能迁移到ARPA领域。http://www.iab.org/iab/DOCUMENTS/iab-arpa-stmt.txt 为这些决策提供额外的上下文。
The ENUM Working Group decided to follow that recommendation.
ENUM工作组决定遵循这项建议。
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.
本文件是IETF向SG2提供的一系列文件之一，旨在提供IETF ENUM工作组审议和决定的背景信息。这一特殊贡献解决了IETF为E164.ARPA域选择一个运营商的问题。
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.
RFC2870(http://www.ietf.org/rfc/rfc2780.txt)描述操作DNS根服务器的要求。重要的基于DNS的基础设施服务要求其服务器在运行时与根服务器在可靠性和安全性方面的关注程度相同。此外，对于E164.ARPA等基础设施服务，IAB认为一些额外的要求很重要。运营核心服务（如IN-ADDR.ARPA和E164.ARPA）的组织必须具有DNS服务器可靠运行的历史，并因其相关技术技能和公平性而受到高度尊重和认可。此外，IAB认为，运营此类基础设施领域的组织必须是非营利和面向公共服务的组织，以消除基于利润动机的任何剥削行为动机，这些动机取决于（例如）数据库中的记录数，即使收取一些合理的注册费以收回成本。IAB还认为，他们需要一个在必要时具有良好（广泛）与政府合作经验的组织，以及一个更广泛地具有与IAB和IETF合作经验的组织。
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.
IAB研究了运营商的各种选择，得出结论，区域IP地址注册（RIR）符合所有标准。他们都拥有可靠、安全地提供和支持基础设施服务的丰富经验，并且三人都有与IETF合作的悠久历史。
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.
鉴于所有RIR都符合标准，选择特定RIR需要考虑其他因素。IAB的结论是，成熟的NCC将是E164.ARPA的最佳运营商，这主要是基于他们在运行DNS服务器方面的更丰富经验以及他们在中立法律管辖区的位置。
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.
当然，一旦将与国家代码相关的子域分配给相关国家或编号计划的适当指定实体进行注册和操作，该子域的管理就完全是国家事务，预计IAB/IETF、E164.ARPA注册中心或ITU不会参与。
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.
IAB和NCC已就后者在国家代码级别进行ENUM注册时应遵循的程序达成一致。随着经验的积累，这些指示将不断发展。当前版本将发布在IAB和/或NCC网站上。
None. This document is intended to be self-contained and purely informational.
没有一个本文件是独立的，仅供参考。
6.2. Informative and explanatory references.
6.2. 资料性和解释性参考文献。
[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 2860]Carpenter，B.，Baker，F.和M.Roberts，“关于互联网分配号码管理局技术工作的谅解备忘录”，RFC 2860，2000年6月。
[RFC 2870] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
[RFC 2870]Bush，R.，Karrenberg，D.，Kosters，M.和R.Plzak，“根名称服务器操作要求”，BCP 40，RFC 2870，2000年6月。
[RFC 2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[RFC 2916]Faltstrom，P.，“E.164数字和DNS”，RFC 2916，2000年9月。
[RFC 3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ('arpa')", BCP 52, RFC 3172, September 2001.
[RFC 3172]Huston，G.，Ed.“地址和路由参数区域域（“arpa”）的管理指南和操作要求”，BCP 52，RFC 3172，2001年9月。
This document provides information only and raises no new security issues. The security issues associated with the underlying protocols are described in RFC 2916.
本文档仅提供信息，不涉及新的安全问题。RFC 2916中描述了与基础协议相关的安全问题。
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.
关于本文件，没有IANA考虑事项。第3节和第4节包含IANA已经执行的行动的记录和部分解释。
Internet Architecture Board EMail: iab@iab.org
互联网架构委员会电子邮件：iab@iab.org
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
哈拉尔·阿尔维斯特兰德（Harald Alvestrand）经营着阿特金森（Atkinson）、罗布·奥斯汀（Rob Austein）、弗雷德·贝克（Fred Baker）、史蒂夫·贝洛文（Steve Bellovin）、布莱恩·卡彭特（Brian Carpenter）、乔恩·克劳克罗夫特（Jon Crowcroft）、莱斯利·戴格尔（Leslie Daigle）、
Scott Bradner EMail: sob@harvard.edu
Scott Bradner电子邮件：sob@harvard.edu
Patrik Faltstrom EMail: paf@cisco.com
Patrik Faltstrom电子邮件：paf@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。