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
AbstractThe 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. 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. 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.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 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. 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 184.108.40.206. Managing Data at a Registrar . . . . . . . . . . 14 220.127.116.11. Managing Data at a CSP . . . . . . . . . . . . . 15 4.2.2. Management of Service Data . . . . . . . . . . . . . 15 18.104.22.168. CSP to Other CSPs . . . . . . . . . . . . . . . . 16 22.214.171.124. User to CSP . . . . . . . . . . . . . . . . . . . 16 4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16 126.96.36.199. Changing the CSP for an Existing Service . . . . 16 188.8.131.52. 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
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. 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. 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
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. 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. 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.
Section 2.3) are also in the scope of this framework. 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
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. 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. 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. 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. Assignee: An actor that is assigned a TN directly by a Registrar; an assignee always has a direct relationship with a Registrar. 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. 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.
+---------+ |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
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. 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. 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
distributed registry system is discussed further in [DRIP]. To support those use cases, it is important to distinguish the following: 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. 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. 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. RFC6461] and Web Extensible Internet Registration Data Service (WEIRDS) [RFC7482], as well as the Telephone-Related Information (TeRI) framework [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. Management: A protocol mechanism for associating data with TNs. Retrieval: A protocol mechanism for retrieving data about 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. 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. 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. 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.
+--------+ |Registry| +---+----+ | V +---------+ |Registrar| +---------+ \ \\ Acquisition \\ \\+-------+ \ CSP | +---+---+ A A | | Management | | Retrieval | | | | +-------++ ++-------+ | User | | User | +--------+ +--------+ (Delegate) (Caller) Figure 2: Example of the Three Interfaces
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. 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. 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. 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
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. 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. 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). 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 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. 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. Changes to this administrative data will not be frequent. Examples of changes would be terminating service (see Section 184.108.40.206), 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.
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 220.127.116.11. 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. 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. RFC3261] method, even for bulk operations [RFC6140], would likely be used rather than through any new interfaces defined by MODERN.
Section 4.3). For certain deployment architectures, like a distributed data store model, CSPs may need to provision data directly to other CSPs. 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. 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 18.104.22.168.
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. 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. 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. 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. 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. 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.
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. 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. Section 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.
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. Section 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.
[DRIP] Wendt, C. and H. Bellur, "Distributed Registry Protocol (DRiP)", Work in Progress, draft-wendt-modern-drip-02, July 2017. [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>.
[RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol Requirements", RFC 3375, DOI 10.17487/RFC3375, September 2002, <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>. [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>. [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>. [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>. [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>. [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>. [TERI-INFO] Peterson, J., "An Architecture and Information Model for Telephone-Related Information (TeRI)", Work in Progress, draft-peterson-modern-teri-04, March 2018.