draft-ietf-modern-problem-framework-04.txt   rfc8396.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft T. McGarry Request for Comments: 8396 NeuStar, Inc.
Intended status: Informational NeuStar, Inc. Category: Informational T. McGarry
Expires: September 6, 2018 March 5, 2018 ISSN: 2070-1721 July 2018
Modern Problem Statement, Use Cases, and Framework Managing, Ordering, Distributing, Exposing, and Registering Telephone
draft-ietf-modern-problem-framework-04.txt Numbers (MODERN): Problem Statement, Use Cases, and Framework
Abstract Abstract
The functions of the public switched telephone network (PSTN) are The functions of the Public Switched Telephone Network (PSTN) are
rapidly migrating to the Internet. This is generating new rapidly migrating to the Internet. This is generating new
requirements for many traditional elements of the PSTN, including requirements for many traditional elements of the PSTN, including
telephone numbers (TNs). TNs no longer serve simply as telephone Telephone Numbers (TNs). TNs no longer serve simply as telephone
routing addresses: they are now identifiers which may be used by routing addresses: they are now identifiers that may be used by
Internet-based services for a variety of purposes including session Internet-based services for a variety of purposes including session
establishment, identity verification, and service enablement. This establishment, identity verification, and service enablement. This
problem statement examines how the existing tools for allocating and problem statement examines how the existing tools for allocating and
managing telephone numbers do not align with the use cases of the managing telephone numbers do not align with the use cases of the
Internet environment, and proposes a framework for Internet-based Internet environment and proposes a framework for Internet-based
services relying on TNs. services relying on TNs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on September 6, 2018. 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 Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Management Architectures . . . . . . . . . . . . . . 8 2.3. Data Management Architectures . . . . . . . . . . . . . . 8
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12 4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12
4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13 4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13
4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Management of Administrative Data . . . . . . . . . . 14 4.2.1. Management of Administrative Data . . . . . . . . . . 14
4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14 4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14
4.2.1.2. Managing Data at a CSP . . . . . . . . . . . . . 15 4.2.1.2. Managing Data at a CSP . . . . . . . . . . . . . 15
4.2.2. Management of Service Data . . . . . . . . . . . . . 15 4.2.2. Management of Service Data . . . . . . . . . . . . . 15
4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 15 4.2.2.1. CSP to Other CSPs . . . . . . . . . . . . . . . . 16
4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16 4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16
4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16 4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16
4.2.3.1. Changing the CSP for an Existing Service . . . . 16 4.2.3.1. Changing the CSP for an Existing Service . . . . 16
4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17 4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17
4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18 4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18
4.3.2. Retrieval of Semi-restricted Administrative Data . . 18 4.3.2. Retrieval of Semi-restricted Administrative Data . . 18
4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 18 4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 19
4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19 4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Informative References . . . . . . . . . . . . . . . . . . . 21
9. Informative References . . . . . . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Problem Statement 1. Problem Statement
The challenges of utilizing telephone numbers (TNs) on the Internet The challenges of utilizing Telephone Numbers (TNs) on the Internet
have been known for some time. Internet telephony provided the first have been known for some time. Internet telephony provided the first
use case for routing telephone numbers on the Internet in a manner use case for routing telephone numbers on the Internet in a manner
similar to how calls are routed in the public switched telephone similar to how calls are routed in the Public Switched Telephone
network (PSTN). As the Internet had no service for discovering the Network (PSTN). As the Internet had no service for discovering the
endpoints associated with telephone numbers, ENUM [3] created a DNS- endpoints associated with telephone numbers, ENUM [RFC6116] created a
based mechanism for resolving TNs in an IP environment, by defining DNS-based mechanism for translating TNs into URIs, as used by
procedures for translating TNs into URIs for use by protocols such as protocols such as SIP [RFC3261]. The resulting database was designed
SIP [2]. The resulting database was designed to function in a manner to function in a manner similar to the systems that route calls in
similar to the systems that route calls in the PSTN. Originally, it the PSTN. Originally, it was envisioned that ENUM would be deployed
was envisioned that ENUM would be deployed as a global hierarchical as a global hierarchical service; however, in practice, it has only
service, though in practice, it has only been deployed piecemeal by been deployed piecemeal by various parties. Most notably, ENUM is
various parties. Most notably, ENUM is used as an internal network used as an internal network function and is rarely used between
function, and is rarely used between service provider networks. The service provider networks. The original ENUM concept of a single
original ENUM concept of a single root, e164.arpa, proved to be root, e164.arpa, proved to be politically and practically
politically and practically challenging, and less centralized models challenging, and less centralized models have thus flourished.
have thus flourished. Subsequently, the DRINKS [4] framework showed Subsequently, the Data for Reachability of Inter-/Intra-NetworK SIP
ways that service providers might provision information about TNs at (DRINKS) framework [RFC6461] showed ways that service providers might
an ENUM service or similar Internet-based directory. These provision information about TNs at an ENUM service or similar
technologies have also generally tried to preserve the features and Internet-based directory. These technologies have also generally
architecture familiar to the PSTN numbering environment. tried to preserve the features and architecture familiar to the PSTN
numbering environment.
Over time, Internet telephony has encompassed functions that differ Over time, Internet telephony has encompassed functions that differ
substantially from traditional PSTN routing and management, substantially from traditional PSTN routing and management,
especially as non-traditional providers have begun to utilize especially as non-traditional providers have begun to utilize
numbering resources. An increasing number of enterprises, over-the- numbering resources. An increasing number of enterprises, over-the-
top voice-over-IP (VoIP) providers, text messaging services, and top Voice over IP (VoIP) providers, text messaging services, and
related non-carrier services have become heavy users of telephone related non-carrier services have become heavy users of telephone
numbers. An enterprise, for example, can deploy an IP PBX that numbers. An enterprise, for example, can deploy an IP Private Branch
receives a block of telephone numbers from a carrier and then in turn Exchange (PBX) that receives a block of telephone numbers from a
distribute those numbers to new IP telephones when they associate carrier and then, in turn, distributes those numbers to new IP
with the PBX. Internet services offer users portals where they can telephones when they associate with the PBX. Internet services offer
allocate new telephone numbers on the fly, assign multiple "alias" users portals where they can allocate new telephone numbers on the
telephone numbers to a single line service, implement various fly, assign multiple "alias" telephone numbers to a single line
mobility or find-me-follow-me applications, and so on. Peer-to-peer service, implement various mobility or find-me-follow-me
telephone networks have encouraged experiments with distributed applications, and so on. Peer-to-peer telephone networks have
databases for telephone number routing and even allocation. encouraged experiments with distributed databases for telephone
number routing and even allocation.
This dynamic control over telephone numbers has few precedents in the This dynamic control over telephone numbers has few precedents in the
traditional PSTN outside of number portability. Number portability traditional PSTN outside of number portability. Number portability
allows the capability of a user to choose and change their service allows the capability of a user to choose and change their service
provider while retaining their TN; it has been implemented in many provider while retaining their TN; it has been implemented in many
countries; either for all telephony services or for subsets such as countries either for all telephony services or for subsets (e.g.,
mobile. However, TN administration processes rooted in PSTN mobile). However, TN administration processes rooted in PSTN
technology and policies dictate that this be an exception process technology and policies made number porting fraught with problems and
fraught with problems and delays. Originally, processes were built delays. Originally, processes were built to associate a specific TN
to associate a specific TN to a specific service provider and never to a specific service provider and never change it. With number
change it. With number portability, the industry had to build new portability, the industry had to build new infrastructure and new
infrastructure, new administrative functions and processes to change administrative functions and processes to change the association of
the association of the TN from one service provider to another. the TN from one service provider to another. Thanks to the
Thanks to the increasing sophistication of consumer mobile devices as increasing sophistication of consumer mobile devices as Internet
Internet endpoints as well as telephones, users now associate TNs endpoints as well as telephones, users now associate TNs with many
with many Internet applications other than telephony. This has Internet applications other than telephony. This has generated new
generated new interest in models similar to those in place for interest in models similar to those in place for administering
administering freephone (non-geographic toll free numbers) services freephone (non-geographic, toll-free numbers) services in the United
in the United States, where a user purchases a number through a sort States, where a user purchases a number through a sort of number
of number registrar and controls its administration (such as routing) registrar and controls its administration (such as routing) on their
on their own, typically using Internet services to directly make own, typically using Internet services to directly make changes to
changes to the service associated with telephone numbers. the service associated with telephone numbers.
Most TNs today are assigned to specific geographies, at both an Most TNs today are assigned to specific geographies, at both an
international level and within national numbering plans. Numbering international level and within national numbering plans. Numbering
practices today are tightly coupled with the manner that service practices today are tightly coupled with the manner that service
providers interconnect, as well as how TNs are routed and providers interconnect as well as with how TNs are routed and
administered: the PSTN was carefully designed to delegate switching administered: the PSTN was carefully designed to delegate switching
intelligence geographically. In interexchange carrier routing in intelligence geographically. In interexchange carrier routing in
North America, for example, calls to a particular TN are often handed North America, for example, calls to a particular TN are often handed
off to the terminating service provider close to the geography where off to the terminating service provider close to the geography where
that TN is assigned. But the overwhelming success of mobile that TN is assigned. But the overwhelming success of mobile
telephones has increasingly eroded the connection between numbers and telephones has increasingly eroded the connection between numbers and
regions. Furthermore, the topology of IP networks is not anchored to regions. Furthermore, the topology of IP networks is not anchored to
geography in the same way that the telephone network is. In an geography in the same way that the telephone network is. In an
Internet environment, establishing a network architecture for routing Internet environment, establishing a network architecture for routing
TNs could depend little on geography, relying instead on network TNs could depend little on geography, relying instead on network
topologies or other architectural features. Adapting TNs to the topologies or other architectural features. Adapting TNs to the
Internet requires more security, richer datasets and more complex Internet requires more security, richer datasets, and more complex
query and response capabilities than previous efforts have provided. query and response capabilities than previous efforts have provided.
This document attempts to create a common understanding of the This document attempts to create a common understanding of the
problem statement related to allocating, managing, and resolving TNs problem statement related to allocating, managing, and resolving TNs
in an IP environment, the focus of the IETF MODERN (Managing, in an IP environment, which is the focus of the IETF Managing,
Ordering, Distributing, Exposing, and Registering telephone Numbers) Ordering, Distributing, Exposing, and Registering telephone Numbers
working group. It outlines a framework and lists motivating use (MODERN) Working Group. It outlines a framework and lists motivating
cases for creating IP-based mechanisms for TNs. It is important to use cases for creating IP-based mechanisms for TNs. It is important
acknowledge at the outset that there are various evolving to acknowledge at the outset that there are various evolving
international and national policies and processes related to TNs, and international and national policies and processes related to TNs, and
any solutions need to be flexible enough to account for variations in any solutions need to be flexible enough to account for variations in
policy and requirements. policy and requirements.
2. Definitions 2. Definitions
This section provides definitions for actors, data types and data This section provides definitions for actors, data types, and data
management architectures as they are discussed in this document. management architectures as they are discussed in this document.
Different numbering spaces may instantiate these roles and concepts Different numbering spaces may instantiate these roles and concepts
differently: practices that apply to non-geographic freephone differently: practices that apply to non-geographic freephone
numbers, for example, may not apply to geographic numbers, and numbers, for example, may not apply to geographic numbers, and
practices that exist under one Numbering Authority may not be practices that exist under one Numbering Authority may not be
permitted under another. The purpose of this framework is to permitted under another. The purpose of this framework is to
identify the characteristics of protocol tools that will satisfy the identify the characteristics of protocol tools that will satisfy the
diverse requirements for telephone number acquisition, management, diverse requirements for telephone number acquisition, management,
and retrieval on the Internet. and retrieval on the Internet.
2.1. Actors 2.1. Actors
The following roles of actors are defined in this document: The following roles of actors are defined in this document.
Numbering Authority: A regulatory body within a region that manages Numbering Authority: A regulatory body within a region that manages
that regions TNs. The Numbering Authority decides national that region's TNs. The Numbering Authority decides national
numbering policy for the nation, region, or other domain for which numbering policy for the nation, region, or other domain for which
it has authority, including what TNs can be allocated, which are it has authority, including what TNs can be allocated, which are
reserved, and which entities may obtain TNs. reserved, and which entities may obtain TNs.
Registry: An entity that administers the allocation of TNs based on Registry: An entity that administers the allocation of TNs based on
a Numbering Authority's policies. Numbering authorities can act a Numbering Authority's policies. Numbering Authorities can act
as the Registries themselves, or they can outsource the function as the Registries themselves, or they can outsource the function
to other entities. Traditional registries are single entities to other entities. Traditional registries are single entities
with sole authority and responsibility for specific numbering with sole authority and responsibility for specific numbering
resources, though distributed registries (see Section 2.3) are resources, though distributed registries (see Section 2.3) are
also in the scope of this framework. also in the scope of this framework.
Credential Authority: An entity that distributes credentials, such Credential Authority: An entity that distributes credentials, such
as certificates that attest the authority of assignees (defined as certificates that attest the authority of assignees (defined
below) and delegates. This document assumes that one of more below) and delegates. This document assumes that one or more
credential authorities may be trusted by actors in any given Credential Authorities may be trusted by actors in any given
regulatory environment; policies for establishing such trust regulatory environment; policies for establishing such trust
anchors are outside the scope of this document. anchors are outside the scope of this document.
Registrar: An entity that distributes the telephone numbers Registrar: An entity that distributes the telephone numbers
administered by a Registry; typically, there are many Registrars administered by a Registry; typically, there are many Registrars
that can distribute numbers from a single Registry, though that can distribute numbers from a single Registry, though
Registrars may serve multiple Registries as well. A Registrar has Registrars may serve multiple Registries as well. A Registrar has
business relationships with number assignees and collects business relationships with number assignees and collects
administrative information from them. administrative information from them.
Communication Service Provider (CSP): A provider of communications Communication Service Provider (CSP): A provider of communication
services, where those services can be identified by TNs. This service where those services can be identified by TNs. This
includes both traditional telephone carriers or enterprises as includes both traditional telephone carriers or enterprises as
well as service providers with no presence on the PSTN who use well as service providers with no presence on the PSTN who use
TNs. This framework does not assume that any single CSP provides TNs. This framework does not assume that any single CSP provides
all the communications service related to a particular TN. all the communication service related to a particular TN.
Service Enabler: An entity that works with CSPs to enable Service Enabler: An entity that works with CSPs to enable
communication service to a User; perhaps a vendor, a service communication service to a User: perhaps a vendor, a service
bureau, or third-party integrator. bureau, or a third-party integrator.
User: An individual reachable through a communications service; User: An individual reachable through a communication service:
usually a customer of a communication service provider. usually a customer of a Communication Service Provider.
Government Entity: An entity that, due to legal powers deriving from Government Entity: An entity that, due to legal powers deriving from
national policy, has privileged access to information about number national policy, has privileged access to information about number
administration under certain conditions. administration under certain conditions.
Note that an individual, organization, or other entity may act in one 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 or more of the roles above; for example, a company may be a CSP and
also a Registrar. Although Numbering Authorities are listed as also a Registrar. Although Numbering Authorities are listed as
actors, they are unlikely to actually participate in the protocol actors, they are unlikely to actually participate in the protocol
flows themselves, though in some situations a Numbering Authority and flows themselves; however, in some situations, a Numbering Authority
Registry may be the same administrative entity. and Registry may be the same administrative entity.
All actors that are recipients of numbering resources, be they a 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 Service Enabler, or User, can also be said to have a relationship to
a Registry of either an assignee or delegate: a Registry of either an assignee or delegate.
Assignee: An actor that is assigned a TN directly by a Registrar; an Assignee: An actor that is assigned a TN directly by a Registrar; an
assignee always has a direct relationship with a Registrar. assignee always has a direct relationship with a Registrar.
Delegate: An actor that is delegated a TN from an assignee or Delegate: An actor that is delegated a TN from an assignee or
another delegate, who does not necessarily have a direct another delegate who does not necessarily have a direct
relationship with a Registrar. Delegates may delegate one or more relationship with a Registrar. Delegates may delegate one or more
of their TN assignment(s) to one or more further downstream of their TN assignment(s) to one or more subdelegates from further
subdelegates. downstream.
As an example, consider a case where a Numbering Authority also acts 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, which in 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 this case, also act as Registrars. CSP/Registrars would then be
responsible for distributing numbering resources to Users and other responsible for distributing numbering resources to Users and other
CSPs. In this case, an enterprise deploying IP PBXs also acts as a 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 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 of 100 from a CSP acting as a Registrar with whom the enterprise has
a business relationship. The enterprise is in this case the a business relationship. The enterprise is, in this case, the
assignee, as it receives numbering resources directly from a assignee, as it receives numbering resources directly from a
Registrar. As it doles out individual numbers to its Users, the Registrar. As it doles out individual numbers to its Users, the
enterprise delegates its own numbering resources to those Users and enterprise delegates its own numbering resources to those Users and
their communications endpoints. The overall ecosystem might look as their communication endpoints. The overall ecosystem might look as
follows. follows.
+---------+ +---------+
|Numbering| |Numbering|
|Authority|Registry |Authority|Registry
+----+----+ +----+----+
| |
V 10,000 TNs V 10,000 TNs
+---------+ +---------+
| CSP |Registrar | CSP |Registrar
+----+----+ +----+----+
| |
V 100 TNs V 100 TNs
+---------+ +---------+
| PBX |Assignee | PBX |Assignee
+---------+ +---------+
| |
V 1 TN V 1 TN
+---------+ +---------+
| User |Delegate | User |Delegate
+---------+ +---------+
Figure 1: Chain of Number Assignment Figure 1: Chain of Number Assignment
2.2. Data Types 2.2. Data Types
The following data types are defined in this document: The following data types are defined in this document.
Administrative Data: assignment data related to the TN and the Administrative Data: Assignment data related to the TN and the
relevant actors; it includes TN status (assigned, unassigned, relevant actors; it includes TN status (assigned, unassigned,
etc.), contact data for the assignee or delegate, and typically etc.), contact data for the assignee or delegate, and typically
does not require real-time access as this data is not required for does not require real-time access as this data is not required for
ordinary call or session establishment. ordinary call or session establishment.
Service Data: data necessary to enable service for the TN; it Service Data: Data necessary to enable service for the TN; it
includes addressing data and service features. Since this data is includes addressing data and service features. Since this data is
necessary to complete calls, it must be obtained in real time. necessary to complete calls, it must be obtained in real time.
Administrative and service data can fit into three access categories: Administrative and service data can fit into three access categories:
Public: Anyone can access public data. Such data might include a Public: Anyone can access public data. Such data might include a
list of which numbering resources (unallocated number ranges) are list of which numbering resources (unallocated number ranges) are
available for acquisition from the Registry. available for acquisition from the Registry.
Semi-restricted: Only a subset of actors can access semi-restricted 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. For example, CSPs may be able to access other CSP's service
data in some closed environment. data in some closed environment.
Restricted: Only a small subset of actors can access restricted Restricted: Only a small subset of actors can access restricted
data. For example a Government Entity may be able access contact data. For example, a Government Entity may be able access contact
information for a User. information for a User.
While it might appear there are really only two categories, public While it might appear there are really only two categories, public
and restricted based on requestor, the distinction between semi- and restricted (based on the requestor), the distinction between
restricted and restricted is helpful for the use cases below. semi-restricted and restricted is helpful for the use cases below.
2.3. Data Management Architectures 2.3. Data Management Architectures
This framework generally assumes that administrative and service data This framework generally assumes that administrative and service data
is maintained by CSPs, Registrars, and Registries. The terms is maintained by CSPs, Registrars, and Registries. The terms
"registrar" and "registry" are familiar from DNS operations, and "registrar" and "registry" are familiar from DNS operations, and
indeed the DNS provides an obvious inspiration for the relationships indeed the DNS provides an obvious inspiration for the relationships
between those entities described here. Protocols for transferring between those entities described here. Protocols for transferring
names between registries and registrars have been standardized in the names between registries and registrars have been standardized in the
DNS space for some time (see [14]). Similarly, the division between DNS space for some time (see [RFC3375]). Similarly, the division
service data acquired by resolving names with the DNS protocol vs. between service data acquired by resolving names with the DNS
administrative data about names acquired through WHOIS [15] is protocol versus administrative data about names acquired through
directly analogous to the distinction between service and WHOIS [RFC3912] is directly analogous to the distinction between
administrative data described in Section 2.2. The major difference service and administrative data described in Section 2.2. The major
between the data management architecture of the DNS and this difference between the data management architecture of the DNS and
framework is that the distinction between the CSP and User, due to this framework is that the distinction between the CSP and User, due
historical policies of the telephone network, will often not exactly to historical policies of the telephone network, will often not
correspond to the distinction between a name service and a registrant exactly correspond to the distinction between a name service and a
in the DNS world - a User in the telephone network is today at least registrant in the DNS world -- a User in the telephone network is
rarely in a direct relationship with a Registrar comparable to that today at least rarely in a direct relationship with a Registrar
of a DNS registrant. comparable to that of a DNS registrant.
The role of a Registry described here is a "thin" one, where the The role of a Registry described here is a "thin" one, where the
Registry manages basic allocation information for the numbering Registry manages basic allocation information for the numbering
space, such as information about whether or not the number is space, such as information about whether or not the number is
assigned, and if assigned, by which Registrar. It is the Registrar assigned, and if assigned, by which Registrar. It is the Registrar
that in turn manages detailed administrative data about those that, in turn, manages detailed administrative data about those
assignments, such as contact or billing information for the assignee. assignments, such as contact or billing information for the assignee.
In some models, CSPs and Registrars will be combined (the same In some models, CSPs and Registrars will be combined (the same
administrative entity), and in others the Registry and Registrar may administrative entity), and in others the Registry and Registrar may
similarly be composed. Typically, service data resides largely at similarly be composed. Typically, service data resides largely at
the CSP itself, though in some models a "thicker" Registry may itself 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. contain a pointer to the servicing CSP for a number or number block.
In addition to traditional centralized Registries, this framework In addition to traditional centralized Registries, this framework
also supports environments where the same data is being managed by also supports environments where the same data is being managed by
multiple administrative entities, and stored in many locations. A multiple administrative entities and stored in many locations. A
distributed registry system is discussed further in [19]. To support distributed registry system is discussed further in [DRIP]. To
those use cases, it is important to distinguish the following: support those use cases, it is important to distinguish the
following:
Data store: A Data Store is a service that stores and enables access Data Store: A data store is a service that stores and enables access
to administrative and/or service data. to administrative and/or service data.
Reference Address: A Reference Address is a URL that dereferences to Reference Address: A reference address is a URL that dereferences to
the location of the data store. the location of the data store.
Distributed data stores: In a Distributed Data Store, administrative Distributed Data Stores: In a distributed data store, administrative
or service data can be stored with multiple actors. For example, or service data can be stored with multiple actors. For example,
CSPs could provision their service data to multiple other CSPs. CSPs could provision their service data to multiple other CSPs.
Distributed Registries: Multiple Registries can manage the same Distributed Registries: Multiple Registries can manage the same
numbering resource. In these architectures, actors could interact numbering resource. In these architectures, actors could interact
with one or multiple Registries. The Registries would update each with one or multiple Registries. The Registries would update each
other when change occurs. The Registries have to ensure that data other when change occurs. The Registries have to ensure that data
remains consistent, e.g. that the same TN is not assigned to two remains consistent, e.g., that the same TN is not assigned to two
different actors. different actors.
3. Framework 3. Framework
The framework outlined in this document requires three Internet-based The framework outlined in this document requires three Internet-based
mechanisms for managing and resolving telephone numbers (TNs) in an mechanisms for managing and resolving TNs in an IP environment.
IP environment. These mechanisms will likely reuse existing These mechanisms will likely reuse existing protocols for sharing
protocols for sharing structured data; it is unlikely that new structured data; it is unlikely that new protocol development work
protocol development work will be required, though new information will be required, though new information models specific to the data
models specific to the data itself will be a major focus of framework itself will be a major focus of framework development. Likely
development. Likely candidates for reuse here include work done in candidates for reuse here include work done in DRINKS [RFC6461] and
DRINKS [4] and WEIRDS [12], as well as the TeRI [16] framework. 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 These protocol mechanisms are scoped in a way that makes them likely
to apply to a broad range of future policies for number to apply to a broad range of future policies for number
administration. It is not the purpose of this framework to dictate administration. It is not the purpose of this framework to dictate
number policy, but instead to provide tools that will work with number policy but instead to provide tools that will work with
policies as they evolve going forward. These mechanisms therefore do policies as they evolve going forward. These mechanisms, therefore,
not assume that number administration is centralized, nor that number do not assume that number administration is centralized nor that
allocations are restricted to any category of service providers, number allocations are restricted to any category of service
though these tools must and will work in environments with those providers, though these tools must and will work in environments with
properties. those properties.
The three mechanisms are: The three mechanisms are:
Acquisition: a protocol mechanism for acquiring TNs, including an Acquisition: A protocol mechanism for acquiring TNs, including an
enrollment process. enrollment process.
Management: a protocol mechanism for associating data with TNs. Management: A protocol mechanism for associating data with TNs.
Retrieval: a protocol mechanism for retrieving data about TNs. Retrieval: A protocol mechanism for retrieving data about TNs.
The acquisition mechanism will enable actors to acquire TNs for use The acquisition mechanism will enable actors to acquire TNs for use
with a communications service by requesting numbering resources from with a communication service by requesting numbering resources from a
a service operated by a Registrar, CSP or similar actor. TNs may be service operated by a Registrar, CSP, or similar actor. TNs may be
requested either on a number-by-number basis, or as inventory blocks. requested either on a number-by-number basis or as inventory blocks.
Any actor who grants numbering resources will retain metadata about Any actor who grants numbering resources will retain metadata about
the assignment, including the responsible organization or individual the assignment, including the responsible organization or individual
to whom numbers have been assigned. to whom numbers have been assigned.
The management mechanism will let actors provision data associated The management mechanism will let actors provision data associated
with TNs. For example, if a User has been assigned a TN, they may 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, 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 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 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 the TN at that CSP and to extend those data sets as CSPs (and even
Users) require. Users) require.
The retrieval mechanism will enable actors to learn information about The retrieval mechanism will enable actors to learn information about
TNs. For real-time service data, this typically involves sending a 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 CSP; for other information, an actor may need to send a
request to a Registry rather than a CSP. Different parties may be request to a Registry rather than a CSP. Different parties may be
authorized to receive different information about TNs. authorized to receive different information about TNs.
As an example, a CSP might use the acquisition interface to acquire a As an example, a CSP might use the acquisition interface to acquire a
chunk of numbers from a Registrar. Users might then provision chunk of numbers from a Registrar. Users might then provision
administrative data associated with those numbers at the CSP through administrative data associated with those numbers at the CSP through
the management interface, and query for service data relating to the management interface and query for service data relating to those
those numbers through the retrieval interface of the CSP. numbers through the retrieval interface of the CSP.
+--------+ +--------+
|Registry| |Registry|
+---+----+ +---+----+
| |
V V
+---------+ +---------+
|Registrar| |Registrar|
+---------+ +---------+
\ \
\\ \\
Acquisition \\ Acquisition \\
\\+-------+ \\+-------+
\ CSP | \ CSP |
+---+---+ +---+---+
A A A A
| | | |
Management | | Retrieval Management | | Retrieval
| | | |
| | | |
+-------++ ++-------+ +-------++ ++-------+
| User | | User | | User | | User |
+--------+ +--------+ +--------+ +--------+
(delegate) (caller) (Delegate) (Caller)
Figure 2: Example of the Three Interfaces Figure 2: Example of the Three Interfaces
4. Use Cases 4. Use Cases
The high-level use cases in this section will provide an overview of The high-level use cases in this section will provide an overview of
the expected operation of the three interfaces in the MODERN problem the expected operation of the three interfaces in the MODERN problem
space: space.
4.1. Acquisition 4.1. Acquisition
There are various scenarios for how TNs can be acquired by the There are various scenarios for how TNs can be acquired by the
relevant actors, that is, a CSP, Service Enabler, and a User. There relevant actors, that is, a CSP, Service Enabler, and a User. There
are three actors from which numbers can be acquired: a Registrar, a are three actors from which numbers can be acquired: a Registrar, a
CSP and a User (presumably one who is delegating to another party). CSP, and a User (presumably one who is delegating to another party).
It is assumed that Registrars are either the same entity as It is assumed either that Registrars are the same entity as
Registries, or that Registrars have established business Registries or that Registrars have established business relationships
relationships with Registries that enable them to distribute the with Registries that enable them to distribute the numbers that the
numbers that the Registries administer. In these use cases, a User Registries administer. In these use cases, a User may acquire TNs
may acquire TNs either from a CSP or a Registry, or from an either from a CSP, a Registry, or an intermediate delegate.
intermediate delegate.
4.1.1. Acquiring TNs from Registrar 4.1.1. Acquiring TNs from Registrar
The most traditional number acquisition use case is one where a CSP, 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 such as a carrier, requests a block of numbers from a Registrar to
hold as inventory or assign to customers. hold as inventory or assign to customers.
Through some out-of-band business process, a CSP develops a Through some out-of-band business process, a CSP develops a
relationship with a Registrar. The Registrar maintains a profile of relationship with a Registrar. The Registrar maintains a profile of
the CSP and assesses whether or not CSPs meet the policy restrictions the CSP and assesses whether or not CSPs meet the policy restrictions
for acquiring TNs. The CSP may then request TNs from within a for acquiring TNs. The CSP may then request TNs from within a
specific pool of numbers in the authority of the Registry; such as specific pool of numbers in the authority of the Registry, such as
region, mobile, wireline, or freephone. The Registrar must region, mobile, wireline, or freephone. The Registrar must
authenticate and authorize the CSP, and then either grant or deny a authenticate and authorize the CSP and then either grant or deny a
request. When an assignment occurs, the Registry creates and stores request. When an assignment occurs, the Registry creates and stores
administrative information related to the assignment such as TN administrative information related to the assignment, such as TN
status and Registrar contact information, and removes the specific status and Registrar contact information, and removes the specific
TN(s) from the pool of those that are available for assignment. As a TN(s) from the pool of those that are available for assignment. As a
part of the acquisition and assignment process, the Registry provides part of the acquisition and assignment process, the Registry provides
to the Registrar any tokens or other material needed by a Credential to the Registrar any tokens or other material needed by a Credential
Authority to issue credentials (for example, STIR certificates [17]) Authority to issue credentials (for example, Secure Telephone
used to attest the assignment for future transactions. Depending on Identity Revisited (STIR) certificates [RFC8226]) used to attest the
the policies of the Numbering Authorities, Registrars may be required assignment for future transactions. Depending on the policies of the
to log these operations. Numbering Authorities, Registrars may be required to log these
operations.
Before it is eligible to receive TN assignments, per the policy of a Before it is eligible to receive TN assignments, per the policy of a
Numbering Authority, the CSP may need to have submitted (again, Numbering Authority, the CSP may need to have submitted (again,
through some out-of-band process) additional qualifying information through some out-of-band process) additional qualifying information
such as current utilization rate or a demand forecast. such as the current utilization rate or a demand forecast.
There are two scenarios under which a CSP requests resources; they There are two scenarios under which a CSP requests resources: either
are requesting inventory, or they are requesting for a specific User they are requesting inventory or they are requesting for a specific
or delegate. For the purpose of status information, TNs assigned to User or delegate. For the purpose of status information, TNs
a User are always considered assigned, not inventory. The CSP will assigned to a User are always considered assigned, not inventory.
associate service information for that TN, e.g., service address, and The CSP will associate service information for that TN (e.g., a
make it available to other CSPs to enable interconnection. The CSP service address) and make it available to other CSPs to enable
may need to update the Registrar regarding this service activation; interconnection. The CSP may need to update the Registrar regarding
this is part of the "TN status" maintained by the Registrar. 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 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 from a Registrar. Today, a User wishing to acquire a freephone
number may browse the existing inventory through one or more number may browse the existing inventory through one or more
Registrars, comparing their prices and services. Each such Registrar Registrars, comparing their prices and services. Each such Registrar
either is a CSP, or has a business relationship with one or more CSPs 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 to provide services for that freephone number. In this case, the
User must establish some business relationship directly with a User must establish some business relationship directly with a
Registrar, similarly to how such functions are conducted today when Registrar, similar to how such functions are conducted today when
Users purchase domain names. In this use case, after receiving a Users purchase domain names. In this use case, after receiving a
number assignment from the Registrar, a User will then obtain number assignment from the Registrar, a User will obtain
communications service from a CSP, and provide to the CSP the TN to communication service from a CSP and provide to the CSP the TN to be
be used for that service. The CSP will associate service information used for that service. The CSP will associate service information
for that TN, e.g., service address, and make it available to other for that TN (e.g., the service address) and make it available to
CSPs to enable interconnection. The user will also need to inform other CSPs to enable interconnection. The User will also need to
the Registrar about this relationship. inform the Registrar about this relationship.
4.1.2. Acquiring TNs from CSPs 4.1.2. Acquiring TNs from CSPs
Today, a User typically acquires a TN from CSP when signing up for Today, a User typically acquires a TN from a CSP when signing up for
communications service or turning on a new device. In this use case, a communication service or turning on a new device. In this use
the User becomes the delegate of the CSP. A reseller or a service case, the User becomes the delegate of the CSP. A reseller or a
bureau might also acquire a block of numbers from a CSP to be issued service bureau might also acquire a block of numbers from a CSP to be
to Users. issued to Users.
Consider a case where a User creates or has a relationship with the Consider a case where a User creates or has a relationship with the
CSP, and subscribes to a communications service which includes the CSP and subscribes to a communication service that includes the use
use of a TN. The CSP collects and stores administrative data about of a TN. The CSP collects and stores administrative data about the
the User. The CSP then activates the User on their network and User. The CSP then activates the User on their network and creates
creates any necessary service data to enable connectivity with other any necessary service data to enable connectivity with other CSPs.
CSPs. The CSP could also update public or privileged databases The CSP could also update public or privileged databases accessible
accessible by other Actors. The CSP provides any tokens or other by other actors. The CSP provides any tokens or other material
material needed by a Credential Authority to issue credentials to the needed by a Credential Authority to issue credentials to the User
User (for example, a STIR certificate [17]) to prove the assignment (for example, a STIR certificate [RFC8226]) to prove the assignment
for future transactions. Such credentials could be delegated from for future transactions. Such credentials could be delegated from
the one provided by the Credential Authority to the CSP to continue the one provided by the Credential Authority to the CSP to continue
the chain of assignment. CSPs may be required to log such the chain of assignment. CSPs may be required to log such
transactions, if required by the policy of the Numbering Authority. transactions if required by the policy of the Numbering Authority.
Virtually the same flow would work for a reseller: it would form a Virtually, the same flow would work for a reseller: it would form a
business relationship with the CSP, at which point the CSP would business relationship with the CSP, at which point the CSP would
collect and store administrative data about the reseller and give the collect and store administrative data about the reseller and give the
reseller any material needed for the reseller to acquire credentials reseller any material needed for the reseller to acquire credentials
for the numbers. A user might then in turn acquire numbers from the for the numbers. A User might then, in turn, acquire numbers from
reseller: in this case, the delegate re-delegating the TNs would be the reseller: in this case, the delegate redelegating the TNs would
performing functions done by the CSP, e.g., providing any be performing functions done by the CSP (e.g., providing any
credentials, collecting administrative data, or creative service credentials or collecting administrative data or creative service
data. data).
The CSP could assign a TN from its existing inventory or it could 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 acquire a new TN from the Registrar as part of the assignment
process. If it assigns it from its existing inventory, it would process. If it assigns it from its existing inventory, it would
remove the specific TN from the pool of those available for remove the specific TN from the pool of those available for
assignment. It may also update the Registrar about the assignment so assignment. It may also update the Registrar about the assignment so
the Registrar has current assignment data. If a reseller or delegate the Registrar has current assignment data. If a reseller or delegate
CSP is acquiring the numbers, it may have the same obligations to CSP is acquiring the numbers, it may have the same obligations to
provide utilization data to the Registry as the assignee, per provide utilization data to the Registry as the assignee, per
Section 4.1.1. Section 4.1.1.
4.2. Management 4.2. Management
The management protocol mechanism is needed to associate The management protocol mechanism is needed to associate
administrative and service data with TNs, and may be used to refresh administrative and service data with TNs and may be used to refresh
or rollover associated credentials. or rollover associated credentials.
4.2.1. Management of Administrative Data 4.2.1. Management of Administrative Data
Administrative data is primarily related to the status of the TN, its Administrative data is primarily related to the status of the TN, its
administrative contacts, and the actors involved in providing service administrative contacts, and the actors involved in providing service
to the TN. Protocol interactions for administrative data will to the TN. Protocol interactions for administrative data will
therefore predominantly occur between CSPs and Users to the therefore predominantly occur between CSPs and Users to the Registrar
Registrar, or between Users and delegate CSPs to the CSP. or between Users and delegate CSPs to the CSP.
Some administrative data may be private, and would thus require Some administrative data may be private and would thus require
special handling in a distributed data store model. Access to it special handling in a distributed data store model. Access to it
does not require real-time performance therefore local caches are not does not require real-time performance; therefore, local caches are
necessary. And it will include sensitive information such as user not necessary, and the data will include sensitive information such
and contact data. as User and contact data.
Some of the data could lend itself to being publicly available, such 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 as CSP and TN assignment status. In that case, it would be deemed
public information for the purposes of the retrieval interface. public information for the purposes of the retrieval interface.
4.2.1.1. Managing Data at a Registrar 4.2.1.1. Managing Data at a Registrar
After a CSP acquires a TN or block of TNs from the Registrar (per After a CSP acquires a TN or block of TNs from the Registrar (per
Section 4.1.1 above), it then provides administrative data to the Section 4.1.1), it then provides administrative data to the Registrar
Registrar as a step in the acquisition process. The Registrar will as a step in the acquisition process. The Registrar will
authenticate the CSP and determine if the CSP is authorized to authenticate the CSP and determine if the CSP is authorized to
provision the administrative data for the TNs in question. The provision the administrative data for the TNs in question. The
Registry will update the status of the TN, i.e., that it is Registry will update the status of the TN, i.e., that it is
unavailable for assignment. The Registrar will also maintain unavailable for assignment. The Registrar will also maintain
administrative data provided by the CSP. administrative data provided by the CSP.
Changes to this administrative data will not be frequent. Examples Changes to this administrative data will not be frequent. Examples
of changes would be terminating service (see Section 4.2.3.2), 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 changing the name or address of a User or organization, or changing a
CSP or delegate. Changes should be authenticated by a credential to CSP or delegate. Changes should be authenticated by a credential to
prove administrative responsibility for the TN. prove administrative responsibility for the TN.
In some cases, such as the freephone system in North America today, In some cases, such as the freephone system in North America today,
the User has a direct relationship with the Registrar. Naturally, the User has a direct relationship with the Registrar. Naturally,
these users could provision administrative data associated with their these Users could provision administrative data associated with their
TNs directly to the Registrar, just as a freephone provider today TNs directly to the Registrar just as a freephone provider today
maintains account and billing data. While delegates may not maintains account and billing data. While delegates may not
ordinarily have a direct relationship to a Registrar, some ordinarily have a direct relationship to a Registrar, some
environments as an optimization might want to support a model where environments (as an optimization) might want to support a model where
the delegate updates the Registrar directly on changes, as opposed to 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 sending that data to the CSP or through the CSP to the Registrar. As
stated already, the protocol should enable Users to acquire TNs stated already, the protocol should enable Users to acquire TNs
directly from a Registrar, which Registrar may or may not also act as directly from a Registrar, which may or may not also act as a CSP.
a CSP. In these cases the updates would be similar to that described In these cases, the updates would be similar to those described in
in Section 4.2.1.1. Section 4.2.1.1.
In a distributed Registry model, TN status, e.g., allocated, In a distributed Registry model, TN status (e.g., allocated,
assigned, available, unavailable, would need to be provided to other assigned, available, or unavailable) would need to be provided to
Registries in real-time. Other administrative data could be sent to other Registries in real time. Other administrative data could be
all Registries or other Registries could get a reference address to sent to all Registries, or other Registries could get a reference
the host Registry's data store. address to the host Registry's data store.
4.2.1.2. Managing Data at a CSP 4.2.1.2. Managing Data at a CSP
After a User acquires a TN or block of TNs from a CSP, the User will 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 provide administrative data to the CSP. The CSP commonly acts as a
Registrar in this case, maintaining the administrative data and only Registrar in this case by maintaining the administrative data and
notifies the Registry of the change in TN status. In this case, the only notifying the Registry of the change in TN status. In this
Registry maintains a reference address (see Section 2.3) to the CSP/ case, the Registry maintains a reference address (see Section 2.3) to
Registrar's administrative data store so relevant actors have the the CSP/Registrar's administrative data store so relevant actors have
ability to access the data. Alternatively, a CSP could send the the ability to access the data. Alternatively, a CSP could send the
administrative data to an external Registrar to store. If there is a 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 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. a mechanism for the delegate to update the CSP as change occurs.
4.2.2. Management of Service Data 4.2.2. Management of Service Data
Service data is data required by an originating or intermediate CSP Service data is data required by an originating or intermediate CSP
to enable communications service to a User: a SIP URI is an example to enable communication service to a User; a SIP URI is an example of
of one service data element commonly used to route communications. one service data element commonly used to route communication. CSPs
CSPs typically create and manage service data, however, it is typically create and manage service data, however, it is possible
possible that delegates and Users could as well. For most use cases that delegates and Users could as well. For most use cases involving
involving individual Users, it is anticipated that lower-level individual Users, it is anticipated that lower-level service
service information changes (such as an end-user device receiving a information changes (such as an end-user device receiving a new IP
new IP address) would be communicated to CSPs via existing protocols. address) would be communicated to CSPs via existing protocols. For
For example, the baseline SIP REGISTER [2] method, even for bulk example, the baseline SIP REGISTER [RFC3261] method, even for bulk
operations [13], would likely be used rather than through any new operations [RFC6140], would likely be used rather than through any
interfaces defined by MODERN. new interfaces defined by MODERN.
4.2.2.1. CSP to other CSPs 4.2.2.1. CSP to Other CSPs
After a User enrolls for service with a CSP, in the case where the 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 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 service address such as a SIP URI and associate it with the TN. The
CSP needs to update this data to enable service interoperability. CSP needs to update this data to enable service interoperability.
There are multiple ways that this update can occur, though most There are multiple ways that this update can occur, though most
commonly service data is exposed through the retrieval interface (see commonly service data is exposed through the retrieval interface (see
Section 4.3). For certain deployment architectures, like a Section 4.3). For certain deployment architectures, like a
distributed data store model, CSPs may need to provision data distributed data store model, CSPs may need to provision data
directly to other CSPs. directly to other CSPs.
If the CSP is assigning a TN from its own inventory it may not need 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 to perform service data updates as change occurs because the existing
service data associated with inventory may be sufficient once the TN service data associated with inventory may be sufficient once the TN
is put in service. They would however likely update the Registry on is put in service. They would, however, likely update the Registry
the change in status. on the change in status.
4.2.2.2. User to CSP 4.2.2.2. User to CSP
Users could also associate service data to their TNs at the CSP. An Users could also associate service data to their TNs at the CSP. An
example is a User acquires a TN from the Registrar (as described in example would be a User acquiring a TN from the Registrar (as
Section 4.1.1) and wants to provide that TN to the CSP so the CSP can described in Section 4.1.1) and wanting to provide that TN to the CSP
enable service. In this case, once the user provides the number to so the CSP can enable service. In this case, once the User provides
the CSP, the CSP would update the Registry or other actors as the number to the CSP, the CSP would update the Registry or other
outlined in Section 4.2.2.1. actors as outlined in Section 4.2.2.1.
4.2.3. Managing Change 4.2.3. Managing Change
This section will address some special management use cases that were This section will address some special management use cases that were
not covered above. not covered above.
4.2.3.1. Changing the CSP for an Existing Service 4.2.3.1. Changing the CSP for an Existing Service
Consider the case where a User who subscribes to a communications Consider the case where a User who subscribes to a communication
service, and received their TN from that CSP, wishes to retain the service (and who received their TN from that CSP) wishes to retain
same TN but move their service to a different CSP. the same TN but move their service to a different CSP.
In the simplest scenario, where there's an authoritative combined In the simplest scenario, where there's an authoritative combined
Registry/Registrar that maintains service data, the User could Registry/Registrar that maintains service data, the User could
provide their credential to the new CSP and let the CSP initiate the 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 change in service. The new CSP could then provide the new service
data with the User's credential to the Registry/Registrar, which then 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 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 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 the old CSP so they can disable service. The old CSP will undo any
delegations to the User, including contacting the Credential delegations to the User, including contacting the Credential
Authority to revoke any cryptographic credentials (e.g., STIR Authority to revoke any cryptographic credentials (e.g., STIR
certificates [17]) previously granted to the User. Any service data certificates [RFC8226]) previously granted to the User. Any service
maintained by the CSP must be removed, and similarly, the CSP must data maintained by the CSP must be removed, and, similarly, the CSP
delete any such information it provisioned in the Registry. must delete any such information it provisioned in the Registry.
In a model similar to common practice in environments today, the User In a model similar to common practice in environments today, the User
could alternatively provide their credential to the old CSP, and the could alternatively provide their credential to the old CSP, and the
old CSP initiates the change in service. Or, a User could go old CSP would initiate the change in service. Or, a User could go
directly to a Registrar to initiate a port. This framework should directly to a Registrar to initiate a port. This framework should
support all of these potential flows. support all of these potential flows.
Note that in cases with a distributed Registry that maintained Note that in cases with a distributed Registry that maintained
service data, the Registry would also have to update the other service data, the Registry would also have to update the other
Registries of the change. Registries of the change.
4.2.3.2. Terminating a Service 4.2.3.2. Terminating a Service
Consider a case where a user who subscribes to a communications Consider a case where a User who subscribes to a communication
service, and received their TN from the CSP, wishes to terminate service (and who received their TN from the CSP) wishes to terminate
their service. At this time, the CSP will undo any delegations to their service. At this time, the CSP will undo any delegations to
the User, which may involve contacting the Credential Authority to the User, which may involve contacting the Credential Authority to
revoke any cryptographic credentials (e.g., STIR certificates [17]) revoke any cryptographic credentials (e.g., STIR certificates
previously granted to the User. Any service data maintained by the [RFC8226]) previously granted to the User. Any service data
CSP must be removed, and similarly, the CSP must delete any such maintained by the CSP must be removed, and similarly, the CSP must
information it provisioned in the Registrar. However, per the policy delete any such information it provisioned in the Registrar.
of the Numbering Authority, Registrars and CSPs may be required to However, per the policy of the Numbering Authority, Registrars and
preserve historical data that will be accessible to Government CSPs may be required to preserve historical data that will be
Entities or others through audits, even if it is no longer accessible to Government Entities or others through audits, even if
retrievable through service interfaces. it is no longer retrievable through service interfaces.
The TN will change state from assigned to unassigned, the CSP will The TN will change state from assigned to unassigned, and the CSP
update the Registry. Depending on policies the TN could go back into will update the Registry. Depending on policies, the TN could go
the Registry, CSP, or delegate's pool of available TNs and would back into the Registry, CSP, or delegate's pool of available TNs and
likely enter an ageing process. would likely enter an aging process.
In an alternative use case, a User who received their own TN In an alternative use case, a User who received their own TN
assignment directly from a Registrar terminates their service with a assignment directly from a Registrar terminates their service with a
CSP. At this time, the User might terminate their assignment from CSP. At this time, the User might terminate their assignment from
the Registrar, and return the TN to the Registry for re-assignment. the Registrar and return the TN to the Registry for reassignment.
Alternatively, they could retain the TN and elect to assign it to Alternatively, they could retain the TN and elect to assign it to
some other service at a later time. some other service at a later time.
4.3. Retrieval 4.3. Retrieval
Retrieval of administrative or service data will be subject to access Retrieval of administrative or service data will be subject to access
restrictions based on the category of the specific data: public, restrictions based on the category of the specific data: public,
semi-restricted or restricted. Both administrative and service data semi-restricted, or restricted. Both administrative and service data
can have data elements that fall into each of these categories. It can have data elements that fall into each of these categories. It
is expected that the majority of administrative will fall into the is expected that the majority of administrative data will fall into
semi-restricted category: access to this information may require some the semi-restricted category: access to this information may require
form of authorization, though service data crucial to reachability some form of authorization, though service data crucial to
will need to be accessible. In some environments, it's possible that reachability will need to be accessible. In some environments, it's
none of the service data necessary to initiate communications will be possible that none of the service data necessary to initiate
useful to an entity on the public Internet, say, or that all that communication will be useful to an entity on the public Internet, or
service data will have dependencies on the origination point of that all that service data will have dependencies on the origination
calls. point for calls.
The retrieval protocol mechanism for semi-restricted and restricted The retrieval protocol mechanism for semi-restricted and restricted
data needs a way for the receiver of the request to identify the data needs a way for the receiver of the request to identify the
originator of the request and what is being requested. The receiver originator of the request and what is being requested. The receiver
of the request will process that request based on this information. of the request will process that request based on this information.
4.3.1. Retrieval of Public Data 4.3.1. Retrieval of Public Data
Either administrative or service data may be made publicly available Either administrative or service data may be made publicly available
by the authority that generates and provisions it. Under most by the authority that generates and provisions it. Under most
circumstances, a CSP wants its communications service to be publicly circumstances, a CSP wants its communication service to be publicly
reachable through TNs, so the retrieval interface supports public reachable through TNs, so the retrieval interface supports public
interfaces that permit clients to query for service data about a TN. interfaces that permit clients to query for service data about a TN.
Some service data may however require that the client be authorized Some service data may, however, require that the client be authorized
to receive it, per the use case in Section 4.3.3 below. to receive it, per the use case in Section 4.3.3.
Public data can simply be posted on websites or made available Public data can simply be posted on websites or made available
through a publicly available API. Public data hosted by a CSP may through a publicly available API. Public data hosted by a CSP may
have a reference address at the Registry. have a reference address at the Registry.
4.3.2. Retrieval of Semi-restricted Administrative Data 4.3.2. Retrieval of Semi-restricted Administrative Data
Consider a case in which a CSP is having service problems completing 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 calls to a specific TN, so it wants to contact the CSP serving that
TN. The Registry authorizes the originating CSP to access this TN. The Registry authorizes the originating CSP to access this
information. It initiates a query to the Registry, the Registry information. It initiates a query to the Registry, the Registry
verifies the requestor and the requested data and Registry responds verifies the requestor and the requested data, and the Registry
with the serving CSP and contact data. However, CSPs might not want responds with the serving CSP and contact data. However, CSPs might
to make those administrative contact points public data: they are not want to make those administrative contact points public data:
willing to share them with other CSPs for troubleshooting purposes, they are willing to share them with other CSPs for troubleshooting
but not to make them available to general communication. purposes, but not to make them available to general communication.
Alternatively that information could be part of a distributed data Alternatively, that information could be part of a distributed data
store and not stored at a monolithic Registry. In that case, the CSP 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 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 query to the local data store. The local data store responds with
the CSP and contact data. No verification is necessary because it the CSP and contact data. No verification is necessary because it
was done when the CSP was authorized to receive the data store. was done when the CSP was authorized to receive the data store.
4.3.3. Retrieval of Semi-restricted Service Data 4.3.3. Retrieval of Semi-restricted Service Data
Consider a case where a User on a CSP's network calls a TN. The 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 initiates a query for service data associated with the TN to complete
the call, and will receive special service data because the CSP the call and will receive special service data because the CSP
operates in a closed environment where different CSPs receive operates in a closed environment where different CSPs receive
different responses, and only participating CSPs can initiate different responses, and only participating CSPs can initiate
communications. This service data would be flagged as semi- communication. This service data would be flagged as semi-
restricted. The query and response have real-time performance restricted. The query and response have real-time performance
requirements in that environment. requirements in that environment.
Semi-restricted service data also works in a distributed data store Semi-restricted service data also works in a distributed data store
model, where each CSP distributes its updated service data to all model where each CSP distributes its updated service data to all
other CSPs. The originating CSP has the service data in its local other CSPs. The originating CSP has the service data in its local
data store and queries it. The local data store responds with the data store and queries it. The local data store responds with the
service data. The service data in the response can be a reference 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 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 the service address itself. In the case where the response gives a
reference address, a subsequent query would go to the serving CSP, reference address, a subsequent query would go to the serving CSP,
who would in turn authorize the requestor for the requested data and who would, in turn, authorize the requestor for the requested data
respond appropriate. In the case where the original response and respond appropriately. In the case, where the original response
contains the service address, the requestor would use that service contains the service address, the requestor would use that service
address as the destination for the call. address as the destination for the call.
In some environments, aspects of the service data may reside at the In some environments, aspects of the service data may reside at the
Registry itself (for example, the assigned CSP for a TN), and thus Registry itself (for example, the assigned CSP for a TN); thus, the
the query may be sent to the Registry. The Registry verifies the query may be sent to the Registry. The Registry verifies the
requestor and the requested data and responds with the service data, requestor and the requested data and responds with the service data,
such as a SIP URI containing the domain of the assigned CSP. such as a SIP URI containing the domain of the assigned CSP.
4.3.4. Retrieval of Restricted Data 4.3.4. Retrieval of Restricted Data
A Government Entity wishes to access information about a particular A Government Entity wishes to access information about a particular
User, who subscribes to a communications service. The entity that User who subscribes to a communication service. The entity that
operates the Registry on behalf of the Numbering Authority in this operates the Registry on behalf of the Numbering Authority in this
case has some pre-defined relationship with the Government Entity. case has some predefined relationship with the Government Entity.
When the CSP acquired TNs from the Numbering Authority, it was a When the CSP acquired TNs from the Numbering Authority, it was a
condition of that assignment that the CSP provide access for condition of that assignment that the CSP provide access for
Government Entities to telephone numbering data when certain Government Entities to telephone numbering data when certain
conditions apply. The required data may reside either in the CSP or conditions apply. The required data may reside either in the CSP or
in the Registrar. in the Registrar.
For a case where the CSP delegates a number to the User, the 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 might provision the Registrar (or itself, if the CSP is composed with
a Registrar) with information relevant to the User. At such a time a Registrar) with information relevant to the User. At such a time
as the Government Entity needs information about that User, the as the Government Entity needs information about that User, the
Government Entity may contact the Registrar or CSP to acquire the Government Entity may contact the Registrar or CSP to acquire the
necessary data. The interfaces necessary for this will be the same necessary data. The interfaces necessary for this will be the same
as those described in Section 4.3; the Government Entity will be as those described in Section 4.3; the Government Entity will be
authenticated, and an authorization decision will be made by the authenticated and an authorization decision will be made by the
Registrar or CSP under the policy dictates established by the Registrar or CSP under the policy dictates established by the
Numbering Authority. Numbering Authority.
5. Acknowledgments 5. IANA Considerations
We would like to thank Henning Schulzrinne and Adam Roach for their
contributions to this problem statement and framework, and to thank
Pierce Gorman for detailed comments.
6. IANA Considerations
This memo includes no instructions for the IANA. This document has no IANA actions.
7. Privacy Considerations 6. Privacy Considerations
This framework defines two categories of information about telephone This framework defines two categories of information about telephone
numbers: service data and administrative data. Service data numbers: service data and administrative data. Service data
describes how telephone numbers map to particular services and describes how telephone numbers map to particular services and
devices that provide real-time communication for users. As such, devices that provide real-time communication for users. As such,
service data could potentially leak resource locations and even service data could potentially leak resource locations and even
lower-layer network addresses associated with these services, and in lower-layer network addresses associated with these services, and in
rare cases, with end-user devices. Administrative data more broadly rare cases, with end-user devices. Administrative data more broadly
characterizes who the administrative entities are behind telephone characterizes who the administrative entities are behind telephone
numbers, which will often identify CSPs, but in some layers of the numbers, which will often identify CSPs but some layers of the
architecture could include personally identifying information (PII), architecture could include Personally Identifiable Information (PII),
even WHOIS-style information, about the end users behind identifiers. even WHOIS-style information, about the end users behind identifiers.
This could conceivably encompass the sorts of data that carriers and This could conceivably encompass the sorts of data that carriers and
similar CSPs today keep about their customers for billing purposes, similar CSPs today keep about their customers for billing purposes,
like real names and postal addresses. The exact nature of like real names and postal addresses. The exact nature of
administrative data is not defined by this framework, and it is administrative data is not defined by this framework, and it is
anticipated that the protocols that will perform this function will anticipated that the protocols that will perform this function will
be extensible for different use cases, so at this point, it is be extensible for different use cases, so at this point, it is
difficult to characterize exactly how much PII might end up being difficult to characterize exactly how much PII might end up being
housed by these services. housed by these services.
As such, if an attacker were to compromise the registrar services in As such, if an attacker were to compromise the registrar services
this architecture which maintain administrative data, and in some that maintains administrative data in this architecture, and in some
cases even service data, this could leak PII about end users. These cases even service data, this could leak PII about end users. These
interfaces, and the systems that host them, are a potentially interfaces, and the systems that host them, are a potentially
attractive target for hackers and need to be hardened accordingly. attractive target for hackers and need to be hardened accordingly.
Protocols that are selected to fulfill these functions must provide Protocols that are selected to fulfill these functions must provide
the security features described in [Sec Cons]. the security features described in Section 7.
Finally, this framework recognizes that in many jurisdictions, Finally, this framework recognizes that, in many jurisdictions,
certain government agencies have a legal right to access service and certain government agencies have a legal right to access service and
administrative data maintained by CSPs. This access is typically administrative data maintained by CSPs. This access is typically
aimed at identifying the users behind communications identifiers in aimed at identifying the users behind the communication identifier in
order to enforce regulatory policy. Those legal entities already order to enforce regulatory policy. Those legal entities already
have the power to access the existing data held by CSPs in many have the power to access the existing data held by CSPs in many
jurisdictions, though potentially the administrative data associated jurisdictions, though, potentially, the administrative data
with this framework could be richer information. associated with this framework could be richer information.
8. Security Considerations 7. Security Considerations
The acquisition, management, and retrieval of administrative and The acquisition, management, and retrieval of administrative and
service data associated with telephone numbers raises a number of service data associated with telephone numbers raises a number of
security issues. security issues.
Any mechanism that allows an individual or organization to acquire Any mechanism that allows an individual or organization to acquire
telephone numbers will require a means of mutual authentication, of telephone numbers will require a means of mutual authentication, of
integrity protection, and of confidentiality. A Registry as defined integrity protection, and of confidentiality. A Registry as defined
in this document will surely want to authenticate the source of an in this document will surely want to authenticate the source of an
acquisition request as a first step in the authorization process to acquisition request as a first step in the authorization process to
skipping to change at page 21, line 25 skipping to change at page 21, line 31
personally identifying information associated with the administrative personally identifying information associated with the administrative
or technical contracts for allocations. or technical contracts for allocations.
A management interface for telephone numbers has similar A management interface for telephone numbers has similar
requirements. Without proper authentication and authorization requirements. Without proper authentication and authorization
mechanisms in place, an attack could use the management interface to mechanisms in place, an attack could use the management interface to
disrupt service data or administrative data, which could deny service disrupt service data or administrative data, which could deny service
to users, enable new impersonation attacks, prevent billing systems to users, enable new impersonation attacks, prevent billing systems
from operating properly, and cause similar system failures. from operating properly, and cause similar system failures.
Finally, a retrieval interfaces has its own needs for mutual Finally, a retrieval interface has its own needs for mutual
authentication, integrity protection, and for confidentiality. Any authentication, integrity protection, and confidentiality. Any CSP
CSP sending a request to retrieve service data associated with a sending a request to retrieve service data associated with a number
number will want to know that it is reaching the proper authority, will want to know that it is reaching the proper authority, that the
that the response from that authority has not been tampered with in response from that authority has not been tampered with in transit,
transit, and in most cases the CSP will not want to reveal to and, in most cases, the CSP will not want to reveal to eavesdroppers
eavesdroppers the number it is requesting or the response that it has the number it is requesting or the response that it has received.
received. Similarly, any service answering such a query will want to Similarly, any service answering such a query will want to have a
have a means of authenticating the source of the query, and of means of authenticating the source of the query and of protecting the
protecting the integrity and confidentiality of its responses. integrity and confidentiality of its responses.
9. Informative References 8. Informative References
[1] Peterson, J. and C. Jennings, "Enhancements for [DRIP] Wendt, C. and H. Bellur, "Distributed Registry Protocol
Authenticated Identity Management in the Session (DRiP)", Work in Progress, draft-wendt-modern-drip-02,
Initiation Protocol (SIP)", RFC 4474, July 2017.
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[3] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to [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 Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116, Discovery System (DDDS) Application (ENUM)", RFC 6116,
DOI 10.17487/RFC6116, March 2011, DOI 10.17487/RFC6116, March 2011,
<https://www.rfc-editor.org/info/rfc6116>. <https://www.rfc-editor.org/info/rfc6116>.
[4] Channabasappa, S., Ed., "Data for Reachability of Inter- [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 /Intra-NetworK SIP (DRINKS) Use Cases and Protocol
Requirements", RFC 6461, DOI 10.17487/RFC6461, January Requirements", RFC 6461, DOI 10.17487/RFC6461, January
2012, <https://www.rfc-editor.org/info/rfc6461>. 2012, <https://www.rfc-editor.org/info/rfc6461>.
[5] Watson, M., "Short Term Requirements for Network Asserted [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access
Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
<https://www.rfc-editor.org/info/rfc3324>.
[6] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>.
[7] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <https://www.rfc-editor.org/info/rfc6698>.
[8] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
2007, <https://www.rfc-editor.org/info/rfc4916>.
[9] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<https://www.rfc-editor.org/info/rfc3966>.
[10] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
January 2008, <https://www.rfc-editor.org/info/rfc5039>.
[11] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67,
RFC 5727, DOI 10.17487/RFC5727, March 2010,
<https://www.rfc-editor.org/info/rfc5727>.
[12] Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol (RDAP) Query Format", RFC 7482, Protocol (RDAP) Query Format", RFC 7482,
DOI 10.17487/RFC7482, March 2015, DOI 10.17487/RFC7482, March 2015,
<https://www.rfc-editor.org/info/rfc7482>. <https://www.rfc-editor.org/info/rfc7482>.
[13] Roach, A., "Registration for Multiple Phone Numbers in the [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Session Initiation Protocol (SIP)", RFC 6140,
DOI 10.17487/RFC6140, March 2011,
<https://www.rfc-editor.org/info/rfc6140>.
[14] Hollenbeck, S., "Generic Registry-Registrar Protocol
Requirements", RFC 3375, DOI 10.17487/RFC3375, September
2002, <https://www.rfc-editor.org/info/rfc3375>.
[15] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>.
[16] Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-03 (work in progress), July 2017.
[17] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
[18] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- [TERI-INFO]
Huguenin, "Verification Involving PSTN Reachability: Peterson, J., "An Architecture and Information Model for
Requirements and Architecture Overview", draft-jennings- Telephone-Related Information (TeRI)", Work in Progress,
vipr-overview-06 (work in progress), December 2013. draft-peterson-modern-teri-04, March 2018.
[19] Wendt, C. and H. Bellur, "Distributed Registry Protocol Acknowledgments
(DRiP)", draft-wendt-modern-drip-02 (work in progress),
July 2017.
[20] Rosenberg, J. and H. Schulzrinne, "Session Initiation We would like to thank Henning Schulzrinne and Adam Roach for their
Protocol (SIP): Locating SIP Servers", RFC 3263, contributions to this problem statement and framework; we would also
DOI 10.17487/RFC3263, June 2002, like to thank Pierce Gorman for detailed comments.
<https://www.rfc-editor.org/info/rfc3263>.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US United States of America
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
Tom McGarry Tom McGarry
Neustar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: tom.mcgarry@neustar.biz Email: tmcgarry6@gmail.com
 End of changes. 142 change blocks. 
458 lines changed or deleted 411 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/