<pre>Internet Engineering Task Force (IETF)                       J. Peterson
Request for Comments: 8396                                 NeuStar, Inc.
Category: Informational                                       T. McGarry
ISSN: 2070-1721                                                July 2018


 <span class="h1">Managing, Ordering, Distributing, Exposing, and Registering Telephone</span>
     <span class="h1">Numbers (MODERN): Problem Statement, Use Cases, and Framework</span>

Abstract

   The functions of the Public Switched Telephone Network (PSTN) are
   rapidly migrating to the Internet.  This is generating new
   requirements for many traditional elements of the PSTN, including
   Telephone Numbers (TNs).  TNs no longer serve simply as telephone
   routing addresses: they are now identifiers that may be used by
   Internet-based services for a variety of purposes including session
   establishment, identity verification, and service enablement.  This
   problem statement examines how the existing tools for allocating and
   managing telephone numbers do not align with the use cases of the
   Internet environment and proposes a framework for Internet-based
   services relying on TNs.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see <a href="./rfc7841#section-2">Section&nbsp;2 of RFC 7841</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc8396">https://www.rfc-editor.org/info/rfc8396</a>.













<span class="grey">Peterson &amp; McGarry            Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   <a href="#section-1">1</a>.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-3">3</a>
   <a href="#section-2">2</a>.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-2.1">2.1</a>.  Actors  . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-5">5</a>
     <a href="#section-2.2">2.2</a>.  Data Types  . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-7">7</a>
     <a href="#section-2.3">2.3</a>.  Data Management Architectures . . . . . . . . . . . . . .   <a href="#page-8">8</a>
   <a href="#section-3">3</a>.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   <a href="#page-9">9</a>
   <a href="#section-4">4</a>.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
     <a href="#section-4.1">4.1</a>.  Acquisition . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-11">11</a>
       <a href="#section-4.1.1">4.1.1</a>.  Acquiring TNs from Registrar  . . . . . . . . . . . .  <a href="#page-12">12</a>
       <a href="#section-4.1.2">4.1.2</a>.  Acquiring TNs from CSPs . . . . . . . . . . . . . . .  <a href="#page-13">13</a>
     <a href="#section-4.2">4.2</a>.  Management  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-14">14</a>
       <a href="#section-4.2.1">4.2.1</a>.  Management of Administrative Data . . . . . . . . . .  <a href="#page-14">14</a>
         <a href="#section-4.2.1.1">4.2.1.1</a>.  Managing Data at a Registrar  . . . . . . . . . .  <a href="#page-14">14</a>
         <a href="#section-4.2.1.2">4.2.1.2</a>.  Managing Data at a CSP  . . . . . . . . . . . . .  <a href="#page-15">15</a>
       <a href="#section-4.2.2">4.2.2</a>.  Management of Service Data  . . . . . . . . . . . . .  <a href="#page-15">15</a>
         <a href="#section-4.2.2.1">4.2.2.1</a>.  CSP to Other CSPs . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
         <a href="#section-4.2.2.2">4.2.2.2</a>.  User to CSP . . . . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
       <a href="#section-4.2.3">4.2.3</a>.  Managing Change . . . . . . . . . . . . . . . . . . .  <a href="#page-16">16</a>
         <a href="#section-4.2.3.1">4.2.3.1</a>.  Changing the CSP for an Existing Service  . . . .  <a href="#page-16">16</a>
         <a href="#section-4.2.3.2">4.2.3.2</a>.  Terminating a Service . . . . . . . . . . . . . .  <a href="#page-17">17</a>
     <a href="#section-4.3">4.3</a>.  Retrieval . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-17">17</a>
       <a href="#section-4.3.1">4.3.1</a>.  Retrieval of Public Data  . . . . . . . . . . . . . .  <a href="#page-18">18</a>
       <a href="#section-4.3.2">4.3.2</a>.  Retrieval of Semi-restricted Administrative Data  . .  <a href="#page-18">18</a>
       <a href="#section-4.3.3">4.3.3</a>.  Retrieval of Semi-restricted Service Data . . . . . .  <a href="#page-19">19</a>
       <a href="#section-4.3.4">4.3.4</a>.  Retrieval of Restricted Data  . . . . . . . . . . . .  <a href="#page-19">19</a>
   <a href="#section-5">5</a>.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  <a href="#page-20">20</a>
   <a href="#section-6">6</a>.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  <a href="#page-20">20</a>
   <a href="#section-7">7</a>.  Security Considerations . . . . . . . . . . . . . . . . . . .  <a href="#page-21">21</a>
   <a href="#section-8">8</a>.  Informative References  . . . . . . . . . . . . . . . . . . .  <a href="#page-21">21</a>
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-22">22</a>
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-22">22</a>



