Network Working Group                                        J. Peterson
Internet-Draft                                                T. McGarry
Intended status: Informational                             NeuStar, Inc.
Expires: January 8, September 14, 2017                               March 13, 2017                                    July 7, 2016

           Modern Problem Statement, Use Cases, and Framework


   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, addresses: they are now identifiers which 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 8, September 14, 2017.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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

   1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Actors  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Data Types  . . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Data Management Architectures . . . . . . . . . . . . . .   8
   3.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  10  11
     4.1.  Acquisition . . . . . . . . . . . . . . . . . . . . . . .  11
       4.1.1.  CSP Acquires TNs from Registrar . . . . . . . . . . .  11  12
       4.1.2.  User Acquires TNs from CSP  . . . . . . . . . . . . .  12
       4.1.3.  CSP Delegates TNs to Another CSP  . . . . . . . . . .  12  13
       4.1.4.  User Acquires TNs from a Delegate . . . . . . . . . .  13
       4.1.5.  User Acquires Numbers TNs from Registrar  . . . . . . . .  13 . .  14
     4.2.  Management  . . . . . . . . . . . . . . . . . . . . . . .  13  14
       4.2.1.  Management of Administrative Data . . . . . . . . . .  13  14  CSP to Registrar  . . . . . . . . . . . . . . . .  14  15  User to CSP . . . . . . . . . . . . . . . . . . .  14  15  User to Registrar . . . . . . . . . . . . . . . .  15
       4.2.2.  Management of Service Data  . . . . . . . . . . . . .  15  16  CSP to other CSPs . . . . . . . . . . . . . . . .  15  16  User to CSP . . . . . . . . . . . . . . . . . . .  16
       4.2.3.  Managing Change . . . . . . . . . . . . . . . . . . .  16  17  Changing the CSP for an Existing Communications
                   Service . . . . . . . . . . . . . . . . . . . . .  16  17  Terminating a Service . . . . . . . . . . . . . .  16  17
     4.3.  Retrieval . . . . . . . . . . . . . . . . . . . . . . . .  17  18
       4.3.1.  Retrieval of Public Data  . . . . . . . . . . . . . .  17  18
       4.3.2.  Retrieval of Semi-restricted Administrative Data  . .  18
       4.3.3.  Retrieval of Semi-restricted Service Data . . . . . .  18  19
       4.3.4.  Retrieval of Restricted Data  . . . . . . . . . . . .  18  19
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19  20
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19  20
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19  20
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  20  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22  23

1.  Problem Statement

   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 [3] created a DNS-
   based mechanism for resolving TNs in an IP environment, by defining
   procedures for translating TNs into URIs for use by protocols such as
   SIP [2].  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, though in practice, it has only been deployed piecemeal by
   various parties.  Most notably, ENUM is used as an internal network
   function, and is hardly rarely used between service provider networks.  The
   original ENUM concept of a single root,, proved to be
   politically and practically challenging, and less centralized models
   have thus flourished.  Subsequently, the DRINKS [4] framework showed
   ways that authorities 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 voice-over-IP (VoIP) providers, text messaging services, and
   related non-carrier services have become heavy users of telephone
   numbers.  An enterprise, for example, could can deploy an IP PBX that
   receives a block of telephone numbers from a carrier and then in turn
   distribute 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 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
   has been implemented in many countries, and
   allows the capability of a user to choose and change their service
   provider while retaining their TN
   is widely TN; it has been implemented now. in many
   countries; either for all telephony services or for subsets such as
   mobile.  However, TN administration processes rooted in PSTN
   technology and policies dictate that this be an exception process
   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, 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 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 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 increasing 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. 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 will attempts to create a common understanding of the
   problem statement related to allocating, managing, and resolving TNs
   in an IP environment.  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.

2.  Definitions

   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.

