Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8396 NeuStar, Inc.
Category: Informational T. McGarry
ISSN: 2070-1721 July 2018
Internet Engineering Task Force (IETF) J. Peterson
Request for Comments: 8396 NeuStar, Inc.
Category: Informational T. McGarry
ISSN: 2070-1721 July 2018
Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework
管理、订购、分发、公开和注册电话号码（现代）：问题陈述、用例和框架
Abstract
摘要
The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, including Telephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used by Internet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of the Internet environment and proposes a framework for Internet-based services relying on TNs.
公共交换电话网（PSTN）的功能正在迅速向互联网迁移。这对PSTN的许多传统元素产生了新的要求，包括电话号码（TNs）。TNs不再仅仅用作电话路由地址：它们现在是基于Internet的服务可用于各种目的的标识符，包括会话建立、身份验证和服务启用。本问题陈述探讨了用于分配和管理电话号码的现有工具如何与互联网环境的用例不一致，并提出了依赖TNs的基于互联网的服务框架。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8396.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8396.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Management Architectures . . . . . . . . . . . . . . 8
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12
4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13
4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Management of Administrative Data . . . . . . . . . . 14
4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14
4.2.1.2. Managing Data at a CSP . . . . . . . . . . . . . 15
4.2.2. Management of Service Data . . . . . . . . . . . . . 15
4.2.2.1. CSP to Other CSPs . . . . . . . . . . . . . . . . 16
4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16
4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16
4.2.3.1. Changing the CSP for an Existing Service . . . . 16
4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17
4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18
4.3.2. Retrieval of Semi-restricted Administrative Data . . 18
4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 19
4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Informative References . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Management Architectures . . . . . . . . . . . . . . 8
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12
4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13
4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Management of Administrative Data . . . . . . . . . . 14
4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14
4.2.1.2. Managing Data at a CSP . . . . . . . . . . . . . 15
4.2.2. Management of Service Data . . . . . . . . . . . . . 15
4.2.2.1. CSP to Other CSPs . . . . . . . . . . . . . . . . 16
4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16
4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16
4.2.3.1. Changing the CSP for an Existing Service . . . . 16
4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17
4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18
4.3.2. Retrieval of Semi-restricted Administrative Data . . 18
4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 19
4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Informative References . . . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The challenges of utilizing Telephone Numbers (TNs) on the Internet have been known for some time. Internet telephony provided the first use case for routing telephone numbers on the Internet in a manner similar to how calls are routed in the Public Switched Telephone Network (PSTN). As the Internet had no service for discovering the endpoints associated with telephone numbers, ENUM [RFC6116] created a DNS-based mechanism for translating TNs into URIs, as used by protocols such as SIP [RFC3261]. The resulting database was designed to function in a manner similar to the systems that route calls in the PSTN. Originally, it was envisioned that ENUM would be deployed as a global hierarchical service; however, in practice, it has only been deployed piecemeal by various parties. Most notably, ENUM is used as an internal network function and is rarely used between service provider networks. The original ENUM concept of a single root, e164.arpa, proved to be politically and practically challenging, and less centralized models have thus flourished. Subsequently, the Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) framework [RFC6461] showed ways that service providers might provision information about TNs at an ENUM service or similar Internet-based directory. These technologies have also generally tried to preserve the features and architecture familiar to the PSTN numbering environment.
在互联网上使用电话号码（TNs）的挑战早已为人所知。Internet telephony提供了第一个在Internet上路由电话号码的用例，其方式类似于在公共交换电话网（PSTN）中路由呼叫的方式。由于互联网没有发现与电话号码相关的端点的服务，ENUM[RFC6116]创建了一种基于DNS的机制，用于将TNs转换为URI，如SIP[RFC3261]等协议所使用的那样。由此产生的数据库设计为以类似于PSTN中路由呼叫的系统的方式运行。最初，设想将ENUM部署为一个全局分层服务；然而，在实践中，各方只是零碎地部署了它。最值得注意的是，ENUM用作内部网络功能，很少在服务提供商网络之间使用。最初的单根ENUM概念e164.arpa在政治上和实践上都具有挑战性，因此较不集中的模型也因此蓬勃发展。随后，网络间/网络内SIP（饮料）框架[RFC6461]的可达性数据显示了服务提供商可能在枚举服务或类似的基于互联网的目录中提供TNs信息的方式。这些技术通常还试图保留PSTN编号环境所熟悉的功能和体系结构。
Over time, Internet telephony has encompassed functions that differ substantially from traditional PSTN routing and management, especially as non-traditional providers have begun to utilize numbering resources. An increasing number of enterprises, over-the-top Voice over IP (VoIP) providers, text messaging services, and related non-carrier services have become heavy users of telephone numbers. An enterprise, for example, can deploy an IP Private Branch Exchange (PBX) that receives a block of telephone numbers from a carrier and then, in turn, distributes those numbers to new IP telephones when they associate with the PBX. Internet services offer users portals where they can allocate new telephone numbers on the fly, assign multiple "alias" telephone numbers to a single line service, implement various mobility or find-me-follow-me applications, and so on. Peer-to-peer telephone networks have encouraged experiments with distributed databases for telephone number routing and even allocation.
随着时间的推移，互联网电话已经包含了与传统PSTN路由和管理有很大不同的功能，特别是在非传统提供商开始利用编号资源的情况下。越来越多的企业、IP语音（VoIP）提供商、短信服务和相关的非运营商服务已经成为电话号码的大量用户。例如，企业可以部署一个IP专用交换机（PBX），该交换机从运营商接收一组电话号码，然后在新的IP电话与PBX关联时将这些号码分发给新的IP电话。互联网服务为用户提供了门户网站，用户可以在其中动态分配新的电话号码，为一条线路服务分配多个“别名”电话号码，实施各种移动或“查找我-跟我走”应用程序，等等。对等电话网络鼓励使用分布式数据库进行电话号码路由甚至分配的实验。
This dynamic control over telephone numbers has few precedents in the traditional PSTN outside of number portability. Number portability allows the capability of a user to choose and change their service provider while retaining their TN; it has been implemented in many countries either for all telephony services or for subsets (e.g., mobile). However, TN administration processes rooted in PSTN
这种对电话号码的动态控制在传统的PSTN中除了号码可携性之外几乎没有先例。号码可移植性允许用户选择和更改其服务提供商，同时保留其TN；它已在许多国家针对所有电话服务或子集（如移动电话）实施。然而，TN管理流程植根于PSTN
technology and policies made number porting fraught with problems and delays. Originally, processes were built to associate a specific TN to a specific service provider and never change it. With number portability, the industry had to build new infrastructure and new administrative functions and processes to change the association of the TN from one service provider to another. Thanks to the increasing sophistication of consumer mobile devices as Internet endpoints as well as telephones, users now associate TNs with many Internet applications other than telephony. This has generated new interest in models similar to those in place for administering freephone (non-geographic, toll-free numbers) services in the United States, where a user purchases a number through a sort of number registrar and controls its administration (such as routing) on their own, typically using Internet services to directly make changes to the service associated with telephone numbers.
技术和政策使得数字移植充满了问题和延迟。最初，构建流程是为了将特定的TN与特定的服务提供商相关联，并且从不更改它。由于电话号码的可移植性，该行业必须建立新的基础设施和新的管理职能和流程，以改变TN从一个服务提供商到另一个服务提供商的关联。由于消费者移动设备作为互联网终端和电话的日益成熟，用户现在将TNs与电话以外的许多互联网应用程序联系起来。这引起了人们对类似于美国管理免费电话（非地理、免费电话）服务的模式的新兴趣，用户通过一种号码注册器购买号码，并自行控制其管理（如路由），通常使用Internet服务直接更改与电话号码相关的服务。
Most TNs today are assigned to specific geographies, at both an international level and within national numbering plans. Numbering practices today are tightly coupled with the manner that service providers interconnect as well as with how TNs are routed and administered: the PSTN was carefully designed to delegate switching intelligence geographically. In interexchange carrier routing in North America, for example, calls to a particular TN are often handed off to the terminating service provider close to the geography where that TN is assigned. But the overwhelming success of mobile telephones has increasingly eroded the connection between numbers and regions. Furthermore, the topology of IP networks is not anchored to geography in the same way that the telephone network is. In an Internet environment, establishing a network architecture for routing TNs could depend little on geography, relying instead on network topologies or other architectural features. Adapting TNs to the Internet requires more security, richer datasets, and more complex query and response capabilities than previous efforts have provided.
目前，大多数TN在国际层面和国家编号计划中都被分配到特定的地理位置。当今的编号实践与服务提供商的互连方式以及TNs的路由和管理方式紧密结合：PSTN经过精心设计，可在地理上分配交换智能。例如，在北美的交换间载波路由中，对特定TN的呼叫通常被转移到靠近该TN被分配的地理位置的终端服务提供商。但移动电话的巨大成功日益削弱了数字和地区之间的联系。此外，IP网络的拓扑结构并不像电话网络那样固定在地理位置上。在Internet环境中，建立用于路由TNs的网络体系结构几乎不依赖于地理位置，而是依赖于网络拓扑或其他体系结构特征。使TNs适应互联网需要比以前的努力提供更多的安全性、更丰富的数据集和更复杂的查询和响应能力。
This document attempts to create a common understanding of the problem statement related to allocating, managing, and resolving TNs in an IP environment, which is the focus of the IETF Managing, Ordering, Distributing, Exposing, and Registering telephone Numbers (MODERN) Working Group. It outlines a framework and lists motivating use cases for creating IP-based mechanisms for TNs. It is important to acknowledge at the outset that there are various evolving international and national policies and processes related to TNs, and any solutions need to be flexible enough to account for variations in policy and requirements.
本文件试图对与IP环境中TNs的分配、管理和解决相关的问题陈述达成共识，这是IETF管理、订购、分发、公开和注册电话号码（现代）工作组的重点。它概述了一个框架，并列出了为TNs创建基于IP的机制的激励用例。一开始就必须承认，与跨国公司有关的各种国际和国家政策和进程正在演变，任何解决办法都需要足够灵活，以考虑到政策和要求的变化。
This section provides definitions for actors, data types, and data management architectures as they are discussed in this document. Different numbering spaces may instantiate these roles and concepts differently: practices that apply to non-geographic freephone numbers, for example, may not apply to geographic numbers, and practices that exist under one Numbering Authority may not be permitted under another. The purpose of this framework is to identify the characteristics of protocol tools that will satisfy the diverse requirements for telephone number acquisition, management, and retrieval on the Internet.
本节提供了本文档中讨论的参与者、数据类型和数据管理体系结构的定义。不同的编号空间可能会以不同的方式实例化这些角色和概念：例如，适用于非地理自由电话号码的做法可能不适用于地理号码，并且在一个编号机构下存在的做法可能不被另一个编号机构所允许。该框架的目的是确定协议工具的特征，以满足互联网上电话号码获取、管理和检索的各种需求。
The following roles of actors are defined in this document.
本文件中定义了以下参与者角色。
Numbering Authority: A regulatory body within a region that manages that region's TNs. The Numbering Authority decides national numbering policy for the nation, region, or other domain for which it has authority, including what TNs can be allocated, which are reserved, and which entities may obtain TNs.
编号机构：区域内管理该区域TNs的监管机构。编号机构决定其拥有权限的国家、地区或其他领域的国家编号政策，包括可以分配哪些TNs、保留哪些TNs以及哪些实体可以获得TNs。
Registry: An entity that administers the allocation of TNs based on a Numbering Authority's policies. Numbering Authorities can act as the Registries themselves, or they can outsource the function to other entities. Traditional registries are single entities with sole authority and responsibility for specific numbering resources, though distributed registries (see Section 2.3) are also in the scope of this framework.
注册表：根据编号机构的策略管理TNs分配的实体。编号机构本身可以充当登记处，也可以将职能外包给其他实体。传统的注册中心是单一实体，对特定的编号资源具有唯一的权限和责任，尽管分布式注册中心（见第2.3节）也在本框架的范围内。
Credential Authority: An entity that distributes credentials, such as certificates that attest the authority of assignees (defined below) and delegates. This document assumes that one or more Credential Authorities may be trusted by actors in any given regulatory environment; policies for establishing such trust anchors are outside the scope of this document.
凭证颁发机构：分发凭证的实体，如证明受让人（定义见下文）和委托人权限的证书。本文件假设在任何给定的监管环境中，参与者可能信任一个或多个认证机构；建立此类信任锚的政策不在本文件的范围内。
Registrar: An entity that distributes the telephone numbers administered by a Registry; typically, there are many Registrars that can distribute numbers from a single Registry, though Registrars may serve multiple Registries as well. A Registrar has business relationships with number assignees and collects administrative information from them.
登记员：分配由登记处管理的电话号码的实体；通常，有许多注册商可以从单个注册中心分发号码，尽管注册商也可以为多个注册中心提供服务。登记员与号码受让人有业务关系，并从他们那里收集行政信息。
Communication Service Provider (CSP): A provider of communication service where those services can be identified by TNs. This includes both traditional telephone carriers or enterprises as
通信服务提供商（CSP）：可由TNs识别的通信服务提供商。这既包括传统电话运营商，也包括企业
well as service providers with no presence on the PSTN who use TNs. This framework does not assume that any single CSP provides all the communication service related to a particular TN.
以及在PSTN上没有使用TNs的服务提供商。该框架不假设任何单个CSP提供与特定TN相关的所有通信服务。
Service Enabler: An entity that works with CSPs to enable communication service to a User: perhaps a vendor, a service bureau, or a third-party integrator.
服务启用程序：与CSP合作以向用户（可能是供应商、服务局或第三方集成商）启用通信服务的实体。
User: An individual reachable through a communication service: usually a customer of a Communication Service Provider.
用户：可通过通信服务联系到的个人：通常是通信服务提供商的客户。
Government Entity: An entity that, due to legal powers deriving from national policy, has privileged access to information about number administration under certain conditions.
政府实体：由于国家政策所赋予的法定权力，在特定条件下有权获得有关号码管理信息的实体。
Note that an individual, organization, or other entity may act in one or more of the roles above; for example, a company may be a CSP and also a Registrar. Although Numbering Authorities are listed as actors, they are unlikely to actually participate in the protocol flows themselves; however, in some situations, a Numbering Authority and Registry may be the same administrative entity.
请注意，个人、组织或其他实体可担任上述一个或多个角色；例如，公司可以是CSP，也可以是注册商。尽管编号机构被列为参与者，但它们本身不太可能实际参与协议流；然而，在某些情况下，编号机构和登记处可能是同一行政实体。
All actors that are recipients of numbering resources, be they a CSP, Service Enabler, or User, can also be said to have a relationship to a Registry of either an assignee or delegate.
所有作为编号资源接收者的参与者，无论是CSP、服务启用者还是用户，也可以说与受让人或委托人的注册表有关系。
Assignee: An actor that is assigned a TN directly by a Registrar; an assignee always has a direct relationship with a Registrar.
受让人：由登记员直接转让TN的行为人；受让人始终与登记员有直接关系。
Delegate: An actor that is delegated a TN from an assignee or another delegate who does not necessarily have a direct relationship with a Registrar. Delegates may delegate one or more of their TN assignment(s) to one or more subdelegates from further downstream.
委托人：从受让人或不一定与注册人有直接关系的其他委托人处获得TN授权的参与者。代表可以将一个或多个TN分配委派给下游的一个或多个子代表。
As an example, consider a case where a Numbering Authority also acts as a Registry, and it issues blocks of 10,000 TNs to CSPs that, in this case, also act as Registrars. CSP/Registrars would then be responsible for distributing numbering resources to Users and other CSPs. In this case, an enterprise deploying IP PBXs also acts as a CSP, and it acquires number blocks for its enterprise seats in chunks of 100 from a CSP acting as a Registrar with whom the enterprise has a business relationship. The enterprise is, in this case, the assignee, as it receives numbering resources directly from a Registrar. As it doles out individual numbers to its Users, the enterprise delegates its own numbering resources to those Users and their communication endpoints. The overall ecosystem might look as follows.
作为一个例子，考虑一个编号机构也充当注册表的情况，它将10000个TNS块发给CSP，在这种情况下，也充当注册。CSP/注册员将负责向用户和其他CSP分配编号资源。在这种情况下，部署IP PBX的企业还充当CSP，并且它从CSP（充当与该企业有业务关系的注册者）处获得100个数量块的企业席位。在这种情况下，企业是受让人，因为它直接从登记处接收编号资源。在向用户分发单个编号时，企业将自己的编号资源委托给这些用户及其通信端点。整个生态系统可能如下所示。
+---------+
|Numbering|
|Authority|Registry
+----+----+
|
V 10,000 TNs
+---------+
| CSP |Registrar
+----+----+
|
V 100 TNs
+---------+
| PBX |Assignee
+---------+
|
V 1 TN
+---------+
| User |Delegate
+---------+
+---------+
|Numbering|
|Authority|Registry
+----+----+
|
V 10,000 TNs
+---------+
| CSP |Registrar
+----+----+
|
V 100 TNs
+---------+
| PBX |Assignee
+---------+
|
V 1 TN
+---------+
| User |Delegate
+---------+
Figure 1: Chain of Number Assignment
图1：编号分配链
The following data types are defined in this document.
本文档中定义了以下数据类型。
Administrative Data: Assignment data related to the TN and the relevant actors; it includes TN status (assigned, unassigned, etc.), contact data for the assignee or delegate, and typically does not require real-time access as this data is not required for ordinary call or session establishment.
管理数据：与TN和相关参与者相关的任务数据；它包括TN状态（已分配、未分配等）、受让人或代表的联系数据，通常不需要实时访问，因为普通呼叫或会话建立不需要这些数据。
Service Data: Data necessary to enable service for the TN; it includes addressing data and service features. Since this data is necessary to complete calls, it must be obtained in real time.
服务数据：启用TN服务所需的数据；它包括寻址数据和服务功能。由于此数据是完成调用所必需的，因此必须实时获取。
Administrative and service data can fit into three access categories:
管理和服务数据可分为三种访问类别：
Public: Anyone can access public data. Such data might include a list of which numbering resources (unallocated number ranges) are available for acquisition from the Registry.
公共：任何人都可以访问公共数据。此类数据可能包括可从注册表获取的编号资源（未分配的编号范围）列表。
Semi-restricted: Only a subset of actors can access semi-restricted data. For example, CSPs may be able to access other CSP's service data in some closed environment.
半限制：只有一部分参与者可以访问半限制数据。例如，CSP可以在某些封闭环境中访问其他CSP的服务数据。
Restricted: Only a small subset of actors can access restricted data. For example, a Government Entity may be able access contact information for a User.
受限：只有一小部分参与者可以访问受限数据。例如，政府实体可以访问用户的联系信息。
While it might appear there are really only two categories, public and restricted (based on the requestor), the distinction between semi-restricted and restricted is helpful for the use cases below.
虽然看起来实际上只有两个类别，public和restricted（基于请求者），但半受限和受限之间的区别对于下面的用例很有帮助。
This framework generally assumes that administrative and service data is maintained by CSPs, Registrars, and Registries. The terms "registrar" and "registry" are familiar from DNS operations, and indeed the DNS provides an obvious inspiration for the relationships between those entities described here. Protocols for transferring names between registries and registrars have been standardized in the DNS space for some time (see [RFC3375]). Similarly, the division between service data acquired by resolving names with the DNS protocol versus administrative data about names acquired through WHOIS [RFC3912] is directly analogous to the distinction between service and administrative data described in Section 2.2. The major difference between the data management architecture of the DNS and this framework is that the distinction between the CSP and User, due to historical policies of the telephone network, will often not exactly correspond to the distinction between a name service and a registrant in the DNS world -- a User in the telephone network is today at least rarely in a direct relationship with a Registrar comparable to that of a DNS registrant.
该框架通常假设管理和服务数据由CSP、注册商和注册中心维护。术语“注册器”和“注册中心”在DNS操作中很常见，事实上，DNS为这里描述的这些实体之间的关系提供了明显的启示。注册中心和注册中心之间的名称传输协议已经在DNS领域标准化了一段时间（参见[RFC3375]）。类似地，通过DNS协议解析名称获得的服务数据与通过WHOIS[RFC3912]获得的关于名称的管理数据之间的区分与第2.2节中描述的服务和管理数据之间的区别直接类似。DNS的数据管理体系结构与此框架之间的主要区别在于，由于电话网络的历史政策，CSP和用户之间的区别，通常与DNS世界中的名称服务和注册人之间的区别并不完全对应——如今，电话网络中的用户与注册人之间的直接关系至少很少与DNS注册人的直接关系相当。
The role of a Registry described here is a "thin" one, where the Registry manages basic allocation information for the numbering space, such as information about whether or not the number is assigned, and if assigned, by which Registrar. It is the Registrar that, in turn, manages detailed administrative data about those assignments, such as contact or billing information for the assignee. In some models, CSPs and Registrars will be combined (the same administrative entity), and in others the Registry and Registrar may similarly be composed. Typically, service data resides largely at the CSP itself, though in some models a "thicker" Registry may itself contain a pointer to the servicing CSP for a number or number block. In addition to traditional centralized Registries, this framework also supports environments where the same data is being managed by multiple administrative entities and stored in many locations. A
这里描述的注册中心的角色是“精简”的，其中注册中心管理编号空间的基本分配信息，例如关于是否分配了编号以及如果分配了编号，由哪个注册中心分配的信息。反过来，登记员负责管理有关这些任务的详细管理数据，例如受让人的联系信息或账单信息。在某些模式中，客户服务提供商和登记员将合并（同一行政实体），而在其他模式中，登记员和登记员的组成可能类似。通常，服务数据主要驻留在CSP本身，尽管在某些模型中，“较厚”的注册表本身可能包含一个指向服务CSP的数字或数字块的指针。除了传统的集中式注册中心之外，该框架还支持由多个管理实体管理相同数据并存储在多个位置的环境。A.
distributed registry system is discussed further in [DRIP]. To support those use cases, it is important to distinguish the following:
分布式注册表系统将在[DRIP]中进一步讨论。为了支持这些用例，区分以下内容很重要：
Data Store: A data store is a service that stores and enables access to administrative and/or service data.
数据存储：数据存储是一种存储并允许访问管理和/或服务数据的服务。
Reference Address: A reference address is a URL that dereferences to the location of the data store.
引用地址：引用地址是一个URL，它取消对数据存储位置的引用。
Distributed Data Stores: In a distributed data store, administrative or service data can be stored with multiple actors. For example, CSPs could provision their service data to multiple other CSPs.
分布式数据存储：在分布式数据存储中，管理或服务数据可以由多个参与者存储。例如，CSP可以将其服务数据提供给多个其他CSP。
Distributed Registries: Multiple Registries can manage the same numbering resource. In these architectures, actors could interact with one or multiple Registries. The Registries would update each other when change occurs. The Registries have to ensure that data remains consistent, e.g., that the same TN is not assigned to two different actors.
分布式注册表：多个注册表可以管理相同的编号资源。在这些体系结构中，参与者可以与一个或多个注册表交互。当发生变化时，注册中心将相互更新。登记处必须确保数据保持一致，例如，相同的TN不会分配给两个不同的参与者。
The framework outlined in this document requires three Internet-based mechanisms for managing and resolving TNs in an IP environment. These mechanisms will likely reuse existing protocols for sharing structured data; it is unlikely that new protocol development work will be required, though new information models specific to the data itself will be a major focus of framework development. Likely candidates for reuse here include work done in DRINKS [RFC6461] and Web Extensible Internet Registration Data Service (WEIRDS) [RFC7482], as well as the Telephone-Related Information (TeRI) framework [TERI-INFO].
本文件中概述的框架需要三种基于互联网的机制来管理和解决IP环境中的TNs。这些机制可能会重用现有协议来共享结构化数据；虽然特定于数据本身的新信息模型将是框架开发的主要焦点，但不太可能需要新的协议开发工作。这里可能的重用对象包括在饮料[RFC6461]和Web可扩展互联网注册数据服务（WEIRDS）[RFC7482]中完成的工作，以及电话相关信息（TeRI）框架[TeRI-INFO]。
These protocol mechanisms are scoped in a way that makes them likely to apply to a broad range of future policies for number administration. It is not the purpose of this framework to dictate number policy but instead to provide tools that will work with policies as they evolve going forward. These mechanisms, therefore, do not assume that number administration is centralized nor that number allocations are restricted to any category of service providers, though these tools must and will work in environments with those properties.
这些协议机制的范围使得它们有可能应用于未来广泛的数字管理策略。本框架的目的不是规定数字政策，而是提供工具，随着政策的发展，这些工具将与政策一起工作。因此，这些机制并不假定号码管理是集中的，也不假定号码分配仅限于任何类别的服务提供商，尽管这些工具必须并且将在具有这些属性的环境中工作。
The three mechanisms are:
这三个机制是：
Acquisition: A protocol mechanism for acquiring TNs, including an enrollment process.
获取：用于获取TNs的协议机制，包括注册过程。
Management: A protocol mechanism for associating data with TNs.
管理：将数据与TNs关联的协议机制。
Retrieval: A protocol mechanism for retrieving data about TNs.
检索：用于检索TNs数据的协议机制。
The acquisition mechanism will enable actors to acquire TNs for use with a communication service by requesting numbering resources from a service operated by a Registrar, CSP, or similar actor. TNs may be requested either on a number-by-number basis or as inventory blocks. Any actor who grants numbering resources will retain metadata about the assignment, including the responsible organization or individual to whom numbers have been assigned.
获取机制将使参与者能够通过从注册商、CSP或类似参与者操作的服务请求编号资源来获取TNs以用于通信服务。TNs可以逐个编号申请，也可以作为库存块申请。任何授予编号资源的参与者都将保留有关分配的元数据，包括分配编号的责任组织或个人。
The management mechanism will let actors provision data associated with TNs. For example, if a User has been assigned a TN, they may select a CSP to provide a particular service associated with the TN, or a CSP may assign a TN to a User upon service activation. In either case, a mechanism is needed to provision data associated with the TN at that CSP and to extend those data sets as CSPs (and even Users) require.
管理机制将允许行为者提供与TNs相关的数据。例如，如果用户被分配了TN，则他们可以选择CSP来提供与TN相关联的特定服务，或者CSP可以在服务激活时将TN分配给用户。在这两种情况下，都需要一种机制来在该CSP提供和TN相关联的数据，并根据CSP（甚至用户）的需要扩展这些数据集。
The retrieval mechanism will enable actors to learn information about TNs. For real-time service data, this typically involves sending a request to a CSP; for other information, an actor may need to send a request to a Registry rather than a CSP. Different parties may be authorized to receive different information about TNs.
检索机制将使参与者能够了解有关TNs的信息。对于实时服务数据，这通常涉及向CSP发送请求；对于其他信息，参与者可能需要向注册表而不是CSP发送请求。可以授权不同的当事方接收关于TNs的不同信息。
As an example, a CSP might use the acquisition interface to acquire a chunk of numbers from a Registrar. Users might then provision administrative data associated with those numbers at the CSP through the management interface and query for service data relating to those numbers through the retrieval interface of the CSP.
例如，CSP可以使用采集接口从注册器获取一组数字。然后，用户可以通过管理界面在CSP提供与这些号码相关的管理数据，并通过CSP的检索界面查询与这些号码相关的服务数据。
+--------+
|Registry|
+---+----+
|
V
+---------+
|Registrar|
+---------+
\
\\
Acquisition \\
\\+-------+
\ CSP |
+---+---+
A A
| |
Management | | Retrieval
| |
| |
+-------++ ++-------+
| User | | User |
+--------+ +--------+
(Delegate) (Caller)
+--------+
|Registry|
+---+----+
|
V
+---------+
|Registrar|
+---------+
\
\\
Acquisition \\
\\+-------+
\ CSP |
+---+---+
A A
| |
Management | | Retrieval
| |
| |
+-------++ ++-------+
| User | | User |
+--------+ +--------+
(Delegate) (Caller)
Figure 2: Example of the Three Interfaces
图2：三个接口的示例
The high-level use cases in this section will provide an overview of the expected operation of the three interfaces in the MODERN problem space.
本节中的高级用例将概述现代问题空间中三个接口的预期操作。
There are various scenarios for how TNs can be acquired by the relevant actors, that is, a CSP, Service Enabler, and a User. There are three actors from which numbers can be acquired: a Registrar, a CSP, and a User (presumably one who is delegating to another party). It is assumed either that Registrars are the same entity as Registries or that Registrars have established business relationships with Registries that enable them to distribute the numbers that the Registries administer. In these use cases, a User may acquire TNs either from a CSP, a Registry, or an intermediate delegate.
对于相关参与者（即CSP、服务启用程序和用户）如何获取TNs，存在各种场景。有三个参与者可以从中获取号码：注册员、CSP和用户（可能是授权给另一方的用户）。假定登记人与登记处是同一实体，或者登记人与登记处建立了业务关系，使其能够分发登记处管理的号码。在这些用例中，用户可以从CSP、注册表或中间委托获取TNs。
The most traditional number acquisition use case is one where a CSP, such as a carrier, requests a block of numbers from a Registrar to hold as inventory or assign to customers.
最传统的号码获取用例是CSP（如运营商）向注册商请求一组号码作为库存或分配给客户。
Through some out-of-band business process, a CSP develops a relationship with a Registrar. The Registrar maintains a profile of the CSP and assesses whether or not CSPs meet the policy restrictions for acquiring TNs. The CSP may then request TNs from within a specific pool of numbers in the authority of the Registry, such as region, mobile, wireline, or freephone. The Registrar must authenticate and authorize the CSP and then either grant or deny a request. When an assignment occurs, the Registry creates and stores administrative information related to the assignment, such as TN status and Registrar contact information, and removes the specific TN(s) from the pool of those that are available for assignment. As a part of the acquisition and assignment process, the Registry provides to the Registrar any tokens or other material needed by a Credential Authority to issue credentials (for example, Secure Telephone Identity Revisited (STIR) certificates [RFC8226]) used to attest the assignment for future transactions. Depending on the policies of the Numbering Authorities, Registrars may be required to log these operations.
通过一些带外业务流程，CSP与注册商建立了关系。注册官维护客户服务提供商的档案，并评估客户服务提供商是否符合获取TNs的政策限制。然后，CSP可以从注册中心授权的特定号码池中请求TNs，例如地区、移动电话、有线电话或免费电话。注册官必须验证和授权CSP，然后批准或拒绝请求。当分配发生时，注册表创建并存储与分配相关的管理信息，如TN状态和注册人联系信息，并从可用于分配的管理信息池中删除特定TN。作为收购和转让过程的一部分，注册处向注册处提供凭证颁发机构签发凭证所需的任何代币或其他材料（例如，安全电话身份重访（STIR）证书[RFC8226]），用于证明未来交易的转让。根据编号机构的政策，可能需要登记员记录这些操作。
Before it is eligible to receive TN assignments, per the policy of a Numbering Authority, the CSP may need to have submitted (again, through some out-of-band process) additional qualifying information such as the current utilization rate or a demand forecast.
在有资格接收TN分配之前，根据编号机构的政策，CSP可能需要提交（同样，通过一些带外流程）其他合格信息，如当前利用率或需求预测。
There are two scenarios under which a CSP requests resources: either they are requesting inventory or they are requesting for a specific User or delegate. For the purpose of status information, TNs assigned to a User are always considered assigned, not inventory. The CSP will associate service information for that TN (e.g., a service address) and make it available to other CSPs to enable interconnection. The CSP may need to update the Registrar regarding this service activation; this is part of the "TN status" maintained by the Registrar.
CSP请求资源的情况有两种：一种是请求库存，另一种是请求特定用户或委托。出于状态信息的目的，分配给用户的TNs始终被视为已分配，而不是库存。CSP将关联该TN的服务信息（例如，服务地址），并将其提供给其他CSP以实现互连。CSP可能需要更新注册器关于此服务激活的信息；这是注册官维护的“TN状态”的一部分。
There are also use cases in which a User can acquire a TN directly from a Registrar. Today, a User wishing to acquire a freephone number may browse the existing inventory through one or more Registrars, comparing their prices and services. Each such Registrar either is a CSP or has a business relationship with one or more CSPs to provide services for that freephone number. In this case, the User must establish some business relationship directly with a Registrar, similar to how such functions are conducted today when
还有一些用例，其中用户可以直接从注册器获取TN。如今，希望获得免费电话号码的用户可以通过一个或多个注册商浏览现有库存，比较其价格和服务。每个这样的注册者要么是一个CSP，要么与一个或多个CSP有业务关系，为该免费电话号码提供服务。在这种情况下，用户必须直接与注册商建立某种业务关系，类似于今天在
Users purchase domain names. In this use case, after receiving a number assignment from the Registrar, a User will obtain communication service from a CSP and provide to the CSP the TN to be used for that service. The CSP will associate service information for that TN (e.g., the service address) and make it available to other CSPs to enable interconnection. The User will also need to inform the Registrar about this relationship.
用户购买域名。在该用例中，在接收到来自注册器的号码分配之后，用户将从CSP获得通信服务，并向CSP提供用于该服务的TN。CSP将关联该TN的服务信息（例如，服务地址），并将其提供给其他CSP以实现互连。用户还需要将此关系通知注册官。
Today, a User typically acquires a TN from a CSP when signing up for a communication service or turning on a new device. In this use case, the User becomes the delegate of the CSP. A reseller or a service bureau might also acquire a block of numbers from a CSP to be issued to Users.
如今，用户通常在注册通信服务或打开新设备时从CSP获取TN。在这个用例中，用户成为CSP的代表。转售商或服务局也可能从CSP获得一组号码，以发给用户。
Consider a case where a User creates or has a relationship with the CSP and subscribes to a communication service that includes the use of a TN. The CSP collects and stores administrative data about the User. The CSP then activates the User on their network and creates any necessary service data to enable connectivity with other CSPs. The CSP could also update public or privileged databases accessible by other actors. The CSP provides any tokens or other material needed by a Credential Authority to issue credentials to the User (for example, a STIR certificate [RFC8226]) to prove the assignment for future transactions. Such credentials could be delegated from the one provided by the Credential Authority to the CSP to continue the chain of assignment. CSPs may be required to log such transactions if required by the policy of the Numbering Authority.
考虑用户创建或与CSP建立关系并订阅包含TN的通信服务的情况。CSP收集并存储关于用户的管理数据。然后，CSP激活其网络上的用户，并创建任何必要的服务数据，以实现与其他CSP的连接。CSP还可以更新其他参与者可以访问的公共或特权数据库。CSP提供凭证颁发机构向用户颁发凭证所需的任何令牌或其他材料（例如，STIR证书[RFC8226]），以证明未来交易的分配。此类凭证可以从凭证授权机构提供的凭证委托给CSP，以继续分配链。如果编号机构的政策要求，CSP可能需要记录此类交易。
Virtually, the same flow would work for a reseller: it would form a business relationship with the CSP, at which point the CSP would collect and store administrative data about the reseller and give the reseller any material needed for the reseller to acquire credentials for the numbers. A User might then, in turn, acquire numbers from the reseller: in this case, the delegate redelegating the TNs would be performing functions done by the CSP (e.g., providing any credentials or collecting administrative data or creative service data).
实际上，同样的流程也适用于经销商：它将与CSP形成业务关系，CSP将在这一点上收集和存储有关经销商的管理数据，并向经销商提供经销商获取号码凭据所需的任何材料。然后，用户可以从经销商处获得号码：在这种情况下，重新委派TNs的代表将执行CSP完成的功能（例如，提供任何凭证或收集管理数据或创意服务数据）。
The CSP could assign a TN from its existing inventory or it could acquire a new TN from the Registrar as part of the assignment process. If it assigns it from its existing inventory, it would remove the specific TN from the pool of those available for assignment. It may also update the Registrar about the assignment so the Registrar has current assignment data. If a reseller or delegate
CSP可以从其现有库存中分配TN，也可以从注册处获取新TN，作为分配过程的一部分。如果它从现有库存中分配，它将从可分配的库存中删除特定的TN。它还可以向注册官更新有关转让的信息，以便注册官拥有当前转让数据。如果经销商或代表
CSP is acquiring the numbers, it may have the same obligations to provide utilization data to the Registry as the assignee, per Section 4.1.1.
CSP在获取这些号码时，根据第4.1.1节，其可能与受让人有相同的义务向登记处提供利用率数据。
The management protocol mechanism is needed to associate administrative and service data with TNs and may be used to refresh or rollover associated credentials.
管理协议机制需要将管理和服务数据与TNs关联，并可用于刷新或滚动关联的凭据。
Administrative data is primarily related to the status of the TN, its administrative contacts, and the actors involved in providing service to the TN. Protocol interactions for administrative data will therefore predominantly occur between CSPs and Users to the Registrar or between Users and delegate CSPs to the CSP.
管理数据主要与TN的状态、其管理联系人以及向TN提供服务所涉及的参与者有关。因此，管理数据的协议交互主要发生在CSP和注册用户之间或用户和委托CSP之间。
Some administrative data may be private and would thus require special handling in a distributed data store model. Access to it does not require real-time performance; therefore, local caches are not necessary, and the data will include sensitive information such as User and contact data.
一些管理数据可能是私有的，因此需要在分布式数据存储模型中进行特殊处理。访问它不需要实时性能；因此，不需要本地缓存，数据将包括敏感信息，如用户和联系人数据。
Some of the data could lend itself to being publicly available, such as CSP and TN assignment status. In that case, it would be deemed public information for the purposes of the retrieval interface.
一些数据可能会公开，例如CSP和TN分配状态。在这种情况下，就检索界面而言，它将被视为公共信息。
After a CSP acquires a TN or block of TNs from the Registrar (per Section 4.1.1), it then provides administrative data to the Registrar as a step in the acquisition process. The Registrar will authenticate the CSP and determine if the CSP is authorized to provision the administrative data for the TNs in question. The Registry will update the status of the TN, i.e., that it is unavailable for assignment. The Registrar will also maintain administrative data provided by the CSP.
CSP从登记员处获取TN或TN块后（根据第4.1.1节），然后向登记员提供管理数据，作为获取过程中的一个步骤。注册官将认证客户服务提供商，并确定客户服务提供商是否有权为相关TNs提供管理数据。注册表将更新TN的状态，即它不可分配。注册官还将保存CSP提供的行政数据。
Changes to this administrative data will not be frequent. Examples of changes would be terminating service (see Section 4.2.3.2), changing the name or address of a User or organization, or changing a CSP or delegate. Changes should be authenticated by a credential to prove administrative responsibility for the TN.
不会频繁更改此管理数据。变更的示例包括终止服务（见第4.2.3.2节）、更改用户或组织的名称或地址，或更改CSP或代表。变更应通过凭证进行认证，以证明TN的管理责任。
In some cases, such as the freephone system in North America today, the User has a direct relationship with the Registrar. Naturally, these Users could provision administrative data associated with their TNs directly to the Registrar just as a freephone provider today maintains account and billing data. While delegates may not ordinarily have a direct relationship to a Registrar, some environments (as an optimization) might want to support a model where the delegate updates the Registrar directly on changes, as opposed to sending that data to the CSP or through the CSP to the Registrar. As stated already, the protocol should enable Users to acquire TNs directly from a Registrar, which may or may not also act as a CSP. In these cases, the updates would be similar to those described in Section 4.2.1.1.
在某些情况下，例如今天北美的免费电话系统，用户与注册官有直接关系。当然，这些用户可以直接向注册官提供与其TNs相关的管理数据，就像今天的免费电话提供商维护帐户和账单数据一样。虽然委托人通常可能与注册人没有直接关系，但某些环境（作为优化）可能希望支持委托人直接在变更时更新注册人的模型，而不是将数据发送给CSP或通过CSP发送给注册人。如前所述，该协议应允许用户直接从注册商处获取TNs，注册商可能也可能充当CSP，也可能不充当CSP。在这些情况下，更新将类似于第4.2.1.1节中所述的更新。
In a distributed Registry model, TN status (e.g., allocated, assigned, available, or unavailable) would need to be provided to other Registries in real time. Other administrative data could be sent to all Registries, or other Registries could get a reference address to the host Registry's data store.
在分布式注册表模型中，TN状态（例如，已分配、已分配、可用或不可用）需要实时提供给其他注册表。其他管理数据可以发送到所有注册中心，或者其他注册中心可以获得主机注册中心数据存储的引用地址。
After a User acquires a TN or block of TNs from a CSP, the User will provide administrative data to the CSP. The CSP commonly acts as a Registrar in this case by maintaining the administrative data and only notifying the Registry of the change in TN status. In this case, the Registry maintains a reference address (see Section 2.3) to the CSP/Registrar's administrative data store so relevant actors have the ability to access the data. Alternatively, a CSP could send the administrative data to an external Registrar to store. If there is a delegate between the CSP and User, they will have to ensure there is a mechanism for the delegate to update the CSP as change occurs.
用户从CSP获取TN或TN块后，用户将向CSP提供管理数据。在这种情况下，顾客服务提供商通常充当登记员，维护管理数据，仅通知登记处TN状态的变化。在这种情况下，注册中心维护CSP/注册中心管理数据存储的参考地址（见第2.3节），以便相关参与者能够访问数据。或者，CSP可以将管理数据发送到外部注册器进行存储。如果CSP和用户之间有一个委托，他们必须确保有一种机制让该委托在发生更改时更新CSP。
Service data is data required by an originating or intermediate CSP to enable communication service to a User; a SIP URI is an example of one service data element commonly used to route communication. CSPs typically create and manage service data, however, it is possible that delegates and Users could as well. For most use cases involving individual Users, it is anticipated that lower-level service information changes (such as an end-user device receiving a new IP address) would be communicated to CSPs via existing protocols. For example, the baseline SIP REGISTER [RFC3261] method, even for bulk operations [RFC6140], would likely be used rather than through any new interfaces defined by MODERN.
服务数据是发起或中间CSP所需的数据，以便能够向用户提供通信服务；SIP URI是通常用于路由通信的一个服务数据元素的示例。CSP通常创建和管理服务数据，但是，代理和用户也可以这样做。对于涉及单个用户的大多数用例，预计较低级别的服务信息更改（例如接收新IP地址的最终用户设备）将通过现有协议传送给CSP。例如，基线SIP寄存器[RFC3261]方法，即使对于批量操作[RFC6140]，也可能会被使用，而不是通过MODERN定义的任何新接口。
After a User enrolls for service with a CSP, in the case where the CSP was assigned the TN by a Registrar, the CSP will then create a service address such as a SIP URI and associate it with the TN. The CSP needs to update this data to enable service interoperability. There are multiple ways that this update can occur, though most commonly service data is exposed through the retrieval interface (see Section 4.3). For certain deployment architectures, like a distributed data store model, CSPs may need to provision data directly to other CSPs.
用户向CSP注册服务后，如果CSP被注册商分配了TN，CSP将创建一个服务地址，如SIP URI，并将其与TN关联。CSP需要更新此数据以实现服务互操作性。虽然最常见的服务数据是通过检索接口公开的（请参见第4.3节），但可以通过多种方式进行此更新。对于某些部署体系结构，如分布式数据存储模型，CSP可能需要直接向其他CSP提供数据。
If the CSP is assigning a TN from its own inventory, it may not need to perform service data updates as change occurs because the existing service data associated with inventory may be sufficient once the TN is put in service. They would, however, likely update the Registry on the change in status.
如果顾客服务提供商从其自己的库存中分配TN，则在发生变化时可能不需要执行服务数据更新，因为一旦TN投入使用，与库存相关的现有服务数据可能就足够了。但是，他们可能会根据状态的变化更新注册表。
Users could also associate service data to their TNs at the CSP. An example would be a User acquiring a TN from the Registrar (as described in Section 4.1.1) and wanting to provide that TN to the CSP so the CSP can enable service. In this case, once the User provides the number to the CSP, the CSP would update the Registry or other actors as outlined in Section 4.2.2.1.
用户还可以将服务数据关联到CSP上的TNs。例如，用户从注册商处获取TN（如第4.1.1节所述），并希望向CSP提供该TN，以便CSP能够启用服务。在这种情况下，一旦用户向CSP提供了号码，CSP将按照第4.2.2.1节所述更新注册表或其他参与者。
This section will address some special management use cases that were not covered above.
本节将讨论一些上面未涉及的特殊管理用例。
Consider the case where a User who subscribes to a communication service (and who received their TN from that CSP) wishes to retain the same TN but move their service to a different CSP.
考虑订阅通信服务的用户（以及从该CSP接收到TN）的用户希望保留相同的TN，但将他们的服务移动到不同的CSP。
In the simplest scenario, where there's an authoritative combined Registry/Registrar that maintains service data, the User could provide their credential to the new CSP and let the CSP initiate the change in service. The new CSP could then provide the new service data with the User's credential to the Registry/Registrar, which then makes the change. The old credential is revoked and a new one is provided. The new CSP or the Registrar would send a notification to the old CSP so they can disable service. The old CSP will undo any delegations to the User, including contacting the Credential Authority to revoke any cryptographic credentials (e.g., STIR
在最简单的场景中，有一个维护服务数据的权威组合注册表/注册器，用户可以向新的CSP提供他们的凭证，并让CSP启动服务更改。然后，新的CSP可以向注册中心/注册中心提供带有用户凭证的新服务数据，然后注册中心/注册中心进行更改。旧凭证被吊销，并提供新凭证。新的CSP或注册商将向旧的CSP发送通知，以便他们可以禁用服务。旧CSP将撤销对用户的任何委托，包括联系凭证颁发机构以撤销任何加密凭证（例如，STIR）
certificates [RFC8226]) previously granted to the User. Any service data maintained by the CSP must be removed, and, similarly, the CSP must delete any such information it provisioned in the Registry.
以前授予用户的证书[RFC8226]）。必须删除CSP维护的任何服务数据，同样，CSP必须删除它在注册表中提供的任何此类信息。
In a model similar to common practice in environments today, the User could alternatively provide their credential to the old CSP, and the old CSP would initiate the change in service. Or, a User could go directly to a Registrar to initiate a port. This framework should support all of these potential flows.
在一个类似于当今环境中常见做法的模型中，用户可以选择向旧CSP提供其凭证，旧CSP将启动服务更改。或者，用户可以直接到注册器处启动端口。这个框架应该支持所有这些潜在的流动。
Note that in cases with a distributed Registry that maintained service data, the Registry would also have to update the other Registries of the change.
请注意，在使用维护服务数据的分布式注册表的情况下，注册表还必须更新变更的其他注册表。
Consider a case where a User who subscribes to a communication service (and who received their TN from the CSP) wishes to terminate their service. At this time, the CSP will undo any delegations to the User, which may involve contacting the Credential Authority to revoke any cryptographic credentials (e.g., STIR certificates [RFC8226]) previously granted to the User. Any service data maintained by the CSP must be removed, and similarly, the CSP must delete any such information it provisioned in the Registrar. However, per the policy of the Numbering Authority, Registrars and CSPs may be required to preserve historical data that will be accessible to Government Entities or others through audits, even if it is no longer retrievable through service interfaces.
考虑这样一种情况，即订阅通信服务的用户（以及从CSP接收到他们的TN）的用户希望终止其服务。此时，CSP将撤销对用户的任何委托，这可能涉及联系凭证颁发机构以撤销先前授予用户的任何加密凭证（例如，STIR证书[RFC8226]）。必须删除CSP维护的任何服务数据，同样，CSP必须删除其在注册器中提供的任何此类信息。然而，根据编号机构的政策，可能要求登记员和CSP保存政府实体或其他人可以通过审计访问的历史数据，即使这些数据不再可以通过服务接口检索。
The TN will change state from assigned to unassigned, and the CSP will update the Registry. Depending on policies, the TN could go back into the Registry, CSP, or delegate's pool of available TNs and would likely enter an aging process.
TN将从已分配状态更改为未分配状态，CSP将更新注册表。根据策略，TN可能会返回到注册表、CSP或代理的可用TN池中，并可能进入老化过程。
In an alternative use case, a User who received their own TN assignment directly from a Registrar terminates their service with a CSP. At this time, the User might terminate their assignment from the Registrar and return the TN to the Registry for reassignment. Alternatively, they could retain the TN and elect to assign it to some other service at a later time.
在另一个用例中，直接从注册器接收到自己的TN分配的用户使用CSP终止其服务。此时，用户可能会终止他们从注册中心的分配，并将TN返回到注册中心进行重新分配。或者，他们可以保留TN，并选择稍后将其分配给其他服务。
Retrieval of administrative or service data will be subject to access restrictions based on the category of the specific data: public, semi-restricted, or restricted. Both administrative and service data can have data elements that fall into each of these categories. It is expected that the majority of administrative data will fall into
管理或服务数据的检索将受到基于特定数据类别的访问限制：公共、半限制或限制。管理数据和服务数据都可以包含属于这些类别的数据元素。预计大部分管理数据将归入
the semi-restricted category: access to this information may require some form of authorization, though service data crucial to reachability will need to be accessible. In some environments, it's possible that none of the service data necessary to initiate communication will be useful to an entity on the public Internet, or that all that service data will have dependencies on the origination point for calls.
半限制类别：访问此信息可能需要某种形式的授权，尽管对可访问性至关重要的服务数据需要可访问。在某些环境中，启动通信所需的任何服务数据都可能对公共Internet上的实体没有用处，或者所有这些服务数据都可能依赖于呼叫的发起点。
The retrieval protocol mechanism for semi-restricted and restricted data needs a way for the receiver of the request to identify the originator of the request and what is being requested. The receiver of the request will process that request based on this information.
半受限和受限数据的检索协议机制需要一种方法，使请求的接收者能够识别请求的发起人以及所请求的内容。请求的接收者将根据此信息处理该请求。
Either administrative or service data may be made publicly available by the authority that generates and provisions it. Under most circumstances, a CSP wants its communication service to be publicly reachable through TNs, so the retrieval interface supports public interfaces that permit clients to query for service data about a TN. Some service data may, however, require that the client be authorized to receive it, per the use case in Section 4.3.3.
行政或服务数据可由产生和提供数据的机构公开提供。在大多数情况下，CSP希望其通信服务可以通过TNs公开访问，因此检索接口支持公共接口，允许客户端查询关于TN的服务数据。但是，根据第4.3.3节中的用例，一些服务数据可能要求授权客户端接收。
Public data can simply be posted on websites or made available through a publicly available API. Public data hosted by a CSP may have a reference address at the Registry.
公共数据可以简单地发布在网站上，也可以通过公开的API提供。CSP托管的公共数据可能在注册表中有一个引用地址。
Consider a case in which a CSP is having service problems completing calls to a specific TN, so it wants to contact the CSP serving that TN. The Registry authorizes the originating CSP to access this information. It initiates a query to the Registry, the Registry verifies the requestor and the requested data, and the Registry responds with the serving CSP and contact data. However, CSPs might not want to make those administrative contact points public data: they are willing to share them with other CSPs for troubleshooting purposes, but not to make them available to general communication.
考虑一个CSP有服务问题完成对特定TN的调用的情况，因此它想联系TSP服务的CSP。注册表授权原始CSP访问此信息。它向注册表发起查询，注册表验证请求者和请求的数据，注册表使用服务CSP和联系人数据进行响应。但是，客户服务提供商可能不希望将这些管理联系人的数据公开：他们愿意与其他客户服务提供商共享这些数据，以便进行故障排除，但不希望将其用于一般通信。
Alternatively, that information could be part of a distributed data store and not stored at a monolithic Registry. In that case, the CSP has the data in a local distributed data store, and it initiates the query to the local data store. The local data store responds with the CSP and contact data. No verification is necessary because it was done when the CSP was authorized to receive the data store.
或者，该信息可以是分布式数据存储的一部分，而不是存储在单一注册表中。在这种情况下，CSP将数据保存在本地分布式数据存储中，并向本地数据存储发起查询。本地数据存储使用CSP和联系人数据进行响应。无需验证，因为验证是在CSP被授权接收数据存储时完成的。
Consider a case where a User on a CSP's network calls a TN. The CSP initiates a query for service data associated with the TN to complete the call and will receive special service data because the CSP operates in a closed environment where different CSPs receive different responses, and only participating CSPs can initiate communication. This service data would be flagged as semi-restricted. The query and response have real-time performance requirements in that environment.
考虑CSP网络上的用户调用TN的情况。CSP发起对与TN相关联的服务数据的查询以完成呼叫，并且将接收特殊服务数据，因为CSP在不同的CSP接收不同响应的封闭环境中工作，并且只有参与的CSP才能够发起通信。此服务数据将标记为半受限。查询和响应在该环境中具有实时性能要求。
Semi-restricted service data also works in a distributed data store model where each CSP distributes its updated service data to all other CSPs. The originating CSP has the service data in its local data store and queries it. The local data store responds with the service data. The service data in the response can be a reference address to a data store maintained by the serving CSP or it can be the service address itself. In the case where the response gives a reference address, a subsequent query would go to the serving CSP, who would, in turn, authorize the requestor for the requested data and respond appropriately. In the case, where the original response contains the service address, the requestor would use that service address as the destination for the call.
半受限服务数据也适用于分布式数据存储模型，其中每个CSP将其更新的服务数据分发给所有其他CSP。发起CSP在其本地数据存储中具有服务数据并对其进行查询。本地数据存储使用服务数据进行响应。响应中的服务数据可以是服务CSP维护的数据存储的参考地址，也可以是服务地址本身。在响应给出参考地址的情况下，后续查询将转到服务CSP，服务CSP将反过来授权请求者获取请求的数据并做出适当的响应。在原始响应包含服务地址的情况下，请求者将使用该服务地址作为调用的目的地。
In some environments, aspects of the service data may reside at the Registry itself (for example, the assigned CSP for a TN); thus, the query may be sent to the Registry. The Registry verifies the requestor and the requested data and responds with the service data, such as a SIP URI containing the domain of the assigned CSP.
在一些环境中，服务数据的方面可能驻留在注册表本身（例如，为TN分配的CSP）；因此，可以将查询发送到注册表。注册表验证请求者和请求的数据，并用服务数据（例如包含分配的CSP域的SIPURI）进行响应。
A Government Entity wishes to access information about a particular User who subscribes to a communication service. The entity that operates the Registry on behalf of the Numbering Authority in this case has some predefined relationship with the Government Entity. When the CSP acquired TNs from the Numbering Authority, it was a condition of that assignment that the CSP provide access for Government Entities to telephone numbering data when certain conditions apply. The required data may reside either in the CSP or in the Registrar.
政府实体希望访问有关订阅通信服务的特定用户的信息。在这种情况下，代表编号机构运行注册中心的实体与政府实体之间存在某种预定义的关系。当顾客服务提供商从电话号码管理局获得TNs时，该任务的一个条件是，在某些条件适用时，顾客服务提供商向政府实体提供电话号码数据的访问权限。所需数据可以驻留在CSP或注册器中。
For a case where the CSP delegates a number to the User, the CSP might provision the Registrar (or itself, if the CSP is composed with a Registrar) with information relevant to the User. At such a time as the Government Entity needs information about that User, the Government Entity may contact the Registrar or CSP to acquire the necessary data. The interfaces necessary for this will be the same
对于CSP将一个号码委托给用户的情况，CSP可以向注册者（或其自身，如果CSP由注册者组成）提供与用户相关的信息。当政府实体需要有关该用户的信息时，政府实体可联系注册官或CSP以获取必要的数据。这所需的接口将是相同的
as those described in Section 4.3; the Government Entity will be authenticated and an authorization decision will be made by the Registrar or CSP under the policy dictates established by the Numbering Authority.
如第4.3节所述；政府实体将通过认证，并由注册官或CSP根据编号机构制定的政策规定作出授权决定。
This document has no IANA actions.
本文档没有IANA操作。
This framework defines two categories of information about telephone numbers: service data and administrative data. Service data describes how telephone numbers map to particular services and devices that provide real-time communication for users. As such, service data could potentially leak resource locations and even lower-layer network addresses associated with these services, and in rare cases, with end-user devices. Administrative data more broadly characterizes who the administrative entities are behind telephone numbers, which will often identify CSPs but some layers of the architecture could include Personally Identifiable Information (PII), even WHOIS-style information, about the end users behind identifiers. This could conceivably encompass the sorts of data that carriers and similar CSPs today keep about their customers for billing purposes, like real names and postal addresses. The exact nature of administrative data is not defined by this framework, and it is anticipated that the protocols that will perform this function will be extensible for different use cases, so at this point, it is difficult to characterize exactly how much PII might end up being housed by these services.
这个框架定义了两类关于电话号码的信息：服务数据和管理数据。服务数据描述电话号码如何映射到为用户提供实时通信的特定服务和设备。因此，服务数据可能会泄漏资源位置，甚至泄漏与这些服务相关的较低层网络地址，在极少数情况下，还会泄漏最终用户设备。管理数据更广泛地描述了谁是电话号码背后的管理实体，电话号码通常会识别CSP，但架构的某些层可能包括个人识别信息（PII），甚至是关于标识符背后最终用户的WHOIS样式信息。这可能包括运营商和类似的顾客服务提供商今天为计费目的保留的关于客户的各种数据，如真实姓名和邮政地址。该框架未定义管理数据的确切性质，预计将执行此功能的协议将针对不同的用例进行扩展，因此在这一点上，很难准确描述这些服务最终容纳了多少PII。
As such, if an attacker were to compromise the registrar services that maintains administrative data in this architecture, and in some cases even service data, this could leak PII about end users. These interfaces, and the systems that host them, are a potentially attractive target for hackers and need to be hardened accordingly. Protocols that are selected to fulfill these functions must provide the security features described in Section 7.
因此，如果攻击者破坏在该体系结构中维护管理数据的注册器服务，在某些情况下甚至是服务数据，则可能会泄漏有关最终用户的PII。这些接口以及承载它们的系统是黑客潜在的攻击目标，需要相应地加强。为实现这些功能而选择的协议必须提供第7节所述的安全特性。
Finally, this framework recognizes that, in many jurisdictions, certain government agencies have a legal right to access service and administrative data maintained by CSPs. This access is typically aimed at identifying the users behind the communication identifier in order to enforce regulatory policy. Those legal entities already have the power to access the existing data held by CSPs in many jurisdictions, though, potentially, the administrative data associated with this framework could be richer information.
最后，该框架承认，在许多司法管辖区，某些政府机构有权访问CSP维护的服务和管理数据。这种访问通常旨在识别通信标识符后面的用户，以便实施监管政策。这些法律实体已经有权访问CSP在许多司法管辖区持有的现有数据，尽管与此框架相关的管理数据可能是更丰富的信息。
The acquisition, management, and retrieval of administrative and service data associated with telephone numbers raises a number of security issues.
与电话号码相关的管理和服务数据的获取、管理和检索引发了许多安全问题。
Any mechanism that allows an individual or organization to acquire telephone numbers will require a means of mutual authentication, of integrity protection, and of confidentiality. A Registry as defined in this document will surely want to authenticate the source of an acquisition request as a first step in the authorization process to determine whether or not the resource will be granted. Integrity of both the request and response is essential to ensuring that tampering does not allow attackers to block acquisitions, or worse, to commandeer resources. Confidentiality is essential to preventing eavesdroppers from learning about allocations, including the personally identifying information associated with the administrative or technical contracts for allocations.
任何允许个人或组织获取电话号码的机制都需要一种相互认证、完整性保护和保密的手段。本文档中定义的注册中心肯定希望验证获取请求的来源，作为确定是否授予资源的授权过程的第一步。请求和响应的完整性对于确保篡改不允许攻击者阻止获取，或者更糟的是，不允许攻击者侵占资源至关重要。保密对于防止窃听者了解分配至关重要，包括与分配管理或技术合同相关的个人身份信息。
A management interface for telephone numbers has similar requirements. Without proper authentication and authorization mechanisms in place, an attack could use the management interface to disrupt service data or administrative data, which could deny service to users, enable new impersonation attacks, prevent billing systems from operating properly, and cause similar system failures.
电话号码管理界面也有类似的要求。如果没有适当的身份验证和授权机制，攻击可能会使用管理接口中断服务数据或管理数据，从而拒绝向用户提供服务，启用新的模拟攻击，阻止计费系统正常运行，并导致类似的系统故障。
Finally, a retrieval interface has its own needs for mutual authentication, integrity protection, and confidentiality. Any CSP sending a request to retrieve service data associated with a number will want to know that it is reaching the proper authority, that the response from that authority has not been tampered with in transit, and, in most cases, the CSP will not want to reveal to eavesdroppers the number it is requesting or the response that it has received. Similarly, any service answering such a query will want to have a means of authenticating the source of the query and of protecting the integrity and confidentiality of its responses.
最后，检索接口对相互身份验证、完整性保护和机密性有自己的需求。任何发送请求以检索与号码相关的服务数据的CSP都希望知道它正在到达适当的机构，该机构的响应在传输过程中没有被篡改，并且在大多数情况下，CSP不希望向窃听者透露它请求的号码或它收到的响应。类似地，回答此类查询的任何服务都希望有一种方法来验证查询源，并保护其响应的完整性和机密性。
[DRIP] Wendt, C. and H. Bellur, "Distributed Registry Protocol (DRiP)", Work in Progress, draft-wendt-modern-drip-02, July 2017.
[DRIP]Wendt，C.和H.Bellur，“分布式注册协议（DRIP）”，正在进行的工作，草稿-Wendt-modern-DRIP-022017年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<https://www.rfc-editor.org/info/rfc3261>.
[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, DOI 10.17487/RFC3375, September 2002, <https://www.rfc-editor.org/info/rfc3375>.
[RFC3375]Hollenbeck，S.，“通用注册登记员协议要求”，RFC 3375，DOI 10.17487/RFC3375，2002年9月<https://www.rfc-editor.org/info/rfc3375>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC3912]Daigle，L.，“WHOIS协议规范”，RFC 3912，DOI 10.17487/RFC3912，2004年9月<https://www.rfc-editor.org/info/rfc3912>.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 6116, DOI 10.17487/RFC6116, March 2011, <https://www.rfc-editor.org/info/rfc6116>.
[RFC6116]Bradner，S.，Conroy，L.，和K.Fujiwara，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 6116DOI 10.17487/RFC6116，2011年3月<https://www.rfc-editor.org/info/rfc6116>.
[RFC6140] Roach, A., "Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)", RFC 6140, DOI 10.17487/RFC6140, March 2011, <https://www.rfc-editor.org/info/rfc6140>.
[RFC6140]Roach，A.，“在会话启动协议（SIP）中注册多个电话号码”，RFC 6140，DOI 10.17487/RFC6140，2011年3月<https://www.rfc-editor.org/info/rfc6140>.
[RFC6461] Channabasappa, S., Ed., "Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements", RFC 6461, DOI 10.17487/RFC6461, January 2012, <https://www.rfc-editor.org/info/rfc6461>.
[RFC6461]Channabasappa，S.，Ed.“网络间/网络内SIP（饮料）用例和协议要求的可达性数据”，RFC 6461，DOI 10.17487/RFC6461，2012年1月<https://www.rfc-editor.org/info/rfc6461>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, <https://www.rfc-editor.org/info/rfc7482>.
[RFC7482]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）查询格式”，RFC 7482，DOI 10.17487/RFC7482，2015年3月<https://www.rfc-editor.org/info/rfc7482>.
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>.
[RFC8226]Peterson，J.和S.Turner，“安全电话身份凭证：证书”，RFC 8226，DOI 10.17487/RFC8226，2018年2月<https://www.rfc-editor.org/info/rfc8226>.
[TERI-INFO] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", Work in Progress, draft-peterson-modern-teri-04, March 2018.
[TERI-INFO]Peterson，J.，“电话相关信息（TERI）的架构和信息模型”，正在进行的工作，草稿-Peterson-modern-TERI-042018年3月。
Acknowledgments
致谢
We would like to thank Henning Schulzrinne and Adam Roach for their contributions to this problem statement and framework; we would also like to thank Pierce Gorman for detailed comments.
我们要感谢Henning Schulzrinne和Adam Roach对这个问题陈述和框架的贡献；我们还要感谢皮尔斯·戈尔曼的详细评论。
Authors' Addresses
作者地址
Jon Peterson Neustar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 United States of America
Jon Peterson Neustar，Inc.美国加利福尼亚州康科德市萨特街1800号570室，邮编：94520
Email: jon.peterson@neustar.biz
Email: jon.peterson@neustar.biz
Tom McGarry
汤姆麦加里
Email: tmcgarry6@gmail.com
Email: tmcgarry6@gmail.com