<span class="grey">Peterson &amp; McGarry            Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Problem Statement</span>

   The challenges of utilizing Telephone Numbers (TNs) on the Internet
   have been known for some time.  Internet telephony provided the first
   use case for routing telephone numbers on the Internet in a manner
   similar to how calls are routed in the Public Switched Telephone
   Network (PSTN).  As the Internet had no service for discovering the
   endpoints associated with telephone numbers, ENUM [<a href="./rfc6116" title="&quot;The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)&quot;">RFC6116</a>] created a
   DNS-based mechanism for translating TNs into URIs, as used by
   protocols such as SIP [<a href="./rfc3261" title="&quot;SIP: Session Initiation Protocol&quot;">RFC3261</a>].  The resulting database was designed
   to function in a manner similar to the systems that route calls in
   the PSTN.  Originally, it was envisioned that ENUM would be deployed
   as a global hierarchical service; however, in practice, it has only
   been deployed piecemeal by various parties.  Most notably, ENUM is
   used as an internal network function and is rarely used between
   service provider networks.  The original ENUM concept of a single
   root, e164.arpa, proved to be politically and practically
   challenging, and less centralized models have thus flourished.
   Subsequently, the Data for Reachability of Inter-/Intra-NetworK SIP
   (DRINKS) framework [<a href="./rfc6461" title="&quot;Data for Reachability of Inter- /Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements&quot;">RFC6461</a>] showed ways that service providers might
   provision information about TNs at an ENUM service or similar
   Internet-based directory.  These technologies have also generally
   tried to preserve the features and architecture familiar to the PSTN
   numbering environment.

   Over time, Internet telephony has encompassed functions that differ
   substantially from traditional PSTN routing and management,
   especially as non-traditional providers have begun to utilize
   numbering resources.  An increasing number of enterprises, over-the-
   top Voice over IP (VoIP) providers, text messaging services, and
   related non-carrier services have become heavy users of telephone
   numbers.  An enterprise, for example, can deploy an IP Private Branch
   Exchange (PBX) that receives a block of telephone numbers from a
   carrier and then, in turn, distributes those numbers to new IP
   telephones when they associate with the PBX.  Internet services offer
   users portals where they can allocate new telephone numbers on the
   fly, assign multiple "alias" telephone numbers to a single line
   service, implement various mobility or find-me-follow-me
   applications, and so on.  Peer-to-peer telephone networks have
   encouraged experiments with distributed databases for telephone
   number routing and even allocation.

   This dynamic control over telephone numbers has few precedents in the
   traditional PSTN outside of number portability.  Number portability
   allows the capability of a user to choose and change their service
   provider while retaining their TN; it has been implemented in many
   countries either for all telephony services or for subsets (e.g.,
   mobile).  However, TN administration processes rooted in PSTN



<span class="grey">Peterson &amp; McGarry            Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   technology and policies made number porting fraught with problems and
   delays.  Originally, processes were built to associate a specific TN
   to a specific service provider and never change it.  With number
   portability, the industry had to build new infrastructure and new
   administrative functions and processes to change the association of
   the TN from one service provider to another.  Thanks to the
   increasing sophistication of consumer mobile devices as Internet
   endpoints as well as telephones, users now associate TNs with many
   Internet applications other than telephony.  This has generated new
   interest in models similar to those in place for administering
   freephone (non-geographic, toll-free numbers) services in the United
   States, where a user purchases a number through a sort of number
   registrar and controls its administration (such as routing) on their
   own, typically using Internet services to directly make changes to
   the service associated with telephone numbers.

   Most TNs today are assigned to specific geographies, at both an
   international level and within national numbering plans.  Numbering
   practices today are tightly coupled with the manner that service
   providers interconnect as well as with how TNs are routed and
   administered: the PSTN was carefully designed to delegate switching
   intelligence geographically.  In interexchange carrier routing in
   North America, for example, calls to a particular TN are often handed
   off to the terminating service provider close to the geography where
   that TN is assigned.  But the overwhelming success of mobile
   telephones has increasingly eroded the connection between numbers and
   regions.  Furthermore, the topology of IP networks is not anchored to
   geography in the same way that the telephone network is.  In an
   Internet environment, establishing a network architecture for routing
   TNs could depend little on geography, relying instead on network
   topologies or other architectural features.  Adapting TNs to the
   Internet requires more security, richer datasets, and more complex
   query and response capabilities than previous efforts have provided.

   This document attempts to create a common understanding of the
   problem statement related to allocating, managing, and resolving TNs
   in an IP environment, which is the focus of the IETF Managing,
   Ordering, Distributing, Exposing, and Registering telephone Numbers
   (MODERN) Working Group.  It outlines a framework and lists motivating
   use cases for creating IP-based mechanisms for TNs.  It is important
   to acknowledge at the outset that there are various evolving
   international and national policies and processes related to TNs, and
   any solutions need to be flexible enough to account for variations in
   policy and requirements.







<span class="grey">Peterson &amp; McGarry            Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Definitions</span>

   This section provides definitions for actors, data types, and data
   management architectures as they are discussed in this document.
   Different numbering spaces may instantiate these roles and concepts
   differently: practices that apply to non-geographic freephone
   numbers, for example, may not apply to geographic numbers, and
   practices that exist under one Numbering Authority may not be
   permitted under another.  The purpose of this framework is to
   identify the characteristics of protocol tools that will satisfy the
   diverse requirements for telephone number acquisition, management,
   and retrieval on the Internet.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Actors</span>

   The following roles of actors are defined in this document.

   Numbering Authority:  A regulatory body within a region that manages
      that region's TNs.  The Numbering Authority decides national
      numbering policy for the nation, region, or other domain for which
      it has authority, including what TNs can be allocated, which are
      reserved, and which entities may obtain TNs.

   Registry:  An entity that administers the allocation of TNs based on
      a Numbering Authority's policies.  Numbering Authorities can act
      as the Registries themselves, or they can outsource the function
      to other entities.  Traditional registries are single entities
      with sole authority and responsibility for specific numbering
      resources, though distributed registries (see <a href="#section-2.3">Section 2.3</a>) are
      also in the scope of this framework.

   Credential Authority:  An entity that distributes credentials, such
      as certificates that attest the authority of assignees (defined
      below) and delegates.  This document assumes that one or more
      Credential Authorities may be trusted by actors in any given
      regulatory environment; policies for establishing such trust
      anchors are outside the scope of this document.

   Registrar:  An entity that distributes the telephone numbers
      administered by a Registry; typically, there are many Registrars
      that can distribute numbers from a single Registry, though
      Registrars may serve multiple Registries as well.  A Registrar has
      business relationships with number assignees and collects
      administrative information from them.

   Communication Service Provider (CSP):  A provider of communication
      service where those services can be identified by TNs.  This
      includes both traditional telephone carriers or enterprises as



<span class="grey">Peterson &amp; McGarry            Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


      well as service providers with no presence on the PSTN who use
      TNs.  This framework does not assume that any single CSP provides
      all the communication service related to a particular TN.

   Service Enabler:  An entity that works with CSPs to enable
      communication service to a User: perhaps a vendor, a service
      bureau, or a third-party integrator.

   User:  An individual reachable through a communication service:
      usually a customer of a Communication Service Provider.

   Government Entity:  An entity that, due to legal powers deriving from
      national policy, has privileged access to information about number
      administration under certain conditions.

   Note that an individual, organization, or other entity may act in one
   or more of the roles above; for example, a company may be a CSP and
   also a Registrar.  Although Numbering Authorities are listed as
   actors, they are unlikely to actually participate in the protocol
   flows themselves; however, in some situations, a Numbering Authority
   and Registry may be the same administrative entity.

   All actors that are recipients of numbering resources, be they a CSP,
   Service Enabler, or User, can also be said to have a relationship to
   a Registry of either an assignee or delegate.

   Assignee:  An actor that is assigned a TN directly by a Registrar; an
      assignee always has a direct relationship with a Registrar.

   Delegate:  An actor that is delegated a TN from an assignee or
      another delegate who does not necessarily have a direct
      relationship with a Registrar.  Delegates may delegate one or more
      of their TN assignment(s) to one or more subdelegates from further
      downstream.

   As an example, consider a case where a Numbering Authority also acts
   as a Registry, and it issues blocks of 10,000 TNs to CSPs that, in
   this case, also act as Registrars.  CSP/Registrars would then be
   responsible for distributing numbering resources to Users and other
   CSPs.  In this case, an enterprise deploying IP PBXs also acts as a
   CSP, and it acquires number blocks for its enterprise seats in chunks
   of 100 from a CSP acting as a Registrar with whom the enterprise has
   a business relationship.  The enterprise is, in this case, the
   assignee, as it receives numbering resources directly from a
   Registrar.  As it doles out individual numbers to its Users, the
   enterprise delegates its own numbering resources to those Users and
   their communication endpoints.  The overall ecosystem might look as
   follows.



<span class="grey">Peterson &amp; McGarry            Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


                 +---------+
                 |Numbering|
                 |Authority|Registry
                 +----+----+
                      |
                      V 10,000 TNs
                 +---------+
                 |   CSP   |Registrar
                 +----+----+
                      |
                      V  100 TNs
                 +---------+
                 |   PBX   |Assignee
                 +---------+
                      |
                      V    1 TN
                 +---------+
                 |  User   |Delegate
                 +---------+

                   Figure 1: Chain of Number Assignment

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Data Types</span>

   The following data types are defined in this document.

   Administrative Data:  Assignment data related to the TN and the
      relevant actors; it includes TN status (assigned, unassigned,
      etc.), contact data for the assignee or delegate, and typically
      does not require real-time access as this data is not required for
      ordinary call or session establishment.

   Service Data:  Data necessary to enable service for the TN; it
      includes addressing data and service features.  Since this data is
      necessary to complete calls, it must be obtained in real time.

   Administrative and service data can fit into three access categories:

   Public:  Anyone can access public data.  Such data might include a
      list of which numbering resources (unallocated number ranges) are
      available for acquisition from the Registry.

   Semi-restricted:  Only a subset of actors can access semi-restricted
      data.  For example, CSPs may be able to access other CSP's service
      data in some closed environment.






<span class="grey">Peterson &amp; McGarry            Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   Restricted:  Only a small subset of actors can access restricted
      data.  For example, a Government Entity may be able access contact
      information for a User.

   While it might appear there are really only two categories, public
   and restricted (based on the requestor), the distinction between
   semi-restricted and restricted is helpful for the use cases below.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Data Management Architectures</span>

   This framework generally assumes that administrative and service data
   is maintained by CSPs, Registrars, and Registries.  The terms
   "registrar" and "registry" are familiar from DNS operations, and
   indeed the DNS provides an obvious inspiration for the relationships
   between those entities described here.  Protocols for transferring
   names between registries and registrars have been standardized in the
   DNS space for some time (see [<a href="./rfc3375" title="&quot;Generic Registry-Registrar Protocol Requirements&quot;">RFC3375</a>]).  Similarly, the division
   between service data acquired by resolving names with the DNS
   protocol versus administrative data about names acquired through
   WHOIS [<a href="./rfc3912" title="&quot;WHOIS Protocol Specification&quot;">RFC3912</a>] is directly analogous to the distinction between
   service and administrative data described in <a href="#section-2.2">Section 2.2</a>.  The major
   difference between the data management architecture of the DNS and
   this framework is that the distinction between the CSP and User, due
   to historical policies of the telephone network, will often not
   exactly correspond to the distinction between a name service and a
   registrant in the DNS world -- a User in the telephone network is
   today at least rarely in a direct relationship with a Registrar
   comparable to that of a DNS registrant.

   The role of a Registry described here is a "thin" one, where the
   Registry manages basic allocation information for the numbering
   space, such as information about whether or not the number is
   assigned, and if assigned, by which Registrar.  It is the Registrar
   that, in turn, manages detailed administrative data about those
   assignments, such as contact or billing information for the assignee.
   In some models, CSPs and Registrars will be combined (the same
   administrative entity), and in others the Registry and Registrar may
   similarly be composed.  Typically, service data resides largely at
   the CSP itself, though in some models a "thicker" Registry may itself
   contain a pointer to the servicing CSP for a number or number block.
   In addition to traditional centralized Registries, this framework
   also supports environments where the same data is being managed by
   multiple administrative entities and stored in many locations.  A








<span class="grey">Peterson &amp; McGarry            Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   distributed registry system is discussed further in [<a href="#ref-DRIP" title="&quot;Distributed Registry Protocol (DRiP)&quot;">DRIP</a>].  To
   support those use cases, it is important to distinguish the
   following:

   Data Store:  A data store is a service that stores and enables access
      to administrative and/or service data.

   Reference Address:  A reference address is a URL that dereferences to
      the location of the data store.

   Distributed Data Stores:  In a distributed data store, administrative
      or service data can be stored with multiple actors.  For example,
      CSPs could provision their service data to multiple other CSPs.

   Distributed Registries:  Multiple Registries can manage the same
      numbering resource.  In these architectures, actors could interact
      with one or multiple Registries.  The Registries would update each
      other when change occurs.  The Registries have to ensure that data
      remains consistent, e.g., that the same TN is not assigned to two
      different actors.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Framework</span>

   The framework outlined in this document requires three Internet-based
   mechanisms for managing and resolving TNs in an IP environment.
   These mechanisms will likely reuse existing protocols for sharing
   structured data; it is unlikely that new protocol development work
   will be required, though new information models specific to the data
   itself will be a major focus of framework development.  Likely
   candidates for reuse here include work done in DRINKS [<a href="./rfc6461" title="&quot;Data for Reachability of Inter- /Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements&quot;">RFC6461</a>] and
   Web Extensible Internet Registration Data Service (WEIRDS) [<a href="./rfc7482" title="&quot;Registration Data Access Protocol (RDAP) Query Format&quot;">RFC7482</a>],
   as well as the Telephone-Related Information (TeRI) framework
   [<a href="#ref-TERI-INFO">TERI-INFO</a>].

   These protocol mechanisms are scoped in a way that makes them likely
   to apply to a broad range of future policies for number
   administration.  It is not the purpose of this framework to dictate
   number policy but instead to provide tools that will work with
   policies as they evolve going forward.  These mechanisms, therefore,
   do not assume that number administration is centralized nor that
   number allocations are restricted to any category of service
   providers, though these tools must and will work in environments with
   those properties.








<span class="grey">Peterson &amp; McGarry            Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   The three mechanisms are:

   Acquisition:  A protocol mechanism for acquiring TNs, including an
      enrollment process.

   Management:  A protocol mechanism for associating data with TNs.

   Retrieval:  A protocol mechanism for retrieving data about TNs.

   The acquisition mechanism will enable actors to acquire TNs for use
   with a communication service by requesting numbering resources from a
   service operated by a Registrar, CSP, or similar actor.  TNs may be
   requested either on a number-by-number basis or as inventory blocks.
   Any actor who grants numbering resources will retain metadata about
   the assignment, including the responsible organization or individual
   to whom numbers have been assigned.

   The management mechanism will let actors provision data associated
   with TNs.  For example, if a User has been assigned a TN, they may
   select a CSP to provide a particular service associated with the TN,
   or a CSP may assign a TN to a User upon service activation.  In
   either case, a mechanism is needed to provision data associated with
   the TN at that CSP and to extend those data sets as CSPs (and even
   Users) require.

   The retrieval mechanism will enable actors to learn information about
   TNs.  For real-time service data, this typically involves sending a
   request to a CSP; for other information, an actor may need to send a
   request to a Registry rather than a CSP.  Different parties may be
   authorized to receive different information about TNs.

   As an example, a CSP might use the acquisition interface to acquire a
   chunk of numbers from a Registrar.  Users might then provision
   administrative data associated with those numbers at the CSP through
   the management interface and query for service data relating to those
   numbers through the retrieval interface of the CSP.















<span class="grey">Peterson &amp; McGarry            Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


               +--------+
               |Registry|
               +---+----+
                   |
                   V
              +---------+
              |Registrar|
              +---------+
                    \
                     \\
           Acquisition \\
                         \\+-------+
                           \  CSP  |
                           +---+---+
                            A     A
                            |     |
                 Management |     | Retrieval
                            |     |
                            |     |
                    +-------++   ++-------+
                    |  User  |   |  User  |
                    +--------+   +--------+
                    (Delegate)    (Caller)


                 Figure 2: Example of the Three Interfaces

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Use Cases</span>

   The high-level use cases in this section will provide an overview of
   the expected operation of the three interfaces in the MODERN problem
   space.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Acquisition</span>

   There are various scenarios for how TNs can be acquired by the
   relevant actors, that is, a CSP, Service Enabler, and a User.  There
   are three actors from which numbers can be acquired: a Registrar, a
   CSP, and a User (presumably one who is delegating to another party).
   It is assumed either that Registrars are the same entity as
   Registries or that Registrars have established business relationships
   with Registries that enable them to distribute the numbers that the
   Registries administer.  In these use cases, a User may acquire TNs
   either from a CSP, a Registry, or an intermediate delegate.







<span class="grey">Peterson &amp; McGarry            Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  Acquiring TNs from Registrar</span>

   The most traditional number acquisition use case is one where a CSP,
   such as a carrier, requests a block of numbers from a Registrar to
   hold as inventory or assign to customers.

   Through some out-of-band business process, a CSP develops a
   relationship with a Registrar.  The Registrar maintains a profile of
   the CSP and assesses whether or not CSPs meet the policy restrictions
   for acquiring TNs.  The CSP may then request TNs from within a
   specific pool of numbers in the authority of the Registry, such as
   region, mobile, wireline, or freephone.  The Registrar must
   authenticate and authorize the CSP and then either grant or deny a
   request.  When an assignment occurs, the Registry creates and stores
   administrative information related to the assignment, such as TN
   status and Registrar contact information, and removes the specific
   TN(s) from the pool of those that are available for assignment.  As a
   part of the acquisition and assignment process, the Registry provides
   to the Registrar any tokens or other material needed by a Credential
   Authority to issue credentials (for example, Secure Telephone
   Identity Revisited (STIR) certificates [<a href="./rfc8226" title="&quot;Secure Telephone Identity Credentials: Certificates&quot;">RFC8226</a>]) used to attest the
   assignment for future transactions.  Depending on the policies of the
   Numbering Authorities, Registrars may be required to log these
   operations.

   Before it is eligible to receive TN assignments, per the policy of a
   Numbering Authority, the CSP may need to have submitted (again,
   through some out-of-band process) additional qualifying information
   such as the current utilization rate or a demand forecast.

   There are two scenarios under which a CSP requests resources: either
   they are requesting inventory or they are requesting for a specific
   User or delegate.  For the purpose of status information, TNs
   assigned to a User are always considered assigned, not inventory.
   The CSP will associate service information for that TN (e.g., a
   service address) and make it available to other CSPs to enable
   interconnection.  The CSP may need to update the Registrar regarding
   this service activation; this is part of the "TN status" maintained
   by the Registrar.

   There are also use cases in which a User can acquire a TN directly
   from a Registrar.  Today, a User wishing to acquire a freephone
   number may browse the existing inventory through one or more
   Registrars, comparing their prices and services.  Each such Registrar
   either is a CSP or has a business relationship with one or more CSPs
   to provide services for that freephone number.  In this case, the
   User must establish some business relationship directly with a
   Registrar, similar to how such functions are conducted today when



<span class="grey">Peterson &amp; McGarry            Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   Users purchase domain names.  In this use case, after receiving a
   number assignment from the Registrar, a User will obtain
   communication service from a CSP and provide to the CSP the TN to be
   used for that service.  The CSP will associate service information
   for that TN (e.g., the service address) and make it available to
   other CSPs to enable interconnection.  The User will also need to
   inform the Registrar about this relationship.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  Acquiring TNs from CSPs</span>

   Today, a User typically acquires a TN from a CSP when signing up for
   a communication service or turning on a new device.  In this use
   case, the User becomes the delegate of the CSP.  A reseller or a
   service bureau might also acquire a block of numbers from a CSP to be
   issued to Users.

   Consider a case where a User creates or has a relationship with the
   CSP and subscribes to a communication service that includes the use
   of a TN.  The CSP collects and stores administrative data about the
   User.  The CSP then activates the User on their network and creates
   any necessary service data to enable connectivity with other CSPs.
   The CSP could also update public or privileged databases accessible
   by other actors.  The CSP provides any tokens or other material
   needed by a Credential Authority to issue credentials to the User
   (for example, a STIR certificate [<a href="./rfc8226" title="&quot;Secure Telephone Identity Credentials: Certificates&quot;">RFC8226</a>]) to prove the assignment
   for future transactions.  Such credentials could be delegated from
   the one provided by the Credential Authority to the CSP to continue
   the chain of assignment.  CSPs may be required to log such
   transactions if required by the policy of the Numbering Authority.

   Virtually, the same flow would work for a reseller: it would form a
   business relationship with the CSP, at which point the CSP would
   collect and store administrative data about the reseller and give the
   reseller any material needed for the reseller to acquire credentials
   for the numbers.  A User might then, in turn, acquire numbers from
   the reseller: in this case, the delegate redelegating the TNs would
   be performing functions done by the CSP (e.g., providing any
   credentials or collecting administrative data or creative service
   data).

   The CSP could assign a TN from its existing inventory or it could
   acquire a new TN from the Registrar as part of the assignment
   process.  If it assigns it from its existing inventory, it would
   remove the specific TN from the pool of those available for
   assignment.  It may also update the Registrar about the assignment so
   the Registrar has current assignment data.  If a reseller or delegate





<span class="grey">Peterson &amp; McGarry            Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   CSP is acquiring the numbers, it may have the same obligations to
   provide utilization data to the Registry as the assignee, per
   <a href="#section-4.1.1">Section 4.1.1</a>.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Management</span>

   The management protocol mechanism is needed to associate
   administrative and service data with TNs and may be used to refresh
   or rollover associated credentials.

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Management of Administrative Data</span>

   Administrative data is primarily related to the status of the TN, its
   administrative contacts, and the actors involved in providing service
   to the TN.  Protocol interactions for administrative data will
   therefore predominantly occur between CSPs and Users to the Registrar
   or between Users and delegate CSPs to the CSP.

   Some administrative data may be private and would thus require
   special handling in a distributed data store model.  Access to it
   does not require real-time performance; therefore, local caches are
   not necessary, and the data will include sensitive information such
   as User and contact data.

   Some of the data could lend itself to being publicly available, such
   as CSP and TN assignment status.  In that case, it would be deemed
   public information for the purposes of the retrieval interface.

<span class="h5"><a class="selflink" id="section-4.2.1.1" href="#section-4.2.1.1">4.2.1.1</a>.  Managing Data at a Registrar</span>

   After a CSP acquires a TN or block of TNs from the Registrar (per
   <a href="#section-4.1.1">Section 4.1.1</a>), it then provides administrative data to the Registrar
   as a step in the acquisition process.  The Registrar will
   authenticate the CSP and determine if the CSP is authorized to
   provision the administrative data for the TNs in question.  The
   Registry will update the status of the TN, i.e., that it is
   unavailable for assignment.  The Registrar will also maintain
   administrative data provided by the CSP.

   Changes to this administrative data will not be frequent.  Examples
   of changes would be terminating service (see <a href="#section-4.2.3.2">Section 4.2.3.2</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
   prove administrative responsibility for the TN.







<span class="grey">Peterson &amp; McGarry            Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   In some cases, such as the freephone system in North America today,
   the User has a direct relationship with the Registrar.  Naturally,
   these Users could provision administrative data associated with their
   TNs directly to the Registrar just as a freephone provider today
   maintains account and billing data.  While delegates may not
   ordinarily have a direct relationship to a Registrar, some
   environments (as an optimization) might want to support a model where
   the delegate updates the Registrar directly on changes, as opposed to
   sending that data to the CSP or through the CSP to the Registrar.  As
   stated already, the protocol should enable Users to acquire TNs
   directly from a Registrar, which may or may not also act as a CSP.
   In these cases, the updates would be similar to those described in
   <a href="#section-4.2.1.1">Section 4.2.1.1</a>.

   In a distributed Registry model, TN status (e.g., allocated,
   assigned, available, or unavailable) would need to be provided to
   other Registries in real time.  Other administrative data could be
   sent to all Registries, or other Registries could get a reference
   address to the host Registry's data store.

<span class="h5"><a class="selflink" id="section-4.2.1.2" href="#section-4.2.1.2">4.2.1.2</a>.  Managing Data at a CSP</span>

   After a User acquires a TN or block of TNs from a CSP, the User will
   provide administrative data to the CSP.  The CSP commonly acts as a
   Registrar in this case by maintaining the administrative data and
   only notifying the Registry of the change in TN status.  In this
   case, the Registry maintains a reference address (see <a href="#section-2.3">Section 2.3</a>) to
   the CSP/Registrar's administrative data store so relevant actors have
   the ability to access the data.  Alternatively, a CSP could send the
   administrative data to an external Registrar to store.  If there is a
   delegate between the CSP and User, they will have to ensure there is
   a mechanism for the delegate to update the CSP as change occurs.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Management of Service Data</span>

   Service data is data required by an originating or intermediate CSP
   to enable communication service to a User; a SIP URI is an example of
   one service data element commonly used to route communication.  CSPs
   typically create and manage service data, however, it is possible
   that delegates and Users could as well.  For most use cases involving
   individual Users, it is anticipated that lower-level service
   information changes (such as an end-user device receiving a new IP
   address) would be communicated to CSPs via existing protocols.  For
   example, the baseline SIP REGISTER [<a href="./rfc3261" title="&quot;SIP: Session Initiation Protocol&quot;">RFC3261</a>] method, even for bulk
   operations [<a href="./rfc6140" title="&quot;Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)&quot;">RFC6140</a>], would likely be used rather than through any
   new interfaces defined by MODERN.





<span class="grey">Peterson &amp; McGarry            Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


<span class="h5"><a class="selflink" id="section-4.2.2.1" href="#section-4.2.2.1">4.2.2.1</a>.  CSP to Other CSPs</span>

   After a User enrolls for service with a CSP, in the case where the
   CSP was assigned the TN by a Registrar, the CSP will then create a
   service address such as a SIP URI and associate it with the TN.  The
   CSP needs to update this data to enable service interoperability.
   There are multiple ways that this update can occur, though most
   commonly service data is exposed through the retrieval interface (see
   <a href="#section-4.3">Section 4.3</a>).  For certain deployment architectures, like a
   distributed data store model, CSPs may need to provision data
   directly to other CSPs.

   If the CSP is assigning a TN from its own inventory, it may not need
   to perform service data updates as change occurs because the existing
   service data associated with inventory may be sufficient once the TN
   is put in service.  They would, however, likely update the Registry
   on the change in status.

<span class="h5"><a class="selflink" id="section-4.2.2.2" href="#section-4.2.2.2">4.2.2.2</a>.  User to CSP</span>

   Users could also associate service data to their TNs at the CSP.  An
   example would be a User acquiring a TN from the Registrar (as
   described in <a href="#section-4.1.1">Section 4.1.1</a>) and wanting to provide that TN to the CSP
   so the CSP can enable service.  In this case, once the User provides
   the number to the CSP, the CSP would update the Registry or other
   actors as outlined in <a href="#section-4.2.2.1">Section 4.2.2.1</a>.

<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>.  Managing Change</span>

   This section will address some special management use cases that were
   not covered above.

<span class="h5"><a class="selflink" id="section-4.2.3.1" href="#section-4.2.3.1">4.2.3.1</a>.  Changing the CSP for an Existing Service</span>

   Consider the case where a User who subscribes to a communication
   service (and who received their TN from that CSP) wishes to retain
   the same TN but move their service to a different CSP.

   In the simplest scenario, where there's an authoritative combined
   Registry/Registrar that maintains service data, the User could
   provide their credential to the new CSP and let the CSP initiate the
   change in service.  The new CSP could then provide the new service
   data with the User's credential to the Registry/Registrar, which then
   makes the change.  The old credential is revoked and a new one is
   provided.  The new CSP or the Registrar would send a notification to
   the old CSP so they can disable service.  The old CSP will undo any
   delegations to the User, including contacting the Credential
   Authority to revoke any cryptographic credentials (e.g., STIR



<span class="grey">Peterson &amp; McGarry            Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   certificates [<a href="./rfc8226" title="&quot;Secure Telephone Identity Credentials: Certificates&quot;">RFC8226</a>]) previously granted to the User.  Any service
   data maintained by the CSP must be removed, and, similarly, the CSP
   must delete any such information it provisioned in the Registry.

   In a model similar to common practice in environments today, the User
   could alternatively provide their credential to the old CSP, and the
   old CSP would initiate the change in service.  Or, a User could go
   directly to a Registrar to initiate a port.  This framework should
   support all of these potential flows.

   Note that in cases with a distributed Registry that maintained
   service data, the Registry would also have to update the other
   Registries of the change.

<span class="h5"><a class="selflink" id="section-4.2.3.2" href="#section-4.2.3.2">4.2.3.2</a>.  Terminating a Service</span>

   Consider a case where a User who subscribes to a communication
   service (and who received their TN from the CSP) wishes to terminate
   their service.  At this time, the CSP will undo any delegations to
   the User, which may involve contacting the Credential Authority to
   revoke any cryptographic credentials (e.g., STIR certificates
   [<a href="./rfc8226" title="&quot;Secure Telephone Identity Credentials: Certificates&quot;">RFC8226</a>]) previously granted to the User.  Any service data
   maintained by the CSP must be removed, and similarly, the CSP must
   delete any such information it provisioned in the Registrar.
   However, per the policy of the Numbering Authority, Registrars and
   CSPs may be required to preserve historical data that will be
   accessible to Government Entities or others through audits, even if
   it is no longer retrievable through service interfaces.

   The TN will change state from assigned to unassigned, and the CSP
   will update the Registry.  Depending on policies, the TN could go
   back into the Registry, CSP, or delegate's pool of available TNs and
   would likely enter an aging process.

   In an alternative use case, a User who received their own TN
   assignment directly from a Registrar terminates their service with a
   CSP.  At this time, the User might terminate their assignment from
   the Registrar and return the TN to the Registry for reassignment.
   Alternatively, they could retain the TN and elect to assign it to
   some other service at a later time.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Retrieval</span>

   Retrieval of administrative or service data will be subject to access
   restrictions based on the category of the specific data: public,
   semi-restricted, or restricted.  Both administrative and service data
   can have data elements that fall into each of these categories.  It
   is expected that the majority of administrative data will fall into



<span class="grey">Peterson &amp; McGarry            Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   the semi-restricted category: access to this information may require
   some form of authorization, though service data crucial to
   reachability will need to be accessible.  In some environments, it's
   possible that none of the service data necessary to initiate
   communication will be useful to an entity on the public Internet, or
   that all that service data will have dependencies on the origination
   point for calls.

   The retrieval protocol mechanism for semi-restricted and restricted
   data needs a way for the receiver of the request to identify the
   originator of the request and what is being requested.  The receiver
   of the request will process that request based on this information.

<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>.  Retrieval of Public Data</span>

   Either administrative or service data may be made publicly available
   by the authority that generates and provisions it.  Under most
   circumstances, a CSP wants its communication service to be publicly
   reachable through TNs, so the retrieval interface supports public
   interfaces that permit clients to query for service data about a TN.
   Some service data may, however, require that the client be authorized
   to receive it, per the use case in <a href="#section-4.3.3">Section 4.3.3</a>.

   Public data can simply be posted on websites or made available
   through a publicly available API.  Public data hosted by a CSP may
   have a reference address at the Registry.

<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>.  Retrieval of Semi-restricted Administrative Data</span>

   Consider a case in which a CSP is having service problems completing
   calls to a specific TN, so it wants to contact the CSP serving that
   TN.  The Registry authorizes the originating CSP to access this
   information.  It initiates a query to the Registry, the Registry
   verifies the requestor and the requested data, and the Registry
   responds with the serving CSP and contact data.  However, CSPs might
   not want to make those administrative contact points public data:
   they are willing to share them with other CSPs for troubleshooting
   purposes, but not to make them available to general communication.

   Alternatively, that information could be part of a distributed data
   store and not stored at a monolithic Registry.  In that case, the CSP
   has the data in a local distributed data store, and it initiates the
   query to the local data store.  The local data store responds with
   the CSP and contact data.  No verification is necessary because it
   was done when the CSP was authorized to receive the data store.






<span class="grey">Peterson &amp; McGarry            Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>.  Retrieval of Semi-restricted Service Data</span>

   Consider a case where a User on a CSP's network calls a TN.  The CSP
   initiates a query for service data associated with the TN to complete
   the call and will receive special service data because the CSP
   operates in a closed environment where different CSPs receive
   different responses, and only participating CSPs can initiate
   communication.  This service data would be flagged as semi-
   restricted.  The query and response have real-time performance
   requirements in that environment.

   Semi-restricted service data also works in a distributed data store
   model where each CSP distributes its updated service data to all
   other CSPs.  The originating CSP has the service data in its local
   data store and queries it.  The local data store responds with the
   service data.  The service data in the response can be a reference
   address to a data store maintained by the serving CSP or it can be
   the service address itself.  In the case where the response gives a
   reference address, a subsequent query would go to the serving CSP,
   who would, in turn, authorize the requestor for the requested data
   and respond appropriately.  In the case, where the original response
   contains the service address, the requestor would use that service
   address as the destination for the call.

   In some environments, aspects of the service data may reside at the
   Registry itself (for example, the assigned CSP for a TN); thus, the
   query may be sent to the Registry.  The Registry verifies the
   requestor and the requested data and responds with the service data,
   such as a SIP URI containing the domain of the assigned CSP.

<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>.  Retrieval of Restricted Data</span>

   A Government Entity wishes to access information about a particular
   User who subscribes to a communication service.  The entity that
   operates the Registry on behalf of the Numbering Authority in this
   case has some predefined relationship with the Government Entity.
   When the CSP acquired TNs from the Numbering Authority, it was a
   condition of that assignment that the CSP provide access for
   Government Entities to telephone numbering data when certain
   conditions apply.  The required data may reside either in the CSP or
   in the Registrar.

   For a case where the CSP delegates a number to the User, the CSP
   might provision the Registrar (or itself, if the CSP is composed with
   a Registrar) with information relevant to the User.  At such a time
   as the Government Entity needs information about that User, the
   Government Entity may contact the Registrar or CSP to acquire the
   necessary data.  The interfaces necessary for this will be the same



<span class="grey">Peterson &amp; McGarry            Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   as those described in <a href="#section-4.3">Section 4.3</a>; the Government Entity will be
   authenticated and an authorization decision will be made by the
   Registrar or CSP under the policy dictates established by the
   Numbering Authority.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  IANA Considerations</span>

   This document has no IANA actions.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Privacy Considerations</span>

   This framework defines two categories of information about telephone
   numbers: service data and administrative data.  Service data
   describes how telephone numbers map to particular services and
   devices that provide real-time communication for users.  As such,
   service data could potentially leak resource locations and even
   lower-layer network addresses associated with these services, and in
   rare cases, with end-user devices.  Administrative data more broadly
   characterizes who the administrative entities are behind telephone
   numbers, which will often identify CSPs but some layers of the
   architecture could include Personally Identifiable Information (PII),
   even WHOIS-style information, about the end users behind identifiers.
   This could conceivably encompass the sorts of data that carriers and
   similar CSPs today keep about their customers for billing purposes,
   like real names and postal addresses.  The exact nature of
   administrative data is not defined by this framework, and it is
   anticipated that the protocols that will perform this function will
   be extensible for different use cases, so at this point, it is
   difficult to characterize exactly how much PII might end up being
   housed by these services.

   As such, if an attacker were to compromise the registrar services
   that maintains administrative data in this architecture, and in some
   cases even service data, this could leak PII about end users.  These
   interfaces, and the systems that host them, are a potentially
   attractive target for hackers and need to be hardened accordingly.
   Protocols that are selected to fulfill these functions must provide
   the security features described in <a href="#section-7">Section 7</a>.

   Finally, this framework recognizes that, in many jurisdictions,
   certain government agencies have a legal right to access service and
   administrative data maintained by CSPs.  This access is typically
   aimed at identifying the users behind the communication identifier in
   order to enforce regulatory policy.  Those legal entities already
   have the power to access the existing data held by CSPs in many
   jurisdictions, though, potentially, the administrative data
   associated with this framework could be richer information.




<span class="grey">Peterson &amp; McGarry            Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   The acquisition, management, and retrieval of administrative and
   service data associated with telephone numbers raises a number of
   security issues.

   Any mechanism that allows an individual or organization to acquire
   telephone numbers will require a means of mutual authentication, of
   integrity protection, and of confidentiality.  A Registry as defined
   in this document will surely want to authenticate the source of an
   acquisition request as a first step in the authorization process to
   determine whether or not the resource will be granted.  Integrity of
   both the request and response is essential to ensuring that tampering
   does not allow attackers to block acquisitions, or worse, to
   commandeer resources.  Confidentiality is essential to preventing
   eavesdroppers from learning about allocations, including the
   personally identifying information associated with the administrative
   or technical contracts for allocations.

   A management interface for telephone numbers has similar
   requirements.  Without proper authentication and authorization
   mechanisms in place, an attack could use the management interface to
   disrupt service data or administrative data, which could deny service
   to users, enable new impersonation attacks, prevent billing systems
   from operating properly, and cause similar system failures.

   Finally, a retrieval interface has its own needs for mutual
   authentication, integrity protection, and confidentiality.  Any CSP
   sending a request to retrieve service data associated with a number
   will want to know that it is reaching the proper authority, that the
   response from that authority has not been tampered with in transit,
   and, in most cases, the CSP will not want to reveal to eavesdroppers
   the number it is requesting or the response that it has received.
   Similarly, any service answering such a query will want to have a
   means of authenticating the source of the query and of protecting the
   integrity and confidentiality of its responses.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Informative References</span>

   [<a id="ref-DRIP">DRIP</a>]     Wendt, C. and H. Bellur, "Distributed Registry Protocol
              (DRiP)", Work in Progress, <a href="./draft-wendt-modern-drip-02">draft-wendt-modern-drip-02</a>,
              July 2017.

   [<a id="ref-RFC3261">RFC3261</a>]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
              DOI 10.17487/RFC3261, June 2002,
              &lt;<a href="https://www.rfc-editor.org/info/rfc3261">https://www.rfc-editor.org/info/rfc3261</a>&gt;.



<span class="grey">Peterson &amp; McGarry            Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


   [<a id="ref-RFC3375">RFC3375</a>]  Hollenbeck, S., "Generic Registry-Registrar Protocol
              Requirements", <a href="./rfc3375">RFC 3375</a>, DOI 10.17487/RFC3375, September
              2002, &lt;<a href="https://www.rfc-editor.org/info/rfc3375">https://www.rfc-editor.org/info/rfc3375</a>&gt;.

   [<a id="ref-RFC3912">RFC3912</a>]  Daigle, L., "WHOIS Protocol Specification", <a href="./rfc3912">RFC 3912</a>,
              DOI 10.17487/RFC3912, September 2004,
              &lt;<a href="https://www.rfc-editor.org/info/rfc3912">https://www.rfc-editor.org/info/rfc3912</a>&gt;.

   [<a id="ref-RFC6116">RFC6116</a>]  Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery System (DDDS) Application (ENUM)", <a href="./rfc6116">RFC 6116</a>,
              DOI 10.17487/RFC6116, March 2011,
              &lt;<a href="https://www.rfc-editor.org/info/rfc6116">https://www.rfc-editor.org/info/rfc6116</a>&gt;.

   [<a id="ref-RFC6140">RFC6140</a>]  Roach, A., "Registration for Multiple Phone Numbers in the
              Session Initiation Protocol (SIP)", <a href="./rfc6140">RFC 6140</a>,
              DOI 10.17487/RFC6140, March 2011,
              &lt;<a href="https://www.rfc-editor.org/info/rfc6140">https://www.rfc-editor.org/info/rfc6140</a>&gt;.

   [<a id="ref-RFC6461">RFC6461</a>]  Channabasappa, S., Ed., "Data for Reachability of Inter-
              /Intra-NetworK SIP (DRINKS) Use Cases and Protocol
              Requirements", <a href="./rfc6461">RFC 6461</a>, DOI 10.17487/RFC6461, January
              2012, &lt;<a href="https://www.rfc-editor.org/info/rfc6461">https://www.rfc-editor.org/info/rfc6461</a>&gt;.

   [<a id="ref-RFC7482">RFC7482</a>]  Newton, A. and S. Hollenbeck, "Registration Data Access
              Protocol (RDAP) Query Format", <a href="./rfc7482">RFC 7482</a>,
              DOI 10.17487/RFC7482, March 2015,
              &lt;<a href="https://www.rfc-editor.org/info/rfc7482">https://www.rfc-editor.org/info/rfc7482</a>&gt;.

   [<a id="ref-RFC8226">RFC8226</a>]  Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", <a href="./rfc8226">RFC 8226</a>,
              DOI 10.17487/RFC8226, February 2018,
              &lt;<a href="https://www.rfc-editor.org/info/rfc8226">https://www.rfc-editor.org/info/rfc8226</a>&gt;.

   [<a id="ref-TERI-INFO">TERI-INFO</a>]
              Peterson, J., "An Architecture and Information Model for
              Telephone-Related Information (TeRI)", Work in Progress,
              <a href="./draft-peterson-modern-teri-04">draft-peterson-modern-teri-04</a>, March 2018.

Acknowledgments

   We would like to thank Henning Schulzrinne and Adam Roach for their
   contributions to this problem statement and framework; we would also
   like to thank Pierce Gorman for detailed comments.







<span class="grey">Peterson &amp; McGarry            Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc8396">RFC 8396</a>                     MODERN Problems                   July 2018</span>


Authors' Addresses

   Jon Peterson
   Neustar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520
   United States of America

   Email: jon.peterson@neustar.biz


   Tom McGarry

   Email: tmcgarry6@gmail.com





































Peterson &amp; McGarry            Informational                    [Page 23]
</pre>