Network Working Group                                        J. Peterson
Internet-Draft                                                T. McGarry
Intended status: Informational                             NeuStar, Inc.
Expires: April 21, 2016                                 October 19, 2015


           Modern Problem Statement, Use Cases, and Framework
                 draft-peterson-modern-problems-02.txt

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 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 http://datatracker.ietf.org/drafts/current/.

   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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (http://trustee.ietf.org/license-info) in effect on the date of



Peterson & McGarry       Expires April 21, 2016                 [Page 1]


Internet-Draft               Modern Problems                October 2015


   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  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Data Types  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  Data Management Architectures . . . . . . . . . . . . . .   6
   3.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Acquisition . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.1.  CSP Acquires TNs from Registry  . . . . . . . . . . .   8
       4.1.2.  User Acquires TNs from CSP  . . . . . . . . . . . . .   9
       4.1.3.  CSP Delegates TNs to Another CSP  . . . . . . . . . .   9
       4.1.4.  User Acquires TNs from a Delegate . . . . . . . . . .  10
       4.1.5.  User Acquires Numbers from Registry . . . . . . . . .  10
     4.2.  Management  . . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  Management of Administrative Data . . . . . . . . . .  11
         4.2.1.1.  CSP to Registry . . . . . . . . . . . . . . . . .  11
         4.2.1.2.  User to CSP . . . . . . . . . . . . . . . . . . .  11
       4.2.2.  Management of Service Data  . . . . . . . . . . . . .  12
         4.2.2.1.  CSP to other CSPs . . . . . . . . . . . . . . . .  12
         4.2.2.2.  User to CSP . . . . . . . . . . . . . . . . . . .  12
         4.2.2.3.  User to Registry  . . . . . . . . . . . . . . . .  12
       4.2.3.  Managing Change . . . . . . . . . . . . . . . . . . .  13
         4.2.3.1.  Changing the CSP for an Existing Communications
                   Service . . . . . . . . . . . . . . . . . . . . .  13
         4.2.3.2.  Terminating a Service . . . . . . . . . . . . . .  13
     4.3.  Retrieval . . . . . . . . . . . . . . . . . . . . . . . .  14
       4.3.1.  Retrieval of Public Data  . . . . . . . . . . . . . .  14
       4.3.2.  Retrieval of Semi-restricted Administrative Data  . .  14
       4.3.3.  Retrieval of Semi-restricted Service Data . . . . . .  15
       4.3.4.  Retrieval of Restricted Data  . . . . . . . . . . . .  15
   5.  Distributed Registries and Data Stores  . . . . . . . . . . .  16
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  16
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18






Peterson & McGarry       Expires April 21, 2016                 [Page 2]


Internet-Draft               Modern Problems                October 2015


1.  Problem Statement

   The challenges of utilizing telephone numbers (TNs) on the Internet
   have been known for some time.  Internet telephony provided the main
   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].  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 used between
   service provider networks.  The original ENUM concept of a single
   root, e164.arpa, proved to be politically challenging, and less
   centralized models have thus flourished.

   Subsequently, the DRINKS [4] framework showed ways that authorities
   might provision information about TNs at an ENUM service or similar
   Internet-based directory.  These technologies have generally tried to
   preserve the features and architecture familiar from the PSTN
   numbering environment.

   Telephone numbering, however, has long been transitioning away from a
   provider-centric model towards a user-centric model.  Number
   portability has been implemented in many countries, and the right of
   a user to choose and change their service provider while retaining
   their TN is widely acknowledged now.  However, TN administration
   processes rooted in PSTN technology and policies dictate that this be
   an exception process fraught with problems and delays.  Thanks to the
   increasing sophistication of consumer mobile devices, users now
   associate TNs with many applications other than telephony.  Ideally
   the user would have full control of their TN and would drive the
   porting process on their own rather than rely on complex and time
   consuming back office processes among multiple service providers.

   Most TNs today are assigned to specific geographies, at both an
   international level and within national numbering plans.  This has
   shaped the way 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 eroded the connection
   between numbers and regions.  Furthermore, the topology of IP
   networks is not anchored to geography in the same way that the



Peterson & McGarry       Expires April 21, 2016                 [Page 3]


Internet-Draft               Modern Problems                October 2015


   telephone network is.  In an Internet environment, establishing a
   network architecture for routing TNs would depend little on
   geography.  Adapting TNs to the Internet requires more security,
   richer datasets and more complex query and response capabilities than
   previous efforts have provided.

   With the PSTN well on its way to transitioning to an all IP network,
   and TNs showing no signs of sunsetting as a resource, it is time to
   address the issues of routing, management and administration of TNs
   in an IP environment.  This document will create a common
   understanding of the problem statement related to TNs in an IP
   environment and help develop a vision for how to create IP-based
   mechanisms for TNs.  It will be important to acknowledge that there
   are various international and national policies and processes related
   to TNs, and any solutions need to be flexible enough to account for
   these variations.

2.  Definitions

   This section provides definitions for actors, data types and data
   management architectures as they are discussed in this document.

2.1.  Actors

   The following 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, including what TNs can be allocated, and which
      are reserved.

   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 are two types of Registries an
      authoritative Registry and a distributed Registry.  An
      authoritative Registry is a single entity with sole responsibility
      for specific numbering resources.  Distributed Registries are
      multiple Registries responsible for the same numbering
      resources.(There's more on distributed Registries later in this
      section.)  The general term Registry in this document refers to
      both kinds of Registries.  When referring to one versus the other
      this document will use the specific term.

   Communication Service Provider (CSP):  A provider of communications
      services to Users, 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



Peterson & McGarry       Expires April 21, 2016                 [Page 4]


Internet-Draft               Modern Problems                October 2015


      TNs.  This framework does not assume that any single CSP provides
      all the communications service related to a TN.

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

   User:  An individual reachable through a communications service;
      usually a customer of a communication service provider who uses
      TNs to reach and identify services.  Sophisticated users may also
      act as their own CSPs.

   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 a given entity may act in one or more of the roles above.
   An entity acting as a CSP, Service Enabler, or User can also be said
   to have a relationship to the Registry of either an assignee or
   delegate:

   Assignee:  An entity that is assigned a TN by the Registry.  There is
      always a direct relationship between the Registry and the
      assignee.

   Delegate:  An entity that is delegated a TN from an assignee or
      another delegate.  Delegates may use a TN for a communications
      service or delegate it in turn.

   Note that although Numbering Authorities are listed as actors, they
   are unlikely to actually participate in the protocol flows
   themselves.

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, contact data for the
      assignee or delegate, etc. and typically does not require real-
      time performance.

   Service Data:  data necessary to enable service for the TN; it
      includes addressing data, feature capabilities, etc. and typically
      does require real-time performance.

   Administrative and service data can fit into three categories:




Peterson & McGarry       Expires April 21, 2016                 [Page 5]


Internet-Draft               Modern Problems                October 2015


   Public:  data that anyone can access, for example a list of which
      numbering resources are available for acquisition from the
      Registry.

   Semi-restricted:  data that a somewhat broad subset of actors can
      access, for example CSPs may be able to access other CSP's service
      data.

   Restricted:  data that is only available to a small subset of actors,
      for example a Government Entity may be able access contact
      information for a User.

   While it seems 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

   Beyond traditional centralized Registries, this framework also
   supports environments where the same data is being managed by
   multiple entities, and stored in many locations.

   Data store:  a service that stores and enables access to
      administrative and/or service data.  Typically Registries and CSPs
      would manage data stores.

   Reference Address:  a URL that dereferences to the location of the
      data store.

   Distributed data stores:  refers to administrative or service data
      being stored with multiple actors.  For example, CSPs could
      provision their service data to multiple other CSPs.

   Distributed Registries:  refers to multiple Registries managing the
      same numbering resource.  Actors could interact with one or
      multiple Registries.  The Registries would update each other when
      change occurs.  The challenge is to ensure there are no clashes,
      e.g., two Registries assigning the same TN to two different
      actors.

3.  Framework

   The framework outlined in this document requires three Internet-based
   mechanisms for managing and resolving TNs (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



Peterson & McGarry       Expires April 21, 2016                 [Page 6]


Internet-Draft               Modern Problems                October 2015


   candidates for reuse here include work done in DRINKS and WEIRDS, as
   well as the TeRQ [12] 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
   "ownership" is restricted to any privileged service providers, though
   these tools must and will work in environments with those properties.

   The three mechanisms are:

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

   Management:  a protocol mechanism for associating data with TNs.

   Retrieval:  a protocol mechanism for retrieving data about TNs from
      either an authority or a CSP.

   The acquisition mechanism will enable actors to acquire TNs for use
   with a communications service.  The acquisition mechanism will
   provide a means to request numbering resources from a service
   operated by a Registry, 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 at CSPs.  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.

   The retrieval mechanism will enable actors to learn information about
   TNs, typically by sending a request to a CSP.  For some 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.








Peterson & McGarry       Expires April 21, 2016                 [Page 7]


Internet-Draft               Modern Problems                October 2015


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

4.1.  Acquisition

   There are various scenarios for how TNs can be acquired by the
   relevant actors: a Registry, CSP, Service Enabler, or User.  There
   are three actors from which numbers can be acquired: a Registry, a
   CSP and a User (presumably one who is delegating to another party).
   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 Registry

   The most fundamental and traditional numbering use case is one where
   a CSP, such as a carrier, requests a block of numbers from a Registry
   to hold as inventory or assign to customers.

   Through some out-of-band business process, a CSP develops a
   relationship with a Registry.  The Registry maintains a profile of
   the CSP and what qualifications they possess for requesting 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.  The Registry 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 contact information, and removes
   the specific TN(s) from the pool of those that are available for
   assignment.  As a part of the acqusition and assignment process, the
   Registry provides credentials (for example, STIR certificates [13])
   to the CSP to be used to prove the assignment for future
   transactions.

   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
   by the Registry, not inventory.  In this use case, after receiving a
   number assignment from the Registry, a User will then obtain
   communications service from a CSP, and provide to the CSP the TN to
   be used for that service along with the credential.  The CSP will



Peterson & McGarry       Expires April 21, 2016                 [Page 8]


Internet-Draft               Modern Problems                October 2015


   associate service information for that TN, e.g., service address, and
   make it available to other CSPs to enable interoperability.  The CSP
   may need to update the Registry regarding this service activation
   (this is part of the "TN status" maintained by the Registry).

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 with other CSPs.  The CSP could also
   update public or privileged databases accessible by other Actors.
   The CSP provides a credential to the User (for example, a STIR
   certificate [13]) to prove the assignment for future transactions.
   The credential could be delegated from the one provided by the
   Registry to the CSP to continue the chain of assignment.

   The CSP could assign a TN from its existing inventory or it could
   acquire a new TN from the Registry 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 Registry about the assignment so the Registry 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 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 with other CSPs.  The CSP could also update public
   or privileged databases accessible by other Actors.  The CSP provides
   a credential to the delegate CSP (for example, a STIR certificate
   [13]) to prove the assignment for future transactions.  The
   credential 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 Registry as part of the assignment process.
   If it assigns it from its existing inventory it would remove the



Peterson & McGarry       Expires April 21, 2016                 [Page 9]


Internet-Draft               Modern Problems                October 2015


   specific TN from the pool of those available for assignment.  It may
   also update the Registry about the assignment so the Registry has
   current assignment data.  The Delegate may need to provide
   utilization and assignment data to the Registry, either directly or
   through the CSP.

4.1.4.  User Acquires TNs from a Delegate

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

4.1.5.  User Acquires Numbers from Registry

   Today, typically Users do not have the capability to request
   numbering resources directly from a Registry.  MODERN supports this
   use case, for those Numbering Authorities and Registries that might
   establish policies enabling this use case in the future.

   Acquiring a TN from a Registry follows the process in Section 4.1.1,
   as it should be similar to how a CSP acquires TNs from a Registry.
   In this case, the User must establish some business relationship
   directly to a Registry, perhaps 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
   Registry, 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
   interoperability.

4.2.  Management

   The management protocol mechanism is needed to associate
   administrative and service data with TNs and distribute and receive
   credentials.  While some similar use cases may apply to individual
   Users, it is anticipated that for the most part these lower-level
   service information changes would be communicated via existing
   protocols (like the baseline [2] SIP REGISTER method) rather than
   through any interfaces defined by MODERN.

   While some similar use cases may apply to individual Users, it is
   anticipated that for the most part these lower-level service



Peterson & McGarry       Expires April 21, 2016                [Page 10]


Internet-Draft               Modern Problems                October 2015


   information changes would be communicated via existing protocols
   (like the baseline [2] SIP REGISTER method) rather than through any
   interfaces defined by MODERN.

4.2.1.  Management of Administrative Data

   Administrative data primarily is related to the status of the TN and
   the actors involved in providing service to the TN.  The Registry and
   CSP will most likely maintain the data.  Protocol interactions will
   therefore predominantly occur between CSPs and Users to the Registry,
   or between Users and delegate CSPs to the CSP.

   Most administrative data is not a good candidate for 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 the CSP or Registry
   could simply expose it on a web application.

4.2.1.1.  CSP to Registry

   A CSP acquires a TN or block of TNs from the Registry (per
   Section 4.1.1 above) and provides administrative data to the Registry
   during the acquisition process.  The Registry will update the status
   of the TN, i.e., that it is unavailable for assignment.  The Registry
   will also maintain administrative data provided by the CSP.  Changes
   to this data will not be frequent.  Examples of changes would be
   terminating service and changing a CSP or delegate.  Changes should
   be accompanied by the 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.

4.2.1.2.  User to CSP

   The User acquires a TN or block of TNs from a CSP and provides
   administrative data, the CSP provides a credential.  The CSP could
   maintain the data and only notify the Registry of the change in TN
   status.  In this case, the Registry may maintain a reference address
   to the CSP's administrative data store so relevant actors have the
   ability to access the data.  Alternatively they could send the data
   to the Registry to store.  If there is a delegate between the CSP and



Peterson & McGarry       Expires April 21, 2016                [Page 11]


Internet-Draft               Modern Problems                October 2015


   user, they will have to ensure there is a mechanism for the delegate
   to update the CSP as change occurs.

4.2.2.  Management of Service Data

   Service data is data necessary to enable communications service to
   the delegate or User, for example a SIP URI.  CSPs typically create
   and manage service data, however it is possible that delegates and
   Users could as well.

4.2.2.1.  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 Registry, 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
   Section 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.

4.2.2.2.  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 Registry (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 4.2.2.1.

4.2.2.3.  User to Registry

   If the User has a direct relationship with the Registry, then
   naturally the user could could provision administrative data
   associated with their TN directly to the Registry.  While delegates
   necessarily are not assignees, there could be a model where the
   delegate updates the Registry directly on changes, as opposed to
   sending that data to the CSP or through the CSP to the Registry.  As
   stated already the protocol should enable Users to acquire TNs
   directly from a Registry and in essence act as their own CSP.  In




Peterson & McGarry       Expires April 21, 2016                [Page 12]


Internet-Draft               Modern Problems                October 2015


   these cases the updates would be similar to that described in
   4.2.2.1.

4.2.3.  Managing Change

   This section will address some special use cases that were not
   covered in other sections of 4.2.

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

   In the simplest scenario, where there's an authoritative Registry
   that maintains service data, the new CSP provides the new service
   data with the User's credential to the Registry and the Registry
   makes the change.  The old credential is revoked and a new one is
   provided.  The new CSP or Registry 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.  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.

   If there was a distributed Registry that maintained service data, the
   Registry would also have to update the other Registries of the
   change.

   If there was a distributed data store the new CSP would have to
   update all the other CSPs including the old CSP of the new service
   data.  In this model both CSPs would have to have the ability to
   update all of the same CSPs.  That is the new CSP would have to make
   sure all of the CSPs provisioned by the old CSP get the updated
   service data.

   [TBD - more on the case where multiple CSPs provide services for a
   given TN, and only one service is "ported" to a new CSP?]

4.2.3.2.  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.  STIR certificates [13])
   previously granted to the User.  Any service data maintained by the



Peterson & McGarry       Expires April 21, 2016                [Page 13]


Internet-Draft               Modern Problems                October 2015


   CSP must be removed, and similarly, the CSP must delete any such
   information it provisioned in the Registry.

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

   In an alternative use case, a User who received their own TN
   assignment directly from the Registry terminates their service with a
   CSP.  At this time, the User might terminate their assignment from
   the Registry, 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; 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.  It's possible that none of
   the service data will be considered public.

   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 authorized to receive it, per the use case in Section 4.3.3
   below.

   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

   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 to this information.  It



Peterson & McGarry       Expires April 21, 2016                [Page 14]


Internet-Draft               Modern Problems                October 2015


   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 to 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 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 it's a reference
   address the query would go to the serving CSP and they would verify
   the requestor and the requested data and respond.  In the case where
   it's the service address it would process the call using that.

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



Peterson & McGarry       Expires April 21, 2016                [Page 15]


Internet-Draft               Modern Problems                October 2015


   For a case where the CSP delegates a number to the User, the CSP
   might provision the Registry 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 Registry 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 Registry or CSP under the policy dictates established by the
   National Authority.

5.  Distributed Registries and Data Stores

   It is possible to create a distributed Registry or distributed Data
   Stores for the administrative and service information associated with
   a TN.

   In a distributed Registry there would be multiple duplicate copies of
   the Registry data.  A CSP or User would interact with one Registry
   and that Registry would be responsible for initiating updates to all
   other Registries when there is a change.  The challenge is to ensure
   that there are no clashes, e.g., two Registries assigning the same TN
   to two different CSPs.

   Similarly multiple entities can maintain duplicate copies of
   administrative and service data associated with TNs.  For example,
   when a CSP enables service for a User they can initiative an update
   of the service address to multiple other data stores managed by other
   service providers.  This may not be the best solution for User
   contact data.

   [More TBD]

6.  Acknowledgments

   We would like to thank Henning Schulzrinne for his contributions to
   this problem statement and framework.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   TBD.







Peterson & McGarry       Expires April 21, 2016                [Page 16]


Internet-Draft               Modern Problems                October 2015


9.  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,
              <http://www.rfc-editor.org/info/rfc4474>.

   [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,
              <http://www.rfc-editor.org/info/rfc3261>.

   [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,
              <http://www.rfc-editor.org/info/rfc6116>.

   [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, <http://www.rfc-editor.org/info/rfc6461>.

   [5]        Watson, M., "Short Term Requirements for Network Asserted
              Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
              <http://www.rfc-editor.org/info/rfc3324>.

   [6]        Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              DOI 10.17487/RFC3325, November 2002,
              <http://www.rfc-editor.org/info/rfc3325>.

   [7]        Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <http://www.rfc-editor.org/info/rfc6698>.

   [8]        Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
              2007, <http://www.rfc-editor.org/info/rfc4916>.

   [9]        Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, DOI 10.17487/RFC3966, December 2004,
              <http://www.rfc-editor.org/info/rfc3966>.




Peterson & McGarry       Expires April 21, 2016                [Page 17]


Internet-Draft               Modern Problems                October 2015


   [10]       Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
              January 2008, <http://www.rfc-editor.org/info/rfc5039>.

   [11]       Peterson, J., Jennings, C., and R. Sparks, "Change Process
              for the Session Initiation Protocol (SIP) and the Real-
              time Applications and Infrastructure Area", BCP 67,
              RFC 5727, DOI 10.17487/RFC5727, March 2010,
              <http://www.rfc-editor.org/info/rfc5727>.

   [12]       Peterson, J., "A Framework and Information Model for
              Telephone-Related Queries (TeRQ)", draft-peterson-terq-04
              (work in progress), July 2015.

   [13]       Peterson, J., "Secure Telephone Identity Credentials:
              Certificates", draft-ietf-stir-certificates-02 (work in
              progress), July 2015.

   [14]       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.

   [15]       Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              DOI 10.17487/RFC3263, June 2002,
              <http://www.rfc-editor.org/info/rfc3263>.

Authors' Addresses

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

   Email: jon.peterson@neustar.biz


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

   Email: tom.mcgarry@neustar.biz





Peterson & McGarry       Expires April 21, 2016                [Page 18]