2.1.  Actors

   The following roles of actors are defined in this document:

   Numbering Authority:  A regulatory body within a country that manages
      that country'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, and which are reserved.
      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.  There  Traditional registries are two subtypes of Registries: an
      Authoritative Registry and a Distributed Registry.  The general
      term Registry in this document refers to both kinds of Registries.

   Authoritative Registry:  An authoritative Registry is a single entity entities
      with sole authority and responsibility for specific numbering resources.

   Distributed Registry:  Distributed Registries
      resources, though distributed registries (see Section 2.3) are multiple Registries
      responsible for
      also in the same numbering resources. scope of this framework.

   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, through though
      Registrars may serve multiple Registries as well.  A Registrar has
      business relationships with its number assignees (defined below) and
      collects administrative information from them.

   Communication Service Provider (CSP):  A provider of communications
      services, where those services can be identified by TNs.  This
      includes both traditional telephone carriers or enterprises as
      well as service providers with no presence on the PSTN who use
      TNs.  This framework does not assume that any single CSP provides
      all the communications 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 third-party integrator.

   User:  An individual reachable through a communications 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, company 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, though 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 further downstream

   As an example, consider a case where a Numbering Authority also acts
   as a Registry, and it issues 10,000 blocks of TNs to CSPs, which 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 communications endpoints.  The overall ecosystem might look as

                     V 10,000 TNs
                |   CSP   |Registrar
                     V  100 TNs
                |   PBX   |Assignee
                     V    1 TN
                |  User   |Delegate

                   Figure 1: Chain of Number Assignment

2.2.  Data Types

   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 performance as access to 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, service features, and so on, data and
      typically does require real-time performance, in so far as service features.  Since this data typically is
      necessary to complete calls, it must be queried during call set-up. obtained in real time.

   Administrative and service data can fit into three categories:

   Public:  data that anyone  Anyone can access, for example 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:  data that  Only a subset of actors can access, for access semi-restricted
      data.  For example CSPs may be able to access other CSP's service

   Restricted:  data that is only available to  Only a small subset of actors,
      for 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 requestor, the distinction between semi-
   restricted and restricted is helpful for the use cases below.

2.3.  Data Management Architectures

   This framework generally assumes that administrative and service data
   is maintained by CSPs, Registrars, and Registries.  The terms
   "registrar" and "registry" are familiar from DNS operations, and
   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 [14]).  Similarly, the division between
   service data acquired by resolving names with the DNS protocol vs.
   administrative data about names acquired through WHOIS [15] is
   directly analogous to the distinction between service and
   administrative data described in Section 2.2.  The major difference
   between the data management architecture of the DNS and this
   framework is that the distinction between the CSP and User, due to
   historical policies of the telephone network, will often not exactly
   correspond to the distinction between a name service and a registrant
   in the DNS world - a User in the telephone network is today at least
   rarely in a direct relationship with a Registrar comparable to that
   of a DNS registrant.

   The role of a Registry described here is a "thin" one, where the
   Registry manages basic allocation information for the numbering
   space, such as information about whether or not the number is
   assigned, and if assigned, by which Registrar.  It is the Registrar
   that in turn manages detailed administrative data about those
   assignments, such as contact or billing information for the assignee.
   In some models, CSPs and Registrars will be composed combined (the same
   administrative entity), and in others the Registry and Registrar may
   similarly be composed.  Typically, service data resides largely at
   the CSP itself, though in some models a "thicker" Registry may itself
   contain a pointer to the servicing CSP for a number or number block.
   In addition to traditional centralized Registries, this framework
   also supports environments where the same data is being managed by
   multiple administrative entities, and stored in many locations.  A
   distributed registry system is discussed further in [16]. [19].  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:  refers to  In a Distributed Data Store, administrative
      or service data
      being can be stored with multiple actors.  For example,
      CSPs could provision their service data to multiple other CSPs.

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

