RFC 8396
Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework
Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework 🎀
okay bestie, the title block has all the deets 💅 This is RFC 8396, published by the IETF in July 2018 ✨ It's Informational (so it's published for info, not as a standards-track spec 🌸). The authors are J. Peterson from NeuStar, Inc. and T. McGarry 🫶 (no affiliation is listed for T. McGarry). The ISSN is 2070-1721 💜 The title block doesn't list anything it obsoletes or updates.
Abstract
The PSTN is migrating to the Internet 🌈, and that's bringing new demands to old PSTN stuff, including Telephone Numbers (TNs). TNs aren't just routing addresses anymore. They're identifiers that Internet services use for session establishment, identity verification, and service enablement 💜 This doc checks out how today's tools for allocating and managing phone numbers don't fit Internet use cases, and it proposes a framework for Internet-based services that rely on TNs 🔥
Status of This Memo
This document is not an Internet Standards Track specification 🙅♀️ It's 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, so see Section 2 of RFC 7841 ✨
For info on the current status of this document, any errata, and how to give feedback, check 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. Please review these docs carefully, since 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 they're provided without warranty as described in the Simplified BSD License 🧾
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 . . . . . . . . . . . . . . . . . . . . . . . 221. Problem Statement ✨
okay so the struggle of using Telephone Numbers (TNs) on the Internet is not new 😭 Internet telephony was the first thing to route phone numbers over the Internet in a way that's similar to how calls get routed on the PSTN 📞 The Internet had no service for finding the endpoints tied to a phone number, so ENUM [RFC6116] came in with a DNS-based way to turn TNs into URIs, the kind used by protocols like SIP [RFC3261] 🧚 The resulting database was designed to work like the systems that route calls on the PSTN. ENUM was originally envisioned as a global hierarchical service, but in practice it's 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, so less centralized models have flourished 🌸 Later on, the Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) framework [RFC6461] showed ways that service providers could provision info about TNs at an ENUM service or a similar Internet-based directory 💅 These technologies have generally tried to keep the features and architecture that are familiar from the PSTN numbering environment 🫶
Over time, Internet telephony has picked up functions that differ a lot from traditional PSTN routing and management, especially as non-traditional providers started using 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, then hands those numbers out to new IP telephones when they associate with the PBX 📱 Internet services give users portals where they can allocate new telephone numbers on the fly, assign multiple "alias" telephone numbers to a single line service, run mobility or find-me-follow-me apps, 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 lets a user choose and change their service provider while keeping their TN. It's been implemented in many countries, either for all telephony services or for subsets (e.g., mobile) 🦋 But TN administration processes rooted in PSTN technology and policies made number porting fraught with problems and delays 😤 Originally, processes were built to tie 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 move the TN's association from one provider to another 🛠️ Thanks to consumer mobile devices becoming Internet endpoints as well as telephones, users now associate TNs with lots of Internet applications besides telephony 📲 That's sparked new interest in models like the ones used to administer freephone (non-geographic, toll-free numbers) services in the United States 🇺🇸 There, a user buys 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 the TN 🎀
Most TNs today are assigned to specific geographies, both at an international level and within national numbering plans 🗺️ Numbering practices are tightly coupled with the way service providers interconnect and with how TNs are routed and administered, since 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 isn't anchored to geography in the same way the telephone network is 🌐 In an Internet environment, a network architecture for routing TNs could depend little on geography and instead rely 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's important to say upfront 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 🫶
2. Definitions 📚
This section provides definitions for actors, data types, and data management architectures as they're 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 💖
2.1. Actors ✨
okay bestie, let's talk about who's who in this whole numbering drama 💅 there are a bunch of roles defined in this doc, and they're all kind of iconic in their own way 👑
Numbering Authority: a regulatory body within a region that manages that region's TNs 🏛️ it's the boss that decides national numbering policy for the nation, region, or other domain it has authority over. that includes what TNs can be allocated, which are reserved, and which entities may obtain TNs. main character energy, no cap 😤
Registry: an entity that administers the allocation of TNs based on a Numbering Authority's policies 📋 Numbering Authorities can totally 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 🫶 but distributed registries (see Section 2.3) are also in scope for this framework 🌈
Credential Authority: an entity that distributes credentials, like certificates that attest the authority of assignees (defined below) and delegates 🎀 this doc assumes that one or more Credential Authorities may be trusted by actors in any given regulatory environment 🔐 policies for establishing that trust are outside the scope of this document, so we're not going there today 🙈
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 too 🦋 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 traditional telephone carriers or enterprises, as well as service providers with no presence on the PSTN who still 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 🧚 maybe 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 👀 it's giving authority with a badge 🚨
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, which is so relatable 😭 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 🧁
Okay, here's the example that made it click for me ✨ imagine a Numbering Authority that also acts as a Registry 🏛️ it issues blocks of 10,000 TNs to CSPs that, in this case, also act as Registrars 📦 those CSP/Registrars then handle distributing numbering resources to Users and other CSPs 🤝
Now zoom into an enterprise deploying IP PBXs 🏢 it acts as a CSP too, and it acquires number blocks for its enterprise seats in chunks of 100 from a CSP acting as a Registrar it has a business relationship with 💼 the enterprise is the assignee, since it gets numbering resources directly from a Registrar 🎀 then, as it doles out individual numbers to its Users, the enterprise delegates its own numbering resources to those Users and their communication endpoints 💖 the whole ecosystem looks like this 👇
+---------+
|Numbering|
|Authority|Registry
+----+----+
|
V 10,000 TNs
+---------+
| CSP |Registrar
+----+----+
|
V 100 TNs
+---------+
| PBX |Assignee
+---------+
|
V 1 TN
+---------+
| User |Delegate
+---------+
Figure 1: Chain of Number Assignment2.2. Data Types 🎀
okay so 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 it typically does not require real-time access 🐢 this is because this data isn't needed for ordinary call or session establishment 📵
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 ⚡ no waiting around, bestie 😤
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 🔒
Restricted: only a small subset of actors can access restricted data 🕵️ for example, a Government Entity may be able to 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 🧐 so we keep both, periodt 💅
2.3. Data Management Architectures 🏗️
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 honestly the DNS provides an obvious inspiration for the relationships between those entities 🌐 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 🙅♀️
The role of a Registry described here is a "thin" one 🥗 the Registry manages basic allocation information for the numbering space, such as 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 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 🙏 no double-booking allowed, iykyk 💀
3. Framework ✨
okay so bestie, this section is the blueprint for the whole thing 🧚💖 the framework needs three Internet-based mechanisms for managing and resolving TNs (telephone numbers) in an IP environment. and lowkey the wild part is it probably won't need brand new protocols 🙈 it'll just reuse existing ways of sharing structured data. the real main character work is in the new information models for the data itself 💅 the likely candidates to borrow from are DRINKS [RFC6461], Web Extensible Internet Registration Data Service (WEIRDS) [RFC7482], and the Telephone-Related Information (TeRI) framework [TERI-INFO]. iykyk 🎀
the framework isn't here to tell anyone how to run number policy 🫶 it just gives tools that keep working as policies evolve. so these mechanisms don't assume number administration is centralized, and they don't assume only certain kinds of service providers can get allocations. BUT these tools must and will work in environments with those properties. no cap 👑
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 lets actors grab TNs for use with a communication service by requesting numbering resources from a service run by a Registrar, CSP, or similar actor 💖 TNs can be requested one number at a time or as inventory blocks. and any actor who hands out numbering resources has to keep metadata about the assignment, including which organization or individual the numbers were assigned to. ngl that's the paper trail 📝
the management mechanism lets actors provision data associated with TNs 🎀 for example, if a User has been assigned a TN, they can pick a CSP to provide a service tied to that TN, or a CSP can assign a TN to a User when service activates. either way, there needs to be a way to provision the TN's data at that CSP, and to extend those data sets whenever CSPs (and even Users) need more 🧚
the retrieval mechanism lets actors learn stuff about TNs 🔥 for real-time service data this usually means sending a request to a CSP. for other info, an actor might need to ask a Registry instead of a CSP. and different parties may be allowed to receive different information about TNs, so it's not one-size-fits-all 🌈
as an example, a CSP might use the acquisition interface to grab a chunk of numbers from a Registrar 💅 then Users provision their administrative data for those numbers at the CSP through the management interface, and query for service data about them through the CSP's retrieval interface 🫶
+--------+
|Registry|
+---+----+
|
V
+---------+
|Registrar|
+---------+
\
\\
Acquisition \\
\\+-------+
\ CSP |
+---+---+
A A
| |
Management | | Retrieval
| |
| |
+-------++ ++-------+
| User | | User |
+--------+ +--------+
(Delegate) (Caller)
Figure 2: Example of the Three Interfaces4. Use Cases 🌸
okay this part is the highlight reel 🎬 the high-level use cases show how the three interfaces are expected to work in the MODERN problem space. slay 💖
4.1. Acquisition
so there are lots of ways TNs can be acquired by the relevant actors 🦋 that's a CSP, a Service Enabler, and a User. three actors can hand out numbers: a Registrar, a CSP, and a User (presumably one delegating to another party) 🧚 the assumption is either that Registrars are the same entity as Registries, or that Registrars have business relationships with Registries that let them distribute the numbers the Registries administer 📝 and in these use cases, a User can acquire TNs from a CSP, a Registry, or an intermediate delegate ✨
4.1.1. Acquiring TNs from Registrar
this is the most traditional one 👑 a CSP, like a carrier, asks a Registrar for a block of numbers to hold as inventory or to assign to customers 💅
first, through some out-of-band business process 🙈, the CSP builds a relationship with a Registrar. the Registrar keeps a profile of the CSP and checks whether or not CSPs meet the policy restrictions for acquiring TNs 🎀 then the CSP can request TNs from a specific pool in the Registry's authority, like region, mobile, wireline, or freephone 🌈 the Registrar MUST authenticate and authorize the CSP, and then either grant or deny the request 🔥
when an assignment happens, the Registry creates and stores administrative info about it, like TN status and Registrar contact info, and removes the specific TN(s) from the pool of numbers available for assignment 💖 as part of acquisition and assignment, the Registry gives the Registrar any tokens or other material a Credential Authority needs 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 📝
before a CSP can get TN assignments, per the policy of a Numbering Authority, it may need to have submitted (again, through some out-of-band process) extra qualifying info, like its current utilization rate or a demand forecast 🫶
there are two scenarios where a CSP requests resources: either it wants inventory, or it wants numbers for a specific User or delegate ✨ for status info, TNs assigned to a User are always considered assigned, not inventory 💜 the CSP associates service info for that TN (e.g., a service address) and makes it available to other CSPs so they can interconnect 🦋 the CSP MAY need to update the Registrar about this service activation, which is part of the "TN status" the Registrar maintains 🎀
there are also cases where a User can get a TN straight from a Registrar 💅 today, a User who wants a freephone number can browse the existing inventory through one or more Registrars and compare prices and services 🌸 each of those Registrars 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 set up some business relationship directly with a Registrar, kinda like how it works today when Users buy domain names 🙈 in this use case, after getting a number assignment from the Registrar, the User gets communication service from a CSP and gives that CSP the TN to use for the service 💖 the CSP associates service info for that TN (e.g., the service address) and makes it available to other CSPs for interconnection 🔥 and the User MUST also tell the Registrar about this relationship 👑
4.1.2. Acquiring TNs from CSPs
today a User usually gets a TN from a CSP when they sign up for a communication service or turn on a new device 📱✨ here the User becomes the delegate of the CSP 🫶 a reseller or service bureau might also acquire a block of numbers from a CSP to issue to Users 💅
picture this: a User creates or has a relationship with the CSP and subscribes to a communication service that includes a TN 🎀 the CSP collects and stores administrative data about the User 📝 then it activates the User on its network and creates any service data needed for connectivity with other CSPs 🦋 the CSP could also update public or privileged databases that other actors can access 🌈 the CSP provides any tokens or other material a Credential Authority needs to issue credentials to the User (for example, a STIR certificate [RFC8226]) to prove the assignment for future transactions 🧚 those credentials could be delegated from the ones the Credential Authority gave the CSP, so the chain of assignment continues 💜 CSPs MAY be required to log such transactions if the Numbering Authority's policy requires it 🙈
the same flow works for a reseller 💖 it forms a business relationship with the CSP, and the CSP collects and stores administrative data about the reseller and gives the reseller any material it needs to get credentials for the numbers ✨ a User can then acquire numbers from the reseller, and in that case the delegate redelegating the TNs is doing the stuff the CSP did (like providing credentials, collecting administrative data, or creating service data) 🔥
the CSP can assign a TN from its existing inventory, or it can get a new TN from the Registrar as part of the assignment process 🌸 if it assigns from inventory, it removes that TN from the pool 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 🫶
4.2. Management
the management protocol mechanism is needed to associate administrative and service data with TNs 🎀 it can also be used to refresh or roll over associated credentials 🧚
4.2.1. Management of Administrative Data
administrative data is mainly about the TN's status, its administrative contacts, and the actors involved in providing service to the TN 💅 so protocol interactions for admin data mostly happen between CSPs and Users and the Registrar, or between Users and delegate CSPs and the CSP 🦋
some admin data may be private, so it needs special handling in a distributed data store model 🔒 accessing it doesn't need real-time performance, so local caches are not necessary 🙈 and this data includes sensitive stuff like User and contact data 🌸
some of the data could be public, like CSP and TN assignment status 🌈 if so, it counts as public information for the purposes of the retrieval interface 💖
bestie heads up: the three mechanisms and the MUST/MAY/SHOULD words in here are the actual rules, so keep them in mind as we go 🫶
4.2.1.1. Managing Data at a Registrar ✨
okay so after a CSP grabs a TN or a whole block of TNs from the Registrar (see Section 4.1.1), it has to send its administrative data over to the Registrar as part of the acquisition 💅. The Registrar checks the CSP's identity and figures out if that CSP is allowed to provision admin data for those TNs 🔐. The Registry updates the TN's status to unavailable for assignment, and the Registrar keeps holding onto whatever admin data the CSP gave it 📇. bestie, it's a whole handoff 🫶
Admin data doesn't change very often 🌸. 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 that proves administrative responsibility for the TN 🎀.
In some cases, like the freephone system in North America today, the User has a direct relationship with the Registrar 📞. Naturally, these Users could send their admin data straight to the Registrar, kind of like how a freephone provider today keeps account and billing data 💜. Delegates usually don't have a direct relationship with a Registrar 🙈, but some environments (as an optimization) might want the delegate to update the Registrar directly whenever something changes, instead of sending that data to the CSP or passing it through the CSP to the Registrar ✨. As we already said, the protocol should let Users acquire TNs directly from a Registrar, and that Registrar may or may not also be a CSP 🦋. In those cases, the updates would look a lot like the ones described in Section 4.2.1.1 💖.
In a distributed Registry model, the TN status (for example allocated, assigned, available, or unavailable) has to get sent to the other Registries in real time ⏱️. The other admin data could be sent to every Registry, or the other Registries could just get a reference address pointing to the host Registry's data store 🧚. no cap, this is so clean 😭
4.2.1.2. Managing Data at a CSP 🌈
After a User acquires a TN or a block of TNs from a CSP, the User gives their admin data to the CSP 💅. The CSP usually acts as a Registrar in this situation, keeping the admin data and only telling the Registry about the change in TN status 📬. In this setup, the Registry keeps a reference address (see Section 2.3) pointing to the CSP/Registrar's admin data store, so the relevant actors can get to that data 🔍. Or, a CSP could instead send the admin data to an external Registrar for storage 📦. If there's a delegate between the CSP and the User, they will have to make sure there's a way for the delegate to update the CSP whenever something changes 🫶🎀.
4.2.2. Management of Service Data 💫
Service data is the info an originating or intermediate CSP needs in order to provide communication service to a User 📡. A SIP URI is one example of a service data element that's commonly used for routing calls 📞. CSPs usually create and manage service data, but delegates and Users could totally do it too 👑. For most use cases with individual Users, lower-level service info changes (like an end-user device getting a new IP address) are expected to go to CSPs through existing protocols 🦋. For example, the baseline SIP REGISTER [RFC3261] method, even for bulk operations [RFC6140], would probably get used instead of any new interfaces defined by MODERN 🌸.
4.2.2.1. CSP to Other CSPs 🔁
After a User signs up for service with a CSP, if that CSP got the TN from a Registrar, the CSP will then create a service address (like a SIP URI) and link it to the TN 🎀. The CSP needs to update this data so service interoperability works 🫶. There are a bunch of ways this update can happen, but most commonly the service data gets exposed through the retrieval interface (see Section 4.3) ✨. For certain deployment architectures, like a distributed data store model, CSPs might need to provision data directly to other CSPs 🧚.
If the CSP is assigning a TN from its own inventory, it may not need to do service data updates as changes happen 💅, because the existing service data tied to that inventory might be good enough once the TN is put in service 🌟. They would still probably update the Registry about the change in status though 📬.
4.2.2.2. User to CSP 💌
Users can also link service data to their TNs at the CSP 💖. For example, a User gets a TN from the Registrar (as described in Section 4.1.1) and wants to hand that TN to the CSP so the CSP can turn on service 🍓. Once the User gives the number to the CSP, the CSP would update the Registry or other actors as outlined in Section 4.2.2.1 🔥.
4.2.3. Managing Change 🦋
This section covers some special management use cases that weren't covered above 🎀.
4.2.3.1. Changing the CSP for an Existing Service 🔄
Picture this: a User subscribes to a communication service (and got their TN from that CSP) and wants to keep the same TN but move their service to a different CSP 💅.
In the simplest scenario, there's an authoritative combined Registry/Registrar that maintains service data 👑. The User can give their credential to the new CSP and let that CSP start the change in service 🫶. The new CSP then sends the new service data, along with the User's credential, to the Registry/Registrar, which makes the change ✨. The old credential gets revoked and a new one gets issued 🔐. The new CSP or the Registrar sends a notification to the old CSP so they can disable service 📨. The old CSP undoes any delegations to the User, including contacting the Credential Authority to revoke any cryptographic credentials (for example STIR certificates [RFC8226]) that were previously granted to the User 🧚. Any service data the CSP maintains must be removed, and similarly, the CSP must delete any such information it provisioned in the Registry 🗑️. it's giving clean breakup energy 💀
In a model that's similar to what's common today, the User could instead give their credential to the old CSP, and the old CSP would start the change in service 🌈. Or, a User could go directly to a Registrar to start a port 📲. This framework should support all of these potential flows 💜.
Note that in cases with a distributed Registry that maintains service data, the Registry would also have to tell the other Registries about the change ⏱️.
4.2.3.2. Terminating a Service 🙅♀️
Okay, imagine a User who subscribes to a communication service (and got their TN from the CSP) wants to terminate their service 😭. At this point, the CSP will undo any delegations to the User, which might involve contacting the Credential Authority to revoke any cryptographic credentials (for example STIR certificates [RFC8226]) that were previously granted to the User 🔐. Any service data the CSP maintains must be removed, and similarly, the CSP must delete any such information it provisioned in the Registrar 🗑️. However, depending on the policy of the Numbering Authority, Registrars and CSPs may be required to keep historical data that Government Entities or others can access through audits, even if it's 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's, the CSP's, or the delegate's pool of available TNs, and it would probably go through an aging process ⏳.
In an alternative use case, a User who got their own TN assignment directly from a Registrar terminates their service with a CSP 💁♀️. At that point, the User might end their assignment from the Registrar and return the TN to the Registry for reassignment ♻️. Or, they could keep the TN and choose to assign it to some other service later on 🌸.
4.3. Retrieval 🔍
Retrieval of administrative or service data is 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 🫶. The majority of administrative data is expected to fall into the semi-restricted category 🔒: accessing this info may require some form of authorization, though service data that's crucial to reachability needs to stay accessible ✨. In some environments, none of the service data needed to start communication might be useful to an entity on the public Internet, or all of that service data might depend 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's being requested 🕵️♀️. The receiver of the request processes that request based on this info 💅.
4.3.1. Retrieval of Public Data 🌍
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 let clients 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 🔐.
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 🧚.
4.3.2. Retrieval of Semi-restricted Administrative Data 🤫
Picture this: 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 info 🔑. The CSP sends a query to the Registry, the Registry verifies the requestor and the requested data 🕵️♀️, and then the Registry responds with the serving CSP and contact data 💌. Still, CSPs might not want those administrative contact points to be public data 🙅♀️: they're willing to share them with other CSPs for troubleshooting purposes, but not to make them available to general communication 🎀.
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 sends its query to that local data store 💻. The local data store responds with the CSP and contact data 🫶. No verification is necessary, because it was already done when the CSP was authorized to receive the data store 🦋 ✨
4.3.3. Retrieval of Semi-restricted Service Data 📞
Okay so picture this, bestie: a User on a CSP's network calls a TN 📞. The CSP starts a query for the service data tied to that TN so it can finish the call. It gets special service data back because the CSP lives in a closed environment where different CSPs get different responses, and only participating CSPs are allowed to start communication. 🔒 This service data gets flagged as semi-restricted 🏷️. The query and response also have real-time performance requirements in that environment ⏱️, so speed is everything here 💅.
Semi-restricted service data also works in a distributed data store model 🌐, where each CSP distributes its updated service data to all the other CSPs. The originating CSP already has the service data in its own local data store, so it queries that store, and 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. 🦋 If the response gives a reference address, a subsequent query goes to the serving CSP, who then authorizes the requestor for the requested data and responds appropriately. 🔐 If the original response contains the service address, the requestor uses that service address as the destination for the call 📲.
Some environments keep aspects of the service data at the Registry itself, like the assigned CSP for a TN 🗂️. In that case, the query may be sent to the Registry. The Registry verifies the requestor and the requested data, then responds with the service data, such as a SIP URI containing the domain of the assigned CSP 🧚.
4.3.4. Retrieval of Restricted Data 🕵️♀️
Here's a tea moment ☕. A Government Entity wants 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 has some predefined relationship with that Government Entity 🤝. When the CSP acquired TNs from the Numbering Authority, one condition of that assignment was that the CSP provide Government Entities with access to telephone numbering data when certain conditions apply 📜. The required data may reside in the CSP or in the Registrar, depending on the setup.
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 that User 🗃️. When the Government Entity needs information about that User, it may contact the Registrar or CSP to get the necessary data. The interfaces for this will be the same as the ones described in Section 4.3. The Government Entity gets authenticated, and an authorization decision is made by the Registrar or CSP under the policy dictates established by the Numbering Authority 🛡️.
5. IANA Considerations 🌷
No IANA stuff to worry about here, bestie 🙌. This document has no IANA actions.
6. Privacy Considerations 🫣
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 📡. Because of that, service data could potentially leak resource locations and even lower-layer network addresses associated with those services, and in rare cases, with end-user devices 👀.
Administrative data more broadly characterizes who the administrative entities are behind telephone numbers 🏢. That 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 cover the kinds of data that carriers and similar CSPs 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. The protocols that perform this function are anticipated to be extensible for different use cases, so right now it's hard to say exactly how much PII might end up being housed by these services 🤷♀️.
So, if an attacker compromised the registrar services that maintain administrative data in this architecture, and in some cases even service data, that could leak PII about end users 😱. These interfaces, and the systems that host them, are a potentially attractive target for hackers, so they need to be hardened accordingly 🔥. Protocols selected to fulfill these functions must provide the security features described in 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 ⚖️. That access is typically aimed at identifying the users behind a communication identifier, so regulatory policy can be enforced 🧐. Legal entities already have the power to access the existing data CSPs hold in many jurisdictions. Still, the administrative data associated with this framework could potentially be richer information 📈.
7. Security Considerations 🚨🔐
Okay, this section is serious business, so let's get into it 💀. The acquisition, management, and retrieval of administrative and service data associated with telephone numbers raises a number of security issues.
Any mechanism that lets an individual or organization acquire telephone numbers is going to need a way to do mutual authentication, integrity protection, and 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 figure out whether the resource will be granted 🧐. Integrity of both the request and the response is essential. Tampering could let attackers block acquisitions or, worse, commandeer resources 😈. Confidentiality is essential too, so eavesdroppers can't learn about allocations, including the personally identifying information tied to the administrative or technical contracts for those allocations 🙈.
A management interface for telephone numbers has similar requirements 🛠️. Without proper authentication and authorization mechanisms in place, an attacker could use the management interface to disrupt service data or administrative data. That could deny service to users, enable new impersonation attacks, stop billing systems from operating properly, and cause similar system failures 💥.
Last but not least, 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, and that the response from that authority hasn't been tampered with in transit 📬. In most cases, the CSP also won't want to reveal to eavesdroppers the number it's requesting or the response it has received 🤫. Similarly, any service answering such a query will want a way to authenticate the source of the query and to protect the integrity and confidentiality of its responses 🛡️✨.
8. Informative References 📚
These are the informative references, so you can go deeper whenever you want 🧠:
[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.Acknowledgments 🫶
Huge thank-yous to Henning Schulzrinne and Adam Roach for their contributions to this problem statement and framework 💜. We also want to thank Pierce Gorman for the detailed comments 🌸.
Authors' Addresses 🖋️
Jon Peterson
Neustar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
United States of America
Email: jon.peterson@neustar.biz
Tom McGarry
Email: tmcgarry6@gmail.com📦 where this page comes from
- ietf: rfc8396 2018-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms