Skip to main content

Modern Problem Statement, Use Cases, and Framework
draft-peterson-modern-problems-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jon Peterson , Tom McGarry
Last updated 2015-07-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-peterson-modern-problems-01
Network Working Group                                        J. Peterson
Internet-Draft                                                T. McGarry
Intended status: Informational                             NeuStar, Inc.
Expires: January 7, 2016                                    July 6, 2015

           Modern Problem Statement, Use Cases, and Framework
                 draft-peterson-modern-problems-01.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 on 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 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 January 7, 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 January 7, 2016                [Page 1]
Internet-Draft               Modern Problems                   July 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 . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Acquiring Telephone Numbers . . . . . . . . . . . . . . .   6
       4.1.1.  CSP Acquires Numbers from Registry  . . . . . . . . .   6
       4.1.2.  User/Delegate Acquires TNs from CSP . . . . . . . . .   7
       4.1.3.  User Acquires TNs from a Delegate . . . . . . . . . .   8
       4.1.4.  User Acquires Numbers from Registry . . . . . . . . .   8
     4.2.  Accessing Numbering Information . . . . . . . . . . . . .   8
       4.2.1.  Service Information Access  . . . . . . . . . . . . .   8
       4.2.2.  Privileged Access for Government Entities . . . . . .   9
     4.3.  Service Management for Numbers  . . . . . . . . . . . . .   9
       4.3.1.  Updating Service Information  . . . . . . . . . . . .   9
       4.3.2.  Updating Administrative Information . . . . . . . . .  10
       4.3.3.  Changing the CSP for an Existing Communications
               Service . . . . . . . . . . . . . . . . . . . . . . .  10
       4.3.4.  Terminating a Service . . . . . . . . . . . . . . . .  10
   5.  Distributed Registries and Data Stores  . . . . . . . . . . .  11
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

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.  Most notably, ENUM is
   used as an internal network function, and is hardly used between

Peterson & McGarry       Expires January 7, 2016                [Page 2]
Internet-Draft               Modern Problems                   July 2015

   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 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
   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.  Adapting telephone numbers 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

Peterson & McGarry       Expires January 7, 2016                [Page 3]
Internet-Draft               Modern Problems                   July 2015

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

   The following actors are defined in this document:

   Numbering Authority:  A regulatory body within a country that manages
      that country's telephone numbers.  The numbering authority decides
      national numbering policy, including what telephone numbers can be
      allocated, and which are reserved.

   Registry:  An entity that administers the allocation of telephone
      numbers based on a numbering authority's policies.  Numbering
      authorities can act as the registries themselves, or they can
      outsource the function to other entities.  A registry can act as a
      sole authoritative entity for a numbering authority, or there can
      also be multiple registries that manage the same telephone numbers
      and synchronize with each other.

   Communication Service Provider:  A provider of communications
      services to users, where those services can be identified by
      telephone numbers.  This includes both traditional telephone
      carriers or enterprises as well as service providers with no
      presence on the PSTN who use telephone numbers.  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
      telephone numbers 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 Communications Service Provider, Service
   Enabler, or User can also be said to have a relationship to the
   registry of either an assignee or delegate:

Peterson & McGarry       Expires January 7, 2016                [Page 4]
Internet-Draft               Modern Problems                   July 2015

   Assignee.:  An entity that is assigned the telephone number by the
      registry.  There is a direct relationship between the registry and
      the assignee.

   Delegate:  An entity that is delegated a telephone number from an
      assignee or another delegate for assignment or delegation to
      others.  A delegate is not the assignee or the user.

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

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

Peterson & McGarry       Expires January 7, 2016                [Page 5]
Internet-Draft               Modern Problems                   July 2015

   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 analogous 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 a 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 to 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

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

4.1.  Acquiring Telephone Numbers

   There are various scenarios for how TNs can be acquired by the
   relevant actors; registry, CSP, delegate, service enabler, and user.
   The registry perform its functions as defined by the national
   authority, so the national authority does not participate in the
   protocol flows in this section.

4.1.1.  CSP Acquires Numbers from Registry

   Through some out-of-band business process, a CSP develops a
   relationship with a Registry.  The Registry has 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 stores information related to the assignment including
   the resource and the assignee, and removes the specific TN(s) from
   the pool of those that are available for assignment.  As a part of

Peterson & McGarry       Expires January 7, 2016                [Page 6]
Internet-Draft               Modern Problems                   July 2015

   the 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 number 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.  If they are requesting for a user or delegate they may
   need to register information about the user or delegate with the
   Registry.  Examples of user and delegate information could be contact
   information that may be required by Government Entities, or some
   forms of service information.  Such data could be provided to the
   Registry or the Registry could be provided with an address where that
   data can be accessed.  Such an address could be part of the CSP
   profile with the Registry.