3.  Framework

   The framework outlined in this document requires three Internet-based
   mechanisms for managing and resolving telephone numbers (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 [4] and WEIRDS [12], as well as the TeRI [13] [16] framework.

   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

   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 communications service.  The acquisition mechanism will
   provide a means to request 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. 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 by involves sending a
   request to a CSP.  For some 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.

          Acquisition \\
                          \  CSP  |
                           A     A
                           |     |
                Management |     | Retrieval
                           |     |
                           |     |
                   +-------++   ++-------+
                   |  User  |   |  User  |
                   +--------+   +--------+
                   (delegate)    (caller)

                 Figure 2: Example of the Three Interfaces

4.  Use Cases

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

4.1.  Acquisition

   There are various scenarios for how TNs can be acquired by the
   relevant actors: actors, that is, a CSP, Service Enabler, or 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 that Registrars are either composed with the same entity as
   Registries, or that Registrars have established business
   relationships with Registries that enable them to distribute the
   numbers that the Registries here administer.  In these use cases, a User
   may acquire TNs either from a CSP or a Registry, or from an
   intermediate delegate.

4.1.1.  CSP Acquires TNs from Registrar

   The most fundamental and traditional numbering 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 what qualifications they possess assesses whether or not CSPs meet the policy restrictions
   for requesting 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,
   tollfree, etc. 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
   any necessary credentials (for example, STIR certificates [14]) [17]) to
   the Registrar to be used to prove the assignment for future

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

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

4.1.2.  User Acquires TNs from CSP

   Today, a User typically acquires a TN from CSP when signing up for
   communications service or turning on a new device.  In this use case,
   the User becomes the delegate of the CSP.

   A User creates or has a relationship with the CSP, and subscribes to
   a communications service which 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 interoperability connectivity with other CSPs.  The CSP could also
   update public or privileged databases accessible by other Actors.

   The CSP provides any necessary credentials to the User (for example,
   a STIR certificate [14]) [17]) to prove the assignment for future
   transactions.  Such credential could be delegated from the one
   provided by the Registrar to the CSP to continue the chain of

   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 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.

4.1.3.  CSP Delegates TNs to Another CSP

   A reseller or a service bureau might acquire a block of numbers from
   a CSP to be issued to Users.

   In this case, the delegate CSP (as defined in Section 2.1) has a
   business relationship with the assignee CSP.  The assignee CSP
   collects and stores administrative data about the delegate.  The
   assignee then activates the delegate on their network and creates any
   necessary service data to enable
   interoperability interconnection with other CSPs.
   The CSP could also update public or privileged databases accessible
   by other Actors.  The CSP provides any necessary credentials to the
   delegate CSP (for example, a STIR certificate [14]) [17]) to prove the
   assignment for future transactions.  Such credentials could be
   delegated from the one provided by the Registry to the CSP to
   continue the chain of assignment.

   The CSP could assign a block from its existing inventory or it could
   acquire new TNs 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.  The Delegate delegate may need have the same obligations
   to provide utilization and assignment data to the Registry, either directly or
   through Registry as the CSP. assignee, per
   Section 4.1.1

4.1.4.  User Acquires TNs from a Delegate

   Acquiring a TN from a delegate follows the process in Section 4.1.2,
   as it should be similar to how a User acquires TNs from a CSP.  In  But
   in this case, the delegate re-delegating the TNs would be performing
   functions done by the CSP, e.g., providing any credentials,
   collecting administrative data, or creative service data, and so on. data.

