Modern Problem Statement and Framework
draft-peterson-modern-problems-00

Network Working Group                                        J. Peterson
Internet-Draft                                                T. McGarry
Intended status: Informational                             NeuStar, Inc.
Expires: September 9, 2015                                 March 8, 2015

                 Modern Problem Statement and Framework
                 draft-peterson-modern-problems-00.txt

Abstract

   The functions of the public switched telephone network (PSTN) are
   gradually migrating to the Internet.  This is generating new
   requirements for many mechanisms used by 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 needs of the
   Internet environment and proposes a fraemwork 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 September 9, 2015.

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 September 9, 2015               [Page 1]
Internet-Draft               Modern Problems                  March 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 . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Actors  . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Framework . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  CSP Acquires Numbers from Authority . . . . . . . . . . .   5
     4.2.  User Acquires Numbers from Authority  . . . . . . . . . .   5
     4.3.  Accessing Numbering Data  . . . . . . . . . . . . . . . .   6
       4.3.1.  Privileged Access for Government Entities . . . . . .   6
     4.4.  Service Management for Numbers  . . . . . . . . . . . . .   6
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Problem Statement

   The challenges of utilizing telephone numbers (TNs) on the Internet
   has 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.  The DRINKS [4] framework
   showed ways that authorities might provision information about
   telephone numbers 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

Peterson & McGarry      Expires September 9, 2015               [Page 2]
Internet-Draft               Modern Problems                  March 2015

   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 telephone numbers 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
   telephone numbers 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
   telephone network is.  In an Internet environment, establishing a
   network architecture for routing telephone numbers would depend
   little on geography.

   While some properties of ENUM have been successfully deployed, others
   have not.  Most notably, ENUM is mostly 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.  The industry also came to realize that there were
   limitations in the DNS protocol and it may not be a good fit for a
   communications protocol that would need more security, richer
   datasets and more complex query and response capabilities.  The TeRQ
   proposal [12], a framework and information model for "telephone-
   related queries," proposes a reconsideration of telephone routing and
   administrative services by focusing on what data needs needs to be
   shared rather limiting the data to fit within the particular
   protocols chosen to carry it.

   With the PSTN well on its way to becoming 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
   needs to be flexible enough to account for these variations.

Peterson & McGarry      Expires September 9, 2015               [Page 3]
Internet-Draft               Modern Problems                  March 2015

2.  Actors

   The following actors are defined in this document:

   Numbering Authority:  An entity that manages an inventory of
      allocated and unallocated telephone numbers.  This may be a root
      authority, such as a national regulator, or any delegate of the
      root authority that dispenses numbers to other parties.

   Communication Service Provider:  A provider of communications
      services to users, where those services can be identifed by
      telephone numbers.  This includes both traditional telephone
      carriers and service providers with no presence on the PSTN who
      use telephone numbers.  It also encompasses users who operate
      services on their own behalf.

   User:  An operator of communications endpoints, either as an
      individual or an organization; usually a customer of a
      communication service provider who uses telephone numbers to reach
      and identify services.

   Government Entity:  An entity that, due to legal powers resulting
      from the root of number authority, has privileged access to
      information about number allocation.

3.  Framework

   The framework outlined in this document requires three Internet-based
   mechanisms for managing and resolving telephone numbers (TNs) in an
   IP environment.  These mechanisms will likely reuse existing
   protocols for sharing structured data; it is unlikely that new
   protocol development work will be required, though new information
   models specific to the data itself will be a major focus of framework
   development.  Likely candidates for reuse here include work done in
   DRINKS and WEIRDS, as well as the TeRQ 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
   propoerties.

   The three mechanisms are:

Peterson & McGarry      Expires September 9, 2015               [Page 4]
Internet-Draft               Modern Problems                  March 2015

   Acquisition:  a protocol mechanism to enable users or CSPs to acquire
      TNs from authorities, including an enrollment process for the
      individuals and entities that manage TNs.

   Management:  a protocol mechanism for users to associate data with
      TNs at a CSP.

   Retrieval:  a protocol mechanism for service providers, users, and
      governemnt entities to retrieve data about TNs from either an
      authority or a CSP.

   The acquisition mechanism will enable actors to acquire telephone
   numbers for use with a communications service.  The acquisition
   mechanism will provide a means for either a user or a CSP to request
   numbering resources from an authority, either on a number-by-number
   basis, or as inventory blocks.  The authority who grants numbering
   resources to a user will retain metadata about the assignment,
   including the responsible organization or individual to whom numbers
   have been assigned.  In the DNS environment, an authority thus might
   be analagous to either a registrar or a reseller of names, though
   obvious hierarchical domain names do not have a comparable inventory
   situation to telephone numbers.

   The management mechanism will let actors provision data associated
   with telephone numbers at CSPs.  If a user owns a telephone number,
   they may select a CSP to provide particular service associated with
   the number, or a CSP may own a number, and effectively rent these to
   users.  In either case, a user needs a mechanism for provision data
   associated with the number at a CSP.

   The resolution mechanism will enable actors to learn information
   about telephone numbers, typically by sending a request to a CSP.
   For some information, an actor may need to send a request to a
   numbering authority rather than a CSP.  Different parties may be
   authorized to receive different information about telephone numbers.

4.  Use Cases

4.1.  CSP Acquires Numbers from Authority

   TBD.

4.2.  User Acquires Numbers from Authority

   TBD.

Peterson & McGarry      Expires September 9, 2015               [Page 5]
Internet-Draft               Modern Problems                  March 2015

4.3.  Accessing Numbering Data

   TBD.

4.3.1.  Privileged Access for Government Entities

   TBD.

4.4.  Service Management for Numbers

   TBD.

5.  Acknowledgments

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

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   TBD.

8.  Informative References

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

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

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

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

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

Peterson & McGarry      Expires September 9, 2015               [Page 6]
Internet-Draft               Modern Problems                  March 2015

   [6]        Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              November 2002.

   [7]        Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [8]        Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, June 2007.

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

   [10]       Rosenberg, J. and C. Jennings, "The Session Initiation
              Protocol (SIP) and Spam", RFC 5039, January 2008.

   [11]       Peterson, J., Jennings, C., and R. Sparks, "Change Process
              for the Session Initiation Protocol (SIP) and the Real-
              time Applications and Infrastructure Area", BCP 67, RFC
              5727, March 2010.

   [12]       Peterson, J., "A Framework and Information Model for
              Queries about Telephone-Related Queries (TeRQ)", draft-
              peterson-terq-03 (work in progress), February 2013.

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

   [14]       Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263, June
              2002.

Authors' Addresses

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

   Email: jon.peterson@neustar.biz

Peterson & McGarry      Expires September 9, 2015               [Page 7]
Internet-Draft               Modern Problems                  March 2015

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

   Email: jon.peterson@neustar.biz

Peterson & McGarry      Expires September 9, 2015               [Page 8]