4.1.2.  User/Delegate Acquires TNs from CSP

   A User or Delegate creates or has a relationship with the CSP, and
   subscribes to a communications service which includes the use of a
   telephone number.  The CSP first collects and stores profile data
   about the User or Delegate.  The CSP then activates the User or
   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 User or Delegate (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 in a continuing the chain of assignment.

   The CSP could assign a TN from its existing inventory or it could
   acquire it 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 utilization data.  If TNs are assigned to a Delegate for use
   as inventory to be assigned to Users, the Delegate may need to
   provide utilization data to the Registry, either directly or through
   the CSP.

Peterson & McGarry       Expires January 7, 2016                [Page 7]
Internet-Draft               Modern Problems                   July 2015

4.1.3.  User Acquires TNs from a Delegate

   This 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 would
   be performing functions done by the CSP, e.g., providing credentials,
   updating the Registry, and so on.

4.1.4.  User Acquires Numbers from Registry

   This 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.  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.  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.  Accessing Numbering Information

   Telephone numbering information will generally fall into two
   categories; administrative information and service information.
   Administrative information includes TN status, service provider,
   contact data, etc. and typically does not require real-time
   performance.  Service information includes addressing data, feature
   capabilities, etc. and typically does require real-time performance.

   Telephone numbering data can be stored at the Registry or at the CSP
   that holds the information.  The address for accessing the
   information would need to be available to others to enable access and
   interoperability.  For example, if the data is held by the Registry,
   a URL for accessing that data could be published to those that have
   access to the Registry.  The Registry could allow and restrict access
   to specific information based on the identity of requestor.  If the
   data is held by a CSP, the Registry could host an address for each TN
   that references the correct CSP, and the CSP would allow or restrict
   access based on the requestor.

4.2.1.  Service Information Access

   A gateway receives a call for a telephone number.  That telephone
   number is assigned to a CSP, who has delegated to the number to a
   User.  The gateway wants to reach the User through an Internet

Peterson & McGarry       Expires January 7, 2016                [Page 8]
Internet-Draft               Modern Problems                   July 2015

   communications endpoint.  It therefore send a query to the Registry
   responsible for the numbering space that the telephone number resides
   in.  The Registry proxies or redirects the request to the CSP that
   has been assigned the number.  The CSP returns Internet endpoint
   information for that number to the gateway, possibly after making an
   authorization decision.

   In an alternative use case, the CSP might provision the Registry with
   endpoint service information for the telephone number, or the CSP
   might have delegated to the User the responsibility for provisioning
   this information with the Registry.

4.2.2.  Privileged Access for Government Entities

   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.

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

4.3.  Service Management for Numbers

   The use cases in this section describe ways that numbering data,
   including administrative information and service information, might
   be updated at the CSP or Registry after a number has been initially
   assigned and provisioned.

4.3.1.  Updating Service Information

   A CSP handles all users in a large region through a central set of
   proxy servers.  They provision a URL pointing to that service in the
   Registry.  After a business transition, the CSP wants to point the
   service to a new URL.  The CSP therefore sends a provisioning update
   to the Registry.

Peterson & McGarry       Expires January 7, 2016                [Page 9]
Internet-Draft               Modern Problems                   July 2015

   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.

4.3.2.  Updating Administrative Information

   A User who subscribes to a communications service changes their
   postal address, moving from one location in the country to another.
   At this time, the User informs the CSP.  The CSP updates its own
   records, and send an update to the Registry as well, as the National
   Authority in this case requires that the CSP notify the Registry of
   changes in the contact information associated with numbering
   resources.

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

   Depending on the policies set by the National Authority, it might be
   the responsibility of either the old or new CSP to initiate the
   transition process.  The new CSP will then provision the registry
   with the new service and administrative information associated with
   the CSP, though much of the administrative information relating to
   the User may remain the same through this transition.  The CSP will
   perform other functions described above in Section 4.1.2.

   At this time, 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 routing or
   service information maintained by the CSP must be removed, and
   similarly, the CSP must delete any such information it provisioned in
   the Registry.

   [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.3.4.  Terminating a Service

   This use case is very similar to that in Section 4.3.3.  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 routing or service information maintained

Peterson & McGarry       Expires January 7, 2016               [Page 10]
Internet-Draft               Modern Problems                   July 2015

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

   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 number to the Registry for re-
   assignment.  Alternatively, they could retain the number and elect to
   assign it to some other service at a later time.

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 January 7, 2016               [Page 11]
Internet-Draft               Modern Problems                   July 2015

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

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

Peterson & McGarry       Expires January 7, 2016               [Page 12]
Internet-Draft               Modern Problems                   July 2015

   [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]       Peterson, J., "Secure Telephone Identity Credentials:
              Certificates", draft-ietf-stir-certificates-01 (work in
              progress), March 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, June
              2002.

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 January 7, 2016               [Page 13]