4.1.5.  User Acquires Numbers TNs from 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 a CSP one or more CSPs to provide services for
   that freephone number.

   Acquiring a TN from a Registrar follows the process in Section 4.1.1,
   as it should be similar to how a CSP acquires TNs from a Registrar.
   In this case, the User must establish some business relationship
   directly to with a Registrar, similarly to how such functions are
   conducted today when Users purchase domain names.  For the purpose of
   status information kept by the Registry, TNs assigned to a User are
   always considered assigned, not inventory.

   In this use case, after receiving a number assignment from the
   Registrar, a User will then obtain communications 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., service
   address, and make it available to other CSPs to enable
   interconnection.  The user will also need to inform the Registrar
   about this relationship (see Section

4.2.  Management

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

4.2.1.  Management of Administrative Data

   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 is not a good candidate for 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 it will include sensitive information such as user
   and contact data.

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

   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
   Registrar as a step in the acquisition process.  The Registrar will
   authenticate the CSP and determine if the CSP is authorized to
   provision the administrative data for the TNs in question.  The
   Registry will update the status of the TN, i.e., that it is
   unavailable for assignment.  The Registrar will also maintain
   administrative data provided by the CSP.

   Changes to this administrative data will not be frequent.  Examples
   of changes would be terminating service (see Section and,
   changing the name or address of a User or organization, or changing a
   CSP or delegate.  Changes should be authenticated by a credential to
   prove administrative responsibility for the TN.

   In a distributed Registry model, TN status, e.g., allocated,
   assigned, available, 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.  User to CSP

   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, maintaining the administrative data and only
   notifies the Registry of the change in TN status.  In this case, the
   Registry maintains a reference address (see Section 2.3) to the CSP/Registrar's CSP/
   Registrar's administrative data store so relevant actors have the
   ability to access the data.  Alternatively  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.  User to Registrar

   If the User has a direct relationship with the Registrar, then
   naturally the user could provision administrative data associated
   with their TN directly to the Registrar.  This is the case, for
   example, with the freephone example, where a User has a business
   relationship with its freephone provider, and the freephone provider
   maintains account and billing data.  While delegates necessarily are may not assignees,
   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 Registrar may or may not also act as
   a CSP.  In these cases the updates would be similar to that described
   in Section

4.2.2.  Management of Service Data

   Service data is data required by an originating or intermediate CSP
   to enable communications service to a User: a SIP URI is an example
   of one service data element commonly used to route communications.
   CSPs typically create and manage service data, however 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 (like protocols.
   For example, the baseline SIP REGISTER [2] method) method, even for bulk
   operations [13], would likely be used rather than through any new
   interfaces defined by MODERN.  CSP to other CSPs

   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 such as a SIP URI) URI and associate it with the TN.  The
   CSP needs to update this data to enable service interoperability.
   There are multiple ways that this update can occur, though most
   commonly service data is exposed through the retrieval interface (see
   Section 4.3. 4.3).  For certain deployment architectures, like a
   distributed data store model, CSPs may need to provide 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.  User to CSP

   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
   Section 4.1.5) and wants to provide that TN to the CSP so the CSP can
   enable service.  In this case, once the user provides the number to
   the CSP, the CSP would update the Registry or other actors as
   outlined in Section

