Network Working Group S. Lind
Request for Comments: 5067 AT&T Labs
Category: Informational P. Pfautz
AT&T
November 2007
Network Working Group S. Lind
Request for Comments: 5067 AT&T Labs
Category: Informational P. Pfautz
AT&T
November 2007
Infrastructure ENUM Requirements
基础架构枚举要求
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.)
本文件规定了“基础设施”或“运营商”ENUM（E.164号码映射）的要求，定义为使用RFC 3761技术促进E.164号码寻址服务的网络互连，特别是但不限于VoIP（IP语音）
Table of Contents
目录
1. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Infrastructure ENUM . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
1. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements for Infrastructure ENUM . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Infrastructure ENUM is defined as the use of the technology in RFC 3761 [1] by the carrier-of-record (as defined below) for a specific E.164 number [2] to publish the mapping of the E.164 number into a URI [3] that identifies a specific point of interconnection to that service provider's network. It is separate from any URIs that the end user, who registers their E.164 number, may wish to associate with that E.164 number.
Infrastructure ENUM定义为记录载体（定义见下文）使用RFC 3761[1]中的技术，针对特定的E.164编号[2]，将E.164编号的映射发布到URI[3]，该URI识别到该服务提供商网络的特定互连点。它与注册其E.164号码的最终用户可能希望与该E.164号码关联的任何URI是分开的。
"Infrastructure ENUM" is distinguished from "End User ENUM", defined in RFC3761 [1], in which the entity or person having the right to use a number has the sole discretion about the content of the associated domain and thus the zone content. From a domain registration perspective, the end user number assignee is thus the registrant. Within the infrastructure ENUM namespace, we use the term "carrier-of-record" for the entity having discretion over the domain and zone content and acting as the registrant. The "carrier-of-record" is:
“基础设施枚举”与RFC3761[1]中定义的“最终用户枚举”不同，在RFC3761[1]中，有权使用数字的实体或个人对相关域的内容以及区域内容拥有唯一的自由裁量权。从域名注册的角度来看，最终用户号码受让人就是注册人。在infrastructure ENUM名称空间中，我们使用术语“记录载体”来表示对域和区域内容拥有自由裁量权并充当注册人的实体。“记录载体”是：
o The Service Provider to which the E.164 number was allocated for end user assignment, whether by the National Regulatory Authority (NRA) or the International Telecommunication Union (ITU), for instance, a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878) or,
o 国家管理局（NRA）或国际电信联盟（ITU）为最终用户分配了E.164号码的服务提供商，例如，“国际网络”（+882）或“通用个人电信（UPT）”（+878）下的代码；或，
o if the number is ported, the service provider to which the number was ported, or
o 如果该号码已被移植，则该号码被移植到的服务提供商，或
o where numbers are assigned directly to end users, the service provider that the end user number assignee has chosen to provide a Public Switched Telephone Network/Public Land Mobile Network (PSTN/ PLMN) point-of-interconnect for the number.
o 如果号码直接分配给最终用户，则指最终用户号码受让人选择为号码提供公共交换电话网络/公共陆地移动网络（PSTN/PLMN）互连点的服务提供商。
It is understood that the definition of carrier-of-record within a given jurisdiction is subject to modification by national authorities.
据了解，特定管辖区内记录载体的定义可由国家当局修改。
Voice service providers use E.164 numbers currently as their main naming and routing vehicle. Infrastructure ENUM in e164.arpa or another publicly available tree allows service providers to link Internet-based resources such as URIs to E.164 numbers. This allows service providers, in addition to interconnecting via the PSTN/PLMN (or exclusively), to peer via IP-based protocols. Service providers may announce all E.164 numbers or number ranges they host, regardless of whether the final end user device is on the Internet, on IP-based open or closed Next Generation Networks (NGNs), or on the PSTN or PLMN, provided that an access point of some type to the destination service provider's network is available on the Internet. There is also no guarantee that the originating service provider querying infrastructure ENUM is able to access the ingress network element of the destination provider's network. Additional peering and accounting agreements requiring authentication may be necessary. The access provided may also be to a shared network of a group of providers, resolving the final destination network within the shared network.
语音服务提供商目前使用E.164号码作为其主要的命名和路由工具。e164.arpa或其他公共可用树中的基础设施枚举允许服务提供商将基于Internet的资源（如URI）链接到E.164号码。这使得服务提供商除了通过PSTN/PLMN（或专用）互连外，还可以通过基于IP的协议进行对等。服务提供商可宣布其承载的所有E.164号码或号码范围，无论最终用户设备是否在互联网上、在基于IP的开放式或封闭式下一代网络（NGN）上、或在PSTN或PLMN上，只要在互联网上有某种类型的到目的地服务提供商网络的接入点可用。也不能保证发起服务提供商查询基础设施ENUM能够访问目标提供商网络的入口网元。可能需要其他需要身份验证的对等和记帐协议。所提供的访问还可以是对一组提供商的共享网络的访问，解析共享网络内的最终目的地网络。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC2119[4]中的描述进行解释。
1. Infrastructure ENUM SHALL provide a means for a provider to populate DNS resource records (RRs) for the E.164 numbering resources for which it is the carrier-of-record in a single common publicly accessible namespace. The single common namespace ultimately designated may or may not be the same as that designated for End User ENUM (e164.arpa.) The Fully-Qualified Domain Name (FQDN) in the resulting resource records will not necessarily belong to or identify the carrier-of-record.
1. Infrastructure ENUM应为提供商提供一种方法，以填充E.164编号资源的DNS资源记录（RRs），该资源是单个公共可访问命名空间中的记录载体。最终指定的单个公共名称空间可能与为最终用户ENUM（e164.arpa）指定的名称空间相同，也可能不同。结果资源记录中的完全限定域名（FQDN）不一定属于或标识记录的载体。
2. Queries of infrastructure ENUM fully qualified domain names MUST return a result, even if the result is Refused (RCODE = 5). Queries must not be rejected without response, e.g., based on access control lists.
2. 查询基础结构枚举完全限定域名必须返回结果，即使结果被拒绝（RCODE=5）。在没有响应的情况下不得拒绝查询，例如，基于访问控制列表。
3. Infrastructure ENUM SHALL support RRs providing a URI that can identify a point of interconnection for delivery to the carrier-of-record of communications addressed to the E.164 number.
3. 基础设施ENUM应支持RRs，该RRs提供一个URI，该URI可识别一个互连点，以便将发送至E.164号码的通信记录传送给运营商。
4. Infrastructure ENUM SHOULD be able to support an Internet Registry Information Service (IRIS) [5] capability that allows qualified parties to obtain information regarding the E.164 numbering resources and the corresponding carrier-of-record. Determination of what information, if any, shall be available which parties for geographic numbers is a national matter.
4. Infrastructure ENUM应能够支持互联网注册信息服务（IRIS）[5]功能，该功能允许合格方获取有关E.164编号资源和相应记录载体的信息。确定哪些缔约方可获得哪些地理数字信息（如有）是国家事务。
5. Implementation of infrastructure ENUM MUST NOT restrict the ability of an end user, in a competitive environment, to choose a Registrar and/or name server provider for End User ENUM registrations.
5. 基础设施枚举的实施不得限制最终用户在竞争环境中为最终用户枚举注册选择注册器和/或名称服务器提供商的能力。
6. The domain name chosen for infrastructure ENUM and any parent domains MUST be hosted on name servers that have performance characteristics and supporting infrastructure that is comparable to those deployed for the Internet root name servers. Those name servers for infrastructure ENUM should be configured and operated according to the guidelines described in [6].
6. 为基础结构枚举选择的域名和任何父域必须托管在名称服务器上，这些服务器的性能特征和支持基础结构与为Internet根名称服务器部署的基础结构相当。应根据[6]中所述的指导原则配置和操作基础结构枚举的名称服务器。
7. Infrastructure ENUM MUST meet all reasonable privacy concerns about visibility of information over which an end user has no control. It should, for example, support mechanisms to prevent
7. Infrastructure ENUM必须满足有关最终用户无法控制的信息可见性的所有合理隐私问题。例如，它应该支持预防犯罪的机制
discovery of unlisted numbers by comparison of ENUM registrations against directory listings, or inadvertent disclosure of user identity.
通过将枚举注册与目录列表进行比较或无意中泄露用户身份来发现未列出的号码。
8. Proposed implementations of infrastructure ENUM SHOULD:
8. 基础设施枚举的拟议实施应：
A. Minimize changes required to existing requirements that are part of RFC 3761.
A.尽量减少对RFC 3761中现有要求的变更。
B. Work with open as well as closed numbering plans.
B.使用开放式和封闭式编号计划。
C. Not require additional functionality of resolvers at large though they may require additional functionality in service provider resolvers that would make use of infrastructure ENUM.
C.一般不需要解析程序的附加功能，尽管它们可能需要使用基础结构枚举的服务提供商解析程序中的附加功能。
D. Minimize the number of lookups required to obtain as many NAPTR (Naming Authority Pointer) records (end user and infrastructure) as possible.
D.尽量减少所需的查找次数，以获得尽可能多的NAPTR（命名机构指针）记录（最终用户和基础设施）。
E. Minimize knowledge of the numbering plan required of resolvers making use of Infrastructure ENUM.
E.尽量减少使用基础设施枚举的分解器所需的编号计划知识。
F. Maximize synergies with End User ENUM.
F.最大限度地发挥与最终用户ENUM的协同作用。
G. Support interworking with private ENUM trees. (In this context, a private ENUM tree is one that is not under e164.arpa or whatever namespace is chosen for infrastructure ENUM but uses instead a privately held domain.)
G.支持与私有枚举树的交互。（在此上下文中，私有枚举树不在e164.arpa或为基础结构枚举选择的任何名称空间之下，而是使用私有域。）
Existing security considerations for ENUM (detailed in [1]) still apply. Since infrastructure ENUM involves carriers where RFC 3761 mainly considered indviduals, implementations meeting these requirements SHOULD reconsider the RFC 3761 security model given this difference in actors concerned. Note that some registration validation issues concerning End User ENUM may not apply to infrastructure ENUM. Where the Tier 1 registry is able to identify the provider serving a number, e.g., based on industry data for number block assignments and number portability, registration might be more easily automated and a separate registrar not required.
ENUM的现有安全注意事项（详见[1]）仍然适用。由于基础设施ENUM涉及RFC 3761主要考虑个人的运营商，因此满足这些要求的实现应该重新考虑RFC 3761安全模型，因为相关参与者之间存在这种差异。请注意，与最终用户枚举有关的某些注册验证问题可能不适用于基础结构枚举。如果Tier 1注册中心能够识别提供号码服务的提供商，例如，基于号码区块分配和号码可移植性的行业数据，则注册可能更容易实现自动化，并且不需要单独的注册中心。
Some parties have expressed concern that an infrastructure ENUM could compromise end user privacy by making it possible for others to identify unlisted or unpublished numbers based on their registration in ENUM. This can be avoided if providers register all of the their allocated (as opposed to assigned) numbers. Unassigned numbers
一些缔约方表示担心，基础设施枚举可能会损害最终用户的隐私，使其他缔约方能够根据其在枚举中的注册来识别未列出或未公布的号码。若提供者注册了所有分配的（相对于分配的）号码，这是可以避免的。未分配数字
should be provisioned to route to the provider's network in the same fashion as assigned numbers and only then provide an indication that they are unassigned. In that way, provider registration of a number in ENUM provides no more information about the status of a number than could be obtained by dialing it.
应设置为以与分配的号码相同的方式路由到提供商的网络，然后才提供未分配号码的指示。这样，提供程序在ENUM中注册一个号码时，所提供的有关该号码状态的信息与拨打该号码所能获得的信息相比，并不多。
Implementers should take care to avoid inadvertent disclosure of user identities, for example, in the URIs returned in response to infrastructure ENUM queries.
实现者应该注意避免无意中泄露用户身份，例如，在响应基础结构枚举查询返回的URI中。
This document includes no actions to be taken by IANA. The architecture ultimately chosen to meet the requirements may require IANA actions.
本文件不包括IANA应采取的任何行动。最终选择满足需求的体系结构可能需要IANA行动。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[2] International Telecommunication Union-Telecommunication Standardization Sector, "The International Public Telecommunication Numbering Plan", Recommendation E.164", February 2005.
[2] 国际电信联盟电信标准化部门，“国际公共电信编号计划”，建议E.164，2005年2月。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.
[5] Newton，A.和M.Sanz，“IRIS：互联网注册信息服务（IRIS）核心协议”，RFC 3981，2005年1月。
[6] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", BCP 40, RFC 2870, June 2000.
[6] Bush，R.，Karrenberg，D.，Kosters，M.，和R.Plzak，“根名称服务器操作要求”，BCP 40，RFC 28702000年6月。
Authors' Addresses
作者地址
Steven Lind AT&T Labs 180 Park Ave Florham Park, NJ 07932-0971 USA
美国新泽西州弗洛勒姆公园公园大道180号Steven Lind AT&T实验室07932-0971
EMail: sdlind@att.com
EMail: sdlind@att.com
Penn Pfautz AT&T 200 S. Laurel Ave Middletown, NJ 07748 USA
美国新泽西州米德尔顿市劳雷尔大道南200号宾夕法尼亚州普法茨电话电报公司，邮编：07748
EMail: ppfautz@att.com
EMail: ppfautz@att.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.