< draft-ietf-modern-problem-framework-02.txt   draft-ietf-modern-problem-framework-03.txt >
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft T. McGarry Internet-Draft T. McGarry
Intended status: Informational NeuStar, Inc. Intended status: Informational NeuStar, Inc.
Expires: September 14, 2017 March 13, 2017 Expires: January 4, 2018 July 3, 2017
Modern Problem Statement, Use Cases, and Framework Modern Problem Statement, Use Cases, and Framework
draft-ietf-modern-problem-framework-02.txt draft-ietf-modern-problem-framework-03.txt
Abstract Abstract
The functions of the public switched telephone network (PSTN) are The functions of the public switched telephone network (PSTN) are
rapidly migrating to the Internet. This is generating new rapidly migrating to the Internet. This is generating new
requirements for many traditional elements of the PSTN, including requirements for many traditional elements of the PSTN, including
telephone numbers (TNs). TNs no longer serve simply as telephone telephone numbers (TNs). TNs no longer serve simply as telephone
routing addresses: they are now identifiers which may be used by routing addresses: they are now identifiers which may be used by
Internet-based services for a variety of purposes including session Internet-based services for a variety of purposes including session
establishment, identity verification, and service enablement. This establishment, identity verification, and service enablement. This
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Data Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Management Architectures . . . . . . . . . . . . . . 8 2.3. Data Management Architectures . . . . . . . . . . . . . . 8
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. CSP Acquires TNs from Registrar . . . . . . . . . . . 12 4.1.1. Acquiring TNs from Registrar . . . . . . . . . . . . 12
4.1.2. User Acquires TNs from CSP . . . . . . . . . . . . . 12 4.1.2. Acquiring TNs from CSPs . . . . . . . . . . . . . . . 13
4.1.3. CSP Delegates TNs to Another CSP . . . . . . . . . . 13
4.1.4. User Acquires TNs from a Delegate . . . . . . . . . . 13
4.1.5. User Acquires TNs from Registrar . . . . . . . . . . 14
4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Management of Administrative Data . . . . . . . . . . 14 4.2.1. Management of Administrative Data . . . . . . . . . . 14
4.2.1.1. CSP to Registrar . . . . . . . . . . . . . . . . 15 4.2.1.1. Managing Data at a Registrar . . . . . . . . . . 14
4.2.1.2. User to CSP . . . . . . . . . . . . . . . . . . . 15 4.2.1.2. Mangaing Data at a CSP . . . . . . . . . . . . . 15
4.2.1.3. User to Registrar . . . . . . . . . . . . . . . . 15 4.2.2. Management of Service Data . . . . . . . . . . . . . 15
4.2.2. Management of Service Data . . . . . . . . . . . . . 16 4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 15
4.2.2.1. CSP to other CSPs . . . . . . . . . . . . . . . . 16
4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16 4.2.2.2. User to CSP . . . . . . . . . . . . . . . . . . . 16
4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 17 4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 16
4.2.3.1. Changing the CSP for an Existing Communications 4.2.3.1. Changing the CSP for an Existing Service . . . . 16
Service . . . . . . . . . . . . . . . . . . . . . 17
4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17 4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17
4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18 4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 18
4.3.2. Retrieval of Semi-restricted Administrative Data . . 18 4.3.2. Retrieval of Semi-restricted Administrative Data . . 18
4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 19 4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 18
4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19 4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Informative References . . . . . . . . . . . . . . . . . . . 21 8. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Problem Statement 1. Problem Statement
The challenges of utilizing telephone numbers (TNs) on the Internet The challenges of utilizing telephone numbers (TNs) on the Internet
skipping to change at page 5, line 28 skipping to change at page 5, line 23
reserved, and which entities may obtain TNs. reserved, and which entities may obtain TNs.
Registry: An entity that administers the allocation of TNs based on Registry: An entity that administers the allocation of TNs based on
a Numbering Authority's policies. Numbering authorities can act a Numbering Authority's policies. Numbering authorities can act
as the Registries themselves, or they can outsource the function as the Registries themselves, or they can outsource the function
to other entities. Traditional registries are single entities to other entities. Traditional registries are single entities
with sole authority and responsibility for specific numbering with sole authority and responsibility for specific numbering
resources, though distributed registries (see Section 2.3) are resources, though distributed registries (see Section 2.3) are
also in the scope of this framework. 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 of 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 Registrar: An entity that distributes the telephone numbers
administered by a Registry; typically, there are many Registrars administered by a Registry; typically, there are many Registrars
that can distribute numbers from a single Registry, though that can distribute numbers from a single Registry, though
Registrars may serve multiple Registries as well. A Registrar has Registrars may serve multiple Registries as well. A Registrar has
business relationships with number assignees (defined below) and business relationships with number assignees and collects
collects administrative information from them. administrative information from them.
Communication Service Provider (CSP): A provider of communications Communication Service Provider (CSP): A provider of communications
services, where those services can be identified by TNs. This services, where those services can be identified by TNs. This
includes both traditional telephone carriers or enterprises as includes both traditional telephone carriers or enterprises as
well as service providers with no presence on the PSTN who use well as service providers with no presence on the PSTN who use
TNs. This framework does not assume that any single CSP provides TNs. This framework does not assume that any single CSP provides
all the communications service related to a particular TN. all the communications service related to a particular TN.
Service Enabler: An entity that works with CSPs to enable Service Enabler: An entity that works with CSPs to enable
communication service to a User; perhaps a vendor, a service communication service to a User; perhaps a vendor, a service
skipping to change at page 7, line 41 skipping to change at page 7, line 41
Administrative Data: assignment data related to the TN and the Administrative Data: assignment data related to the TN and the
relevant actors; it includes TN status (assigned, unassigned, relevant actors; it includes TN status (assigned, unassigned,
etc.), contact data for the assignee or delegate, and typically etc.), contact data for the assignee or delegate, and typically
does not require real-time access as this data is not required for does not require real-time access as this data is not required for
ordinary call or session establishment. ordinary call or session establishment.
Service Data: data necessary to enable service for the TN; it Service Data: data necessary to enable service for the TN; it
includes addressing data and service features. Since this data is includes addressing data and service features. Since this data is
necessary to complete calls, it must be obtained in real time. necessary to complete calls, it must be obtained in real time.
Administrative and service data can fit into three categories: Administrative and service data can fit into three access categories:
Public: Anyone can access public data. Such data might include a Public: Anyone can access public data. Such data might include a
list of which numbering resources (unallocated number ranges) are list of which numbering resources (unallocated number ranges) are
available for acquisition from the Registry. available for acquisition from the Registry.
Semi-restricted: Only a subset of actors can access semi-restricted 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. For example CSPs may be able to access other CSP's service
data. data in some closed environment.
Restricted: Only a small subset of actors can access restricted Restricted: Only a small subset of actors can access restricted
data. For example a Government Entity may be able access contact data. For example a Government Entity may be able access contact
information for a User. information for a User.
While it might appear there are really only two categories, public While it might appear there are really only two categories, public
and restricted based on requestor, the distinction between semi- and restricted based on requestor, the distinction between semi-
restricted and restricted is helpful for the use cases below. restricted and restricted is helpful for the use cases below.
2.3. Data Management Architectures 2.3. Data Management Architectures
skipping to change at page 12, line 5 skipping to change at page 12, line 5
relevant actors, that is, a CSP, Service Enabler, and a User. There relevant actors, that is, a CSP, Service Enabler, and a User. There
are three actors from which numbers can be acquired: a Registrar, a are three actors from which numbers can be acquired: a Registrar, a
CSP and a User (presumably one who is delegating to another party). CSP and a User (presumably one who is delegating to another party).
It is assumed that Registrars are either the same entity as It is assumed that Registrars are either the same entity as
Registries, or that Registrars have established business Registries, or that Registrars have established business
relationships with Registries that enable them to distribute the relationships with Registries that enable them to distribute the
numbers that the Registries administer. In these use cases, a User numbers that the Registries administer. In these use cases, a User
may acquire TNs either from a CSP or a Registry, or from an may acquire TNs either from a CSP or a Registry, or from an
intermediate delegate. intermediate delegate.
4.1.1. CSP Acquires TNs from Registrar 4.1.1. Acquiring TNs from Registrar
The most traditional number acquisition use case is one where a CSP, 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 such as a carrier, requests a block of numbers from a Registrar to
hold as inventory or assign to customers. hold as inventory or assign to customers.
Through some out-of-band business process, a CSP develops a Through some out-of-band business process, a CSP develops a
relationship with a Registrar. The Registrar maintains a profile of relationship with a Registrar. The Registrar maintains a profile of
the CSP and assesses whether or not CSPs meet the policy restrictions the CSP and assesses whether or not CSPs meet the policy restrictions
for acquiring TNs. The CSP may then request TNs from within a for acquiring TNs. The CSP may then request TNs from within a
specific pool of numbers in the authority of the Registry; such as specific pool of numbers in the authority of the Registry; such as
region, mobile, wireline, or freephone. The Registrar must region, mobile, wireline, or freephone. The Registrar must
authenticate and authorize the CSP, and then either grant or deny a authenticate and authorize the CSP, and then either grant or deny a
request. When an assignment occurs, the Registry creates and stores request. When an assignment occurs, the Registry creates and stores
administrative information related to the assignment such as TN administrative information related to the assignment such as TN
status and Registrar contact information, and removes the specific status and Registrar contact information, and removes the specific
TN(s) from the pool of those that are available for assignment. As a TN(s) from the pool of those that are available for assignment. As a
part of the acquisition and assignment process, the Registry provides part of the acquisition and assignment process, the Registry provides
any necessary credentials (for example, STIR certificates [17]) to to the Registrar any tokens or other material needed by a Credential
the Registrar to be used to prove the assignment for future Authority to issue credentials (for example, STIR certificates [17])
transactions. 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 Before it is eligible to receive TN assignments, per the policy of a
national authority, the CSP may need to have submitted (again, Numbering Authority, the CSP may need to have submitted (again,
through some out-of-band process) additional qualifying information through some out-of-band process) additional qualifying information
such as current utilization rate or a demand forecast. such as current utilization rate or a demand forecast.
There are two scenarios under which a CSP requests resources; they There are two scenarios under which a CSP requests resources; they
are requesting inventory, or they are requesting for a specific User are requesting inventory, or they are requesting for a specific User
or delegate. TNs assigned to a User are always considered assigned, or delegate. TNs assigned to a User are always considered assigned,
not inventory. The CSP will associate service information for that not inventory. The CSP will associate service information for that
TN, e.g., service address, and make it available to other CSPs to TN, e.g., service address, and make it available to other CSPs to
enable interconnection. The CSP may need to update the Registrar enable interconnection. The CSP may need to update the Registrar
regarding this service activation; this is part of the "TN status" regarding this service activation; this is part of the "TN status"
maintained by the Registrar. maintained by the Registrar.
4.1.2. User Acquires TNs from CSP 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, similarly to how such functions are conducted today when
Users purchase domain names. For the purpose of status information
kept by the Registry, TNs assigned to a User are always considered
assigned, not inventory.In this use case, after receiving a number
assignment from the Registrar, a User will then obtain communications
service from a CSP, and provide to the CSP the TN to be used for that
service. The CSP will associate service information for that TN,
e.g., service address, and make it available to other CSPs to enable
interconnection. The user will also need to inform the Registrar
about this relationship.
4.1.2. Acquiring TNs from CSPs
Today, a User typically acquires a TN from CSP when signing up for Today, a User typically acquires a TN from CSP when signing up for
communications service or turning on a new device. In this use case, communications service or turning on a new device. In this use case,
the User becomes the delegate of the CSP. 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.
A User creates or has a relationship with the CSP, and subscribes to Consider a case where a User creates or has a relationship with the
a communications service which includes the use of a TN. The CSP CSP, and subscribes to a communications service which includes the
collects and stores administrative data about the User. The CSP then use of a TN. The CSP collects and stores administrative data about
activates the User on their network and creates any necessary service the User. The CSP then activates the User on their network and
data to enable connectivity with other CSPs. The CSP could also creates any necessary service data to enable connectivity with other
update public or privileged databases accessible by other Actors. 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 [17]) 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.
The CSP provides any necessary credentials to the User (for example, Virtually the same flow would work for a reseller: it would form a
a STIR certificate [17]) to prove the assignment for future business relationship with the CSP, at which point the CSP would
transactions. Such credential could be delegated from the one collect and store administrative data about the reseller and give the
provided by the Registrar to the CSP to continue the chain of reseller any material needed for the reseller to acquire credentials
assignment. for the numbers. A user might then in turn acquire numbers from the
reseller: in this case, the delegate re-delegating the TNs would be
performing functions done by the CSP, e.g., providing any
credentials, collecting administrative data, or creative service
data.
The CSP could assign a TN from its existing inventory or it could 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 acquire a new TN from the Registrar as part of the assignment
process. If it assigns it from its existing inventory, it would process. If it assigns it from its existing inventory, it would
remove the specific TN from the pool of those available for remove the specific TN from the pool of those available for
assignment. It may also update the Registrar about the assignment so assignment. It may also update the Registrar about the assignment so
the Registrar has current assignment data. the Registrar has current assignment data. If a reseller or delegate
CSP is acquiring the numbers, it may have the same obligations to
4.1.3. CSP Delegates TNs to Another CSP provide utilization data to the Registry as the assignee, per
Section 4.1.1.
A reseller or a service bureau might acquire a block of numbers from
a CSP to be issued to Users.
In this case, the delegate CSP (as defined in Section 2.1) has a
business relationship with the assignee CSP. The assignee CSP
collects and stores administrative data about the delegate. The
assignee then activates the delegate on their network and creates any
necessary service data to enable interconnection with other CSPs.
The CSP could also update public or privileged databases accessible
by other Actors. The CSP provides any necessary credentials to the
delegate CSP (for example, a STIR certificate [17]) to prove the
assignment for future transactions. Such credentials could be
delegated from the one provided by the Registry to the CSP to
continue the chain of assignment.
The CSP could assign a block from its existing inventory or it could
acquire new TNs from the Registrar as part of the assignment process.
If it assigns it from its existing inventory it would remove the
specific TN from the pool of those available for assignment. It may
also update the Registrar about the assignment so the Registrar has
current assignment data. The delegate may have the same obligations
to provide utilization data to the Registry as the assignee, per
Section 4.1.1
4.1.4. User Acquires TNs from a Delegate
Acquiring a TN from a delegate follows the process in Section 4.1.2,
as it should be similar to how a User acquires TNs from a CSP. But
in this case, the delegate re-delegating the TNs would be performing
functions done by the CSP, e.g., providing any credentials,
collecting administrative data, or creative service data.
4.1.5. User Acquires TNs from Registrar
Today, a user wishing to acquire a freephone number may browse the
existing inventory through one or more Registrars, comparing their
prices and services. Each such Registrar either is a CSP, or has a
business relationship with one or more CSPs to provide services for
that freephone number.
Acquiring a TN from a Registrar follows the process in Section 4.1.1,
as it should be similar to how a CSP acquires TNs from a Registrar.
In this case, the User must establish some business relationship
directly with a Registrar, similarly to how such functions are
conducted today when Users purchase domain names. For the purpose of
status information kept by the Registry, TNs assigned to a User are
always considered assigned, not inventory.
In this use case, after receiving a number assignment from the
Registrar, a User will then obtain communications service from a CSP,
and provide to the CSP the TN to be used for that service. The CSP
will associate service information for that TN, e.g., service
address, and make it available to other CSPs to enable
interconnection. The user will also need to inform the Registrar
about this relationship (see Section 4.2.1.3).
4.2. Management 4.2. Management
The management protocol mechanism is needed to associate The management protocol mechanism is needed to associate
administrative and service data with TNs, and may be used to refresh administrative and service data with TNs, and may be used to refresh
or rollover associated credentials. or rollover associated credentials.
4.2.1. Management of Administrative Data 4.2.1. Management of Administrative Data
Administrative data is primarily related to the status of the TN, its Administrative data is primarily related to the status of the TN, its
skipping to change at page 15, line 5 skipping to change at page 14, line 31
Some administrative data may be private, and would thus require Some administrative data may be private, and would thus require
special handling in a distributed data store model. Access to it special handling in a distributed data store model. Access to it
does not require real-time performance therefore local caches are not does not require real-time performance therefore local caches are not
necessary. And it will include sensitive information such as user necessary. And it will include sensitive information such as user
and contact data. and contact data.
Some of the data could lend itself to being publicly available, such 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 as CSP and TN assignment status. In that case it would be deemed
public information for the purposes of the retrieval interface. public information for the purposes of the retrieval interface.
4.2.1.1. CSP to Registrar 4.2.1.1. Managing Data at a Registrar
After a CSP acquires a TN or block of TNs from the Registrar (per After a CSP acquires a TN or block of TNs from the Registrar (per
Section 4.1.1 above), it then provides administrative data to the Section 4.1.1 above), it then provides administrative data to the
Registrar as a step in the acquisition process. The Registrar will Registrar as a step in the acquisition process. The Registrar will
authenticate the CSP and determine if the CSP is authorized to authenticate the CSP and determine if the CSP is authorized to
provision the administrative data for the TNs in question. The provision the administrative data for the TNs in question. The
Registry will update the status of the TN, i.e., that it is Registry will update the status of the TN, i.e., that it is
unavailable for assignment. The Registrar will also maintain unavailable for assignment. The Registrar will also maintain
administrative data provided by the CSP. administrative data provided by the CSP.
Changes to this administrative data will not be frequent. Examples Changes to this administrative data will not be frequent. Examples
of changes would be terminating service (see Section 4.2.3.2), 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 changing the name or address of a User or organization, or changing a
CSP or delegate. Changes should be authenticated by a credential to CSP or delegate. Changes should be authenticated by a credential to
prove administrative responsibility for the TN. prove administrative responsibility for the TN.
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 Registrar may or may not also act as
a CSP. In these cases the updates would be similar to that described
in Section 4.2.1.1.
In a distributed Registry model, TN status, e.g., allocated, In a distributed Registry model, TN status, e.g., allocated,
assigned, available, unavailable, would need to be provided to other assigned, available, unavailable, would need to be provided to other
Registries in real-time. Other administrative data could be sent to Registries in real-time. Other administrative data could be sent to
all Registries or other Registries could get a reference address to all Registries or other Registries could get a reference address to
the host Registry's data store. the host Registry's data store.
4.2.1.2. User to CSP 4.2.1.2. Mangaing Data at a CSP
After a User acquires a TN or block of TNs from a CSP, the User will 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 provide administrative data to the CSP. The CSP commonly acts as a
Registrar in this case, maintaining the administrative data and only Registrar in this case, maintaining the administrative data and only
notifies the Registry of the change in TN status. In this case, the notifies the Registry of the change in TN status. In this case, the
Registry maintains a reference address (see Section 2.3) to the CSP/ Registry maintains a reference address (see Section 2.3) to the CSP/
Registrar's administrative data store so relevant actors have the Registrar's administrative data store so relevant actors have the
ability to access the data. Alternatively, a CSP could send the ability to access the data. Alternatively, a CSP could send the
administrative data to an external Registrar to store. If there is a 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 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. a mechanism for the delegate to update the CSP as change occurs.
4.2.1.3. User to Registrar
If the User has a direct relationship with the Registrar, then
naturally the user could provision administrative data associated
with their TN directly to the Registrar. This is the case, for
example, with the freephone example, where a User has a business
relationship with its freephone provider, and the freephone provider
maintains account and billing data. While delegates 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 Registrar may or may not also act as
a CSP. In these cases the updates would be similar to that described
in Section 4.2.1.1.
4.2.2. Management of Service Data 4.2.2. Management of Service Data
Service data is data required by an originating or intermediate CSP Service data is data required by an originating or intermediate CSP
to enable communications service to a User: a SIP URI is an example to enable communications service to a User: a SIP URI is an example
of one service data element commonly used to route communications. of one service data element commonly used to route communications.
CSPs typically create and manage service data, however, it is CSPs typically create and manage service data, however, it is
possible that delegates and Users could as well. For most use cases possible that delegates and Users could as well. For most use cases
involving individual Users, it is anticipated that lower-level involving individual Users, it is anticipated that lower-level
service information changes (such as an end-user device receiving a service information changes (such as an end-user device receiving a
new IP address) would be communicated to CSPs via existing protocols. new IP address) would be communicated to CSPs via existing protocols.
skipping to change at page 16, line 32 skipping to change at page 16, line 8
4.2.2.1. CSP to other CSPs 4.2.2.1. CSP to other CSPs
After a User enrolls for service with a CSP, in the case where the 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 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 service address such as a SIP URI and associate it with the TN. The
CSP needs to update this data to enable service interoperability. CSP needs to update this data to enable service interoperability.
There are multiple ways that this update can occur, though most There are multiple ways that this update can occur, though most
commonly service data is exposed through the retrieval interface (see commonly service data is exposed through the retrieval interface (see
Section 4.3). For certain deployment architectures, like a Section 4.3). For certain deployment architectures, like a
distributed data store model, CSPs may need to provide data directly distributed data store model, CSPs may need to provision data
to other CSPs. directly to other CSPs.
If the CSP is assigning a TN from its own inventory it may not need 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 to perform service data updates as change occurs because the existing
service data associated with inventory may be sufficient once the TN service data associated with inventory may be sufficient once the TN
is put in service. They would however likely update the Registry on is put in service. They would however likely update the Registry on
the change in status. the change in status.
4.2.2.2. User to CSP 4.2.2.2. User to CSP
Users could also associate service data to their TNs at the CSP. An Users could also associate service data to their TNs at the CSP. An
example is a User acquires a TN from the Registrar (as described in example is a User acquires a TN from the Registrar (as described in
Section 4.1.5) and wants to provide that TN to the CSP so the CSP can Section 4.1.1) and wants to provide that TN to the CSP so the CSP can
enable service. In this case, once the user provides the number to enable service. In this case, once the user provides the number to
the CSP, the CSP would update the Registry or other actors as the CSP, the CSP would update the Registry or other actors as
outlined in Section 4.2.2.1. outlined in Section 4.2.2.1.
4.2.3. Managing Change 4.2.3. Managing Change
This section will address some special use cases that were not This section will address some special management use cases that were
covered in other sections of 4.2. not covered above.
4.2.3.1. Changing the CSP for an Existing Communications Service 4.2.3.1. Changing the CSP for an Existing Service
A User who subscribes to a communications service, and received their Consider the case where a User who subscribes to a communications
TN from that CSP, wishes to retain the same TN but move their service service, and received their TN from that CSP, wishes to retain the
to a different CSP. The User provides their credential to the new same TN but move their service to a different CSP.
CSP and the CSP initiates the change in service
In the simplest scenario, where there's an authoritative combined In the simplest scenario, where there's an authoritative combined
Registry/Registrar that maintains service data, the new CSP provides Registry/Registrar that maintains service data, the User could
the new service data with the User's credential to the Registry/ provide their credential to the new CSP and let the CSP initiate the
Registrar, which then makes the change. The old credential is change in service. The new CSP could then provide the new service
revoked and a new one is provided. The new CSP or the Registrar data with the User's credential to the Registry/Registrar, which then
would send a notification to the old CSP, so they can disable makes the change. The old credential is revoked and a new one is
service. The old CSP will undo any delegations to the User, provided. The new CSP or the Registrar would send a notification to
including invalidating any cryptographic credentials (e.g., STIR the old CSP, so they can disable service. The old CSP will undo any
certificates [13]) previously granted to the User. Any service data delegations to the User, including contacting the Credential
Authority to revoke any cryptographic credentials (e.g., STIR
certificates [17]) previously granted to the User. Any service data
maintained by the CSP must be removed, and similarly, the CSP must maintained by the CSP must be removed, and similarly, the CSP must
delete any such information it provisioned in the Registry. delete any such information it provisioned in the Registry.
In a similar model to common practice in some environments today, the In a similar model to common practice in some environments today, the
User could provide their credential to the old CSP, and the old CSP User could alternatively provide their credential to the old CSP, and
initiates the change in service. Alternatively, a User could go the old CSP initiates the change in service. Or, a User could go
directly to a Registrar to initiate a port. The framework should directly to a Registrar to initiate a port. This framework should
support all of these potential flows. support all of these potential flows.
Note that in cases with a distributed Registry that maintained Note that in cases with a distributed Registry that maintained
service data, the Registry would also have to update the other service data, the Registry would also have to update the other
Registries of the change. Registries of the change.
4.2.3.2. Terminating a Service 4.2.3.2. Terminating a Service
A User who subscribes to a communications service, and received their Consider a case where a user who subscribes to a communications
TN from the CSP, wishes to terminate their service. At this time, service, and received their TN from the CSP, wishes to terminate
the CSP will undo any delegations to the User, including invalidating their service. At this time, the CSP will undo any delegations to
any cryptographic credentials (e.g., STIR certificates [13]) the User, which may involve contacting the Credential Authority to
revoke any cryptographic credentials (e.g., STIR certificates [17])
previously granted to the User. Any service data maintained by the previously granted to the User. Any service data maintained by the
CSP must be removed, and similarly, the CSP must delete any such CSP must be removed, and similarly, the CSP must delete any such
information it provisioned in the Registrar. However, per the policy information it provisioned in the Registrar. However, per the policy
of the Numbering Authority, Registrars and CSPs may be required to of the Numbering Authority, Registrars and CSPs may be required to
preserve historical data that will be accessible to Government preserve historical data that will be accessible to Government
Entities or others through audits, even if it is no longer Entities or others through audits, even if it is no longer
retrievable through service interfaces. retrievable through service interfaces.
The TN will change state from assigned to unassigned, the CSP will The TN will change state from assigned to unassigned, the CSP will
update the Registry. Depending on policies the TN could go back into update the Registry. Depending on policies the TN could go back into
skipping to change at page 18, line 23 skipping to change at page 17, line 48
the Registrar, and return the TN to the Registry for re-assignment. the Registrar, and return the TN to the Registry for re-assignment.
Alternatively, they could retain the TN and elect to assign it to Alternatively, they could retain the TN and elect to assign it to
some other service at a later time. some other service at a later time.
4.3. Retrieval 4.3. Retrieval
Retrieval of administrative or service data will be subject to access Retrieval of administrative or service data will be subject to access
restrictions based on the category of the specific data: public, restrictions based on the category of the specific data: public,
semi-restricted or restricted. Both administrative and service data semi-restricted or restricted. Both administrative and service data
can have data elements that fall into each of these categories. It can have data elements that fall into each of these categories. It
is expected that the majority of administrative and service data will is expected that the majority of administrative will fall into the
fall into the semi-restricted category: access to this information semi-restricted category: access to this information may require some
may require some form of authorization, though service data crucial form of authorization, though service data crucial to reachability
to reachability will need to be accessible. In some environments, will need to be accessible. In some environments, it's possible that
it's possible that none of the service data will be considered none of the service data necessary to initiate communications will be
public. useful to an entity on the public Internet, say, or that all that
service data will have dependencies on .
The retrieval protocol mechanism for semi-restricted and restricted The retrieval protocol mechanism for semi-restricted and restricted
data needs a way for the receiver of the request to identify the data needs a way for the receiver of the request to identify the
originator of the request and what is being requested. The receiver originator of the request and what is being requested. The receiver
of the request will process that request based on this information. of the request will process that request based on this information.
4.3.1. Retrieval of Public Data 4.3.1. Retrieval of Public Data
Under most circumstances, a CSP wants its communications service to Eithert administrative or service data may be made publicly available
be publicly reachable through TNs, so the retrieval interface by the authority that generates and provisions it. Under most
supports public interfaces that permit clients to query for service circumstances, a CSP wants its communications service to be publicly
data about a TN. Some service data may however require that the reachable through TNs, so the retrieval interface supports public
client be authorized to receive it, per the use case in Section 4.3.3 interfaces that permit clients to query for service data about a TN.
below. Some service data may however require that the client be authorized
to receive it, per the use case in Section 4.3.3 below.
Public data can simply be posted on websites or made available Public data can simply be posted on websites or made available
through a publicly available API. Public data hosted by a CSP may through a publicly available API. Public data hosted by a CSP may
have a reference address at the Registry. have a reference address at the Registry.
4.3.2. Retrieval of Semi-restricted Administrative Data 4.3.2. Retrieval of Semi-restricted Administrative Data
Consider a case in which a CSP is having service problems completing 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 calls to a specific TN, so it wants to contact the CSP serving that
TN. The Registry authorizes the originating CSP to access this TN. The Registry authorizes the originating CSP to access this
information. It initiates a query to the Registry, the Registry information. It initiates a query to the Registry, the Registry
verifies the requestor and the requested data and Registry responds verifies the requestor and the requested data and Registry responds
with the serving CSP and contact data. 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 Alternatively that information could be part of a distributed data
store and not stored at the Registry. In that case, the CSP has the store and not stored at a monolithic Registry. In that case, the CSP
data in a local distributed data store and it initiates the query to has the data in a local distributed data store and it initiates the
the local data store. The local data store responds with the CSP and query to the local data store. The local data store responds with
contact data. No verification is necessary because it was done when the CSP and contact data. No verification is necessary because it
the CSP was authorized to receive the data store. was done when the CSP was authorized to receive the data store.
4.3.3. Retrieval of Semi-restricted Service Data 4.3.3. Retrieval of Semi-restricted Service Data
A User on a CSP's network calls a TN. The CSP initiates a query for Consider a case where a User on a CSP's network calls a TN. The CSP
service data associated with the TN to complete the call, and will initiates a query for service data associated with the TN to complete
receive special service data because the CSP operates in a closed the call, and will receive special service data because the CSP
environment where different CSPs receive different responses, and operates in a closed environment where different CSPs receive
only authorized CSPs may access service data. The query and response different responses, and only participating CSPs can initiate
must have real-time performance. communications. This service data would be flagged as semi-
restricted. The query and response have real-time performance
requirements in that environment.
In a distributed data store model each CSP distributes its updated Semi-restricted service data also works in a distributed data store
service data to all other CSPs. The originating CSP has the service model, where each CSP distributes its updated service data to all
data in its local data store and queries it. The local data store other CSPs. The originating CSP has the service data in its local
responds with the service data. The service data in the response can data store and queries it. The local data store responds with the
be a reference address to a data store maintained by the serving CSP, service data. The service data in the response can be a reference
or it can be the service address itself. In the case where the address to a data store maintained by the serving CSP, or it can be
response gives a reference address, a subsequent query would go to the service address itself. In the case where the response gives a
the serving CSP, who would in turn authorize the requestor for the reference address, a subsequent query would go to the serving CSP,
requested data and respond appropriate. In the case where the who would in turn authorize the requestor for the requested data and
original response contains the service address, the requestor would respond appropriate. In the case where the original response
use that service address as the destination for the call. 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 In some environments, aspects of the service data may reside at the
Registry itself (for example, the assigned CSP for a TN), and thus Registry itself (for example, the assigned CSP for a TN), and thus
the query may be sent to the Registry. The Registry verifies the the query may be sent to the Registry. The Registry verifies the
requestor and the requested data and responds with the service data, requestor and the requested data and responds with the service data,
such as a SIP URI containing the domain of the assigned CSP. such as a SIP URI containing the domain of the assigned CSP.
4.3.4. Retrieval of Restricted Data 4.3.4. Retrieval of Restricted Data
A Government Entity wishes to access information about a particular A Government Entity wishes to access information about a particular
User, who subscribes to a communications service. The entity that User, who subscribes to a communications service. The entity that
operates the Registry on behalf of the National Authority in this operates the Registry on behalf of the Numbering Authority in this
case has some pre-defined relationship with the Government Entity. case has some pre-defined relationship with the Government Entity.
When the CSP acquired TNs from the National Authority, it was a When the CSP acquired TNs from the Numbering Authority, it was a
condition of that assignment that the CSP provide access for condition of that assignment that the CSP provide access for
Government Entities to telephone numbering data when certain Government Entities to telephone numbering data when certain
conditions apply. The required data may reside either in the CSP or conditions apply. The required data may reside either in the CSP or
in the Registrar. in the Registrar.
For a case where the CSP delegates a number to the User, the CSP 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 might provision the Registrar (or itself, if the CSP is composed with
a Registrar) with information relevant to the User. At such a time a Registrar) with information relevant to the User. At such a time
as the Government Entity needs information about that User, the as the Government Entity needs information about that User, the
Government Entity may contact the Registrar or CSP to acquire the Government Entity may contact the Registrar or CSP to acquire the
necessary data. The interfaces necessary for this will be the same necessary data. The interfaces necessary for this will be the same
as those described in Section 4.3; the Government Entity will be as those described in Section 4.3; the Government Entity will be
authenticated, and an authorization decision will be made by the authenticated, and an authorization decision will be made by the
Registrar or CSP under the policy dictates established by the Registrar or CSP under the policy dictates established by the
National Authority. Numbering Authority.
5. Acknowledgments 5. Acknowledgments
We would like to thank Henning Schulzrinne and Adam Roach for their We would like to thank Henning Schulzrinne and Adam Roach for their
contributions to this problem statement and framework, and to thank contributions to this problem statement and framework, and to thank
Pierce Gorman for detailed comments. Pierce Gorman for detailed comments.
6. IANA Considerations 6. IANA Considerations
This memo includes no instructions for the IANA. This memo includes no instructions for the IANA.
skipping to change at page 22, line 52 skipping to change at page 22, line 39
[15] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [15] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<http://www.rfc-editor.org/info/rfc3912>. <http://www.rfc-editor.org/info/rfc3912>.
[16] Peterson, J., "An Architecture and Information Model for [16] Peterson, J., "An Architecture and Information Model for
Telephone-Related Information (TeRI)", draft-peterson- Telephone-Related Information (TeRI)", draft-peterson-
modern-teri-02 (work in progress), October 2016. modern-teri-02 (work in progress), October 2016.
[17] Peterson, J. and S. Turner, "Secure Telephone Identity [17] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", draft-ietf-stir- Credentials: Certificates", draft-ietf-stir-
certificates-11 (work in progress), October 2016. certificates-14 (work in progress), May 2017.
[18] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- [18] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit-
Huguenin, "Verification Involving PSTN Reachability: Huguenin, "Verification Involving PSTN Reachability:
Requirements and Architecture Overview", draft-jennings- Requirements and Architecture Overview", draft-jennings-
vipr-overview-06 (work in progress), December 2013. vipr-overview-06 (work in progress), December 2013.
[19] Bellur, H. and C. Wendt, "Distributed Registry Protocol", [19] Bellur, H. and C. Wendt, "Distributed Registry Protocol",
draft-wendt-modern-drip-01 (work in progress), July 2016. draft-wendt-modern-drip-01 (work in progress), July 2016.
[20] Rosenberg, J. and H. Schulzrinne, "Session Initiation [20] Rosenberg, J. and H. Schulzrinne, "Session Initiation
 End of changes. 43 change blocks. 
183 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/