4.2.3.  Managing Change

   This section will address some special use cases that were not
   covered in other sections of 4.2.  Changing the CSP for an Existing Communications Service

   A User who subscribes to a communications service, and received their
   TN from that CSP, wishes to retain the same TN but move their service
   to a different CSP.  The User provides their credential to the new
   CSP and the CSP initiates the change in service. service

   In the simplest scenario, where there's an authoritative composed combined
   Registry/Registrar that maintains service data, the new CSP provides
   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 invalidating any cryptographic credentials (e.g. (e.g., STIR
   certificates [13]) 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 similar model to common practice in some environments today, the
   User could provide their credential to the old CSP, and the old CSP
   initiates the change in service.

   If there was  Alternatively, a User could go
   directly to a Registrar to initiate a port.  The 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.  Terminating a Service

   A User who subscribes to a communications service, and received their
   TN from the CSP, wishes to terminate their service.  At this time,
   the CSP will undo any delegations to the User, including invalidating
   any cryptographic credentials (e.g. (e.g., STIR certificates [13])
   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, 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 ageing 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 re-assignment.
   Alternatively, they could retain the TN and elect to assign it to
   some other service at a later time.

4.3.  Retrieval

   Retrieval of administrative or service data will be subject to access
   restrictions based on the category of the specific data; 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 and service data will
   fall into the semi-restricted category: access to this information
   may require some form of authorization, though service data crucial
   to reachability will need to be accessible.  In some environments,
   it's possible that none of the service data will be considered

   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.

4.3.1.  Retrieval of Public Data

   Under most circumstances, a CSP wants its communications 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 by be authorized to receive it, per the use case in Section 4.3.3

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

4.3.2.  Retrieval of Semi-restricted Administrative Data


   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 Registry responds
   with the serving CSP and contact data.

   Alternatively that information could be part of a distributed data
   store and not stored at the 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.

4.3.3.  Retrieval of Semi-restricted Service Data

   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 authorized CSPs may access service data.  The query and response
   must have real-time performance.  There are multiple scenarios for
   the query and response.

   In a distributed data store model 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 CSP,
   or it can be the service address itself.  In the case where it's the
   response gives a reference
   address the address, a subsequent query would go to
   the serving CSP and they CSP, who would verify in turn authorize the requestor and for the
   requested data and respond. respond appropriate.  In the case where
   it's the
   original response contains the service address it address, the requestor would process
   use that service address as the call using that. 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), and thus a
   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.

4.3.4.  Retrieval of Restricted Data

   In this case, a

   A Government Entity wishes to access information about a particular
   User, who subscribes to a communications service.  The entity that
   operates the Registry on behalf of the National Authority in this
   case has some pre-defined relationship with the Government Entity.
   When the CSP acquired TNs from the National 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
   as those described in Section 4.3; the Government Entity will be
   authenticated, and an authorization decision will be made by the
   Registrar or CSP under the policy dictates established by the
   National Authority.

5.  Acknowledgments

   We would like to thank Henning Schulzrinne and Adam Roach for his 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.

7.  Security Considerations

   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 interfaces has its own needs for mutual
   authentication, integrity protection, and for 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.

8.  Informative References

   [1]        Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474,
              DOI 10.17487/RFC4474, August 2006,

   [2]        Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,

   [3]        Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery System (DDDS) Application (ENUM)", RFC 6116,
              DOI 10.17487/RFC6116, March 2011,

   [4]        Channabasappa, S., Ed., "Data for Reachability of Inter-
              /Intra-NetworK SIP (DRINKS) Use Cases and Protocol
              Requirements", RFC 6461, DOI 10.17487/RFC6461, January
              2012, <>.

   [5]        Watson, M., "Short Term Requirements for Network Asserted
              Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,

   [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,

   [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, <>.

   [8]        Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
              2007, <>.

   [9]        Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,

   [10]       Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
              January 2008, <>.

   [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,

   [12]       Newton, A. and S. Hollenbeck, "Registration Data Access
              Protocol (RDAP) Query Format", RFC 7482,
              DOI 10.17487/RFC7482, March 2015,

   [13]       Roach, A., "Registration for Multiple Phone Numbers in the
              Session Initiation Protocol (SIP)", RFC 6140,
              DOI 10.17487/RFC6140, March 2011,

   [14]       Hollenbeck, S., "Generic Registry-Registrar Protocol
              Requirements", RFC 3375, DOI 10.17487/RFC3375, September
              2002, <>.

   [15]       Daigle, L., "WHOIS Protocol Specification", RFC 3912,
              DOI 10.17487/RFC3912, September 2004,

   [16]       Peterson, J., "A Framework "An Architecture and Information Model for
              Telephone-Related Information (TeRI)", draft-peterson-
              modern-teri-02 (work in progress), October 2015.

   [14] 2016.

   [17]       Peterson, J. and S. Turner, "Secure Telephone Identity
              Credentials: Certificates", draft-ietf-stir-
              certificates-11 (work in progress), July October 2016.


   [18]       Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
              Huguenin, "Verification Involving PSTN Reachability:
              Requirements and Architecture Overview", draft-jennings-
              vipr-overview-06 (work in progress), December 2013.


   [19]       Bellur, H. and C. Wendt, "Distributed Registry Protocol",
              draft-wendt-modern-drip-01 (work in progress), October

   [17] July 2016.

   [20]       Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              DOI 10.17487/RFC3263, June 2002,

Authors' Addresses

   Jon Peterson
   Neustar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520


   Tom McGarry
   Neustar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520