doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

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