< draft-ietf-modern-problem-framework-01.txt		draft-ietf-modern-problem-framework-02.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: January 8, 2017 July 7, 2016		Expires: September 14, 2017 March 13, 2017
	Modern Problem Statement, Use Cases, and Framework		Modern Problem Statement, Use Cases, and Framework
	draft-ietf-modern-problem-framework-01.txt		draft-ietf-modern-problem-framework-02.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
	problem statement examines how the existing tools for allocating and		problem statement examines how the existing tools for allocating and
	managing telephone numbers do not align with the use cases of the		managing telephone numbers do not align with the use cases of the
	Internet environment, and proposes a framework for Internet-based		Internet environment, and proposes a framework for Internet-based
	services relying on TNs.		services relying on TNs.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	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 January 8, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11		4.1. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.1. CSP Acquires TNs from Registrar . . . . . . . . . . . 11		4.1.1. CSP Acquires TNs from Registrar . . . . . . . . . . . 12
	4.1.2. User Acquires TNs from CSP . . . . . . . . . . . . . 12		4.1.2. User Acquires TNs from CSP . . . . . . . . . . . . . 12
	4.1.3. CSP Delegates TNs to Another CSP . . . . . . . . . . 12		4.1.3. CSP Delegates TNs to Another CSP . . . . . . . . . . 13
	4.1.4. User Acquires TNs from a Delegate . . . . . . . . . . 13		4.1.4. User Acquires TNs from a Delegate . . . . . . . . . . 13
	4.1.5. User Acquires Numbers from Registrar . . . . . . . . 13		4.1.5. User Acquires TNs from Registrar . . . . . . . . . . 14
	4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 13		4.2. Management . . . . . . . . . . . . . . . . . . . . . . . 14
	4.2.1. Management of Administrative Data . . . . . . . . . . 13		4.2.1. Management of Administrative Data . . . . . . . . . . 14
	4.2.1.1. CSP to Registrar . . . . . . . . . . . . . . . . 14		4.2.1.1. CSP to Registrar . . . . . . . . . . . . . . . . 15
	4.2.1.2. User to CSP . . . . . . . . . . . . . . . . . . . 14		4.2.1.2. User to CSP . . . . . . . . . . . . . . . . . . . 15
	4.2.1.3. User to Registrar . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 16		4.2.3. Managing Change . . . . . . . . . . . . . . . . . . . 17
	4.2.3.1. Changing the CSP for an Existing Communications		4.2.3.1. Changing the CSP for an Existing Communications
	Service . . . . . . . . . . . . . . . . . . . . . 16		Service . . . . . . . . . . . . . . . . . . . . . 17
	4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 16		4.2.3.2. Terminating a Service . . . . . . . . . . . . . . 17
	4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 17		4.3. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.3.1. Retrieval of Public Data . . . . . . . . . . . . . . 17		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 . . . . . . 18		4.3.3. Retrieval of Semi-restricted Service Data . . . . . . 19
	4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 18		4.3.4. Retrieval of Restricted Data . . . . . . . . . . . . 19
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8. Informative References . . . . . . . . . . . . . . . . . . . 20		8. Informative References . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		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
	have been known for some time. Internet telephony provided the first		have been known for some time. Internet telephony provided the first
	use case for routing telephone numbers on the Internet in a manner		use case for routing telephone numbers on the Internet in a manner
	similar to how calls are routed in the public switched telephone		similar to how calls are routed in the public switched telephone
	network (PSTN). As the Internet had no service for discovering the		network (PSTN). As the Internet had no service for discovering the
	endpoints associated with telephone numbers, ENUM [3] created a DNS-		endpoints associated with telephone numbers, ENUM [3] created a DNS-
	based mechanism for resolving TNs in an IP environment, by defining		based mechanism for resolving TNs in an IP environment, by defining
	procedures for translating TNs into URIs for use by protocols such as		procedures for translating TNs into URIs for use by protocols such as
	SIP [2]. The resulting database was designed to function in a manner		SIP [2]. The resulting database was designed to function in a manner
	similar to the systems that route calls in the PSTN. Originally, it		similar to the systems that route calls in the PSTN. Originally, it
	was envisioned that ENUM would be deployed as a global hierarchical		was envisioned that ENUM would be deployed as a global hierarchical
	service, though in practice, it has only been deployed piecemeal by		service, though in practice, it has only been deployed piecemeal by
	various parties. Most notably, ENUM is used as an internal network		various parties. Most notably, ENUM is used as an internal network
	function, and is hardly used between service provider networks. The		function, and is rarely used between service provider networks. The
	original ENUM concept of a single root, e164.arpa, proved to be		original ENUM concept of a single root, e164.arpa, proved to be
	politically and practically challenging, and less centralized models		politically and practically challenging, and less centralized models
	have thus flourished. Subsequently, the DRINKS [4] framework showed		have thus flourished. Subsequently, the DRINKS [4] framework showed
	ways that authorities might provision information about TNs at an		ways that service providers might provision information about TNs at
	ENUM service or similar Internet-based directory. These technologies		an ENUM service or similar Internet-based directory. These
	have also generally tried to preserve the features and architecture		technologies have also generally tried to preserve the features and
	familiar to the PSTN numbering environment.		architecture familiar to the PSTN numbering environment.
	Over time, Internet telephony has encompassed functions that differ		Over time, Internet telephony has encompassed functions that differ
	substantially from traditional PSTN routing and management,		substantially from traditional PSTN routing and management,
	especially as non-traditional providers have begun to utilize		especially as non-traditional providers have begun to utilize
	numbering resources. An increasing number of enterprises, over-the-		numbering resources. An increasing number of enterprises, over-the-
	top Voice over IP providers, text messaging services, and related		top voice-over-IP (VoIP) providers, text messaging services, and
	non-carrier services have become heavy users of telephone numbers.		related non-carrier services have become heavy users of telephone
	An enterprise, for example, could deploy an IP PBX that receives a		numbers. An enterprise, for example, can deploy an IP PBX that
	block of telephone numbers from a carrier and then in turn distribute		receives a block of telephone numbers from a carrier and then in turn
	those numbers to new IP telephones when they associate with the PBX.		distribute those numbers to new IP telephones when they associate
	Internet services offer users portals where they can allocate new		with the PBX. Internet services offer users portals where they can
	telephone numbers on the fly, assign multiple "alias" telephone		allocate new telephone numbers on the fly, assign multiple "alias"
	numbers to a single line service, implement various mobility or find-		telephone numbers to a single line service, implement various
	me-follow-me applications, and so on. Peer-to-peer telephone		mobility or find-me-follow-me applications, and so on. Peer-to-peer
	networks have encouraged experiments with distributed databases for		telephone networks have encouraged experiments with distributed
	telephone number routing and even allocation.		databases for telephone number routing and even allocation.
	This dynamic control over telephone numbers has few precedents in the		This dynamic control over telephone numbers has few precedents in the
	traditional PSTN outside of number portability. Number portability		traditional PSTN outside of number portability. Number portability
	has been implemented in many countries, and the capability of a user		allows the capability of a user to choose and change their service
	to choose and change their service provider while retaining their TN		provider while retaining their TN; it has been implemented in many
	is widely implemented now. However, TN administration processes		countries; either for all telephony services or for subsets such as
	rooted in PSTN technology and policies dictate that this be an		mobile. However, TN administration processes rooted in PSTN
	exception process fraught with problems and delays. Originally,		technology and policies dictate that this be an exception process
	processes were built to associate a specific TN to a specific service		fraught with problems and delays. Originally, processes were built
	provider and never change it. With number portability, the industry		to associate a specific TN to a specific service provider and never
	had to build new infrastructure, new administrative functions and		change it. With number portability, the industry had to build new
	processes to change the association of the TN from one service		infrastructure, new administrative functions and processes to change
	provider to another. Thanks to the increasing sophistication of		the association of the TN from one service provider to another.
	consumer mobile devices as Internet endpoints as well as telephones,		Thanks to the increasing sophistication of consumer mobile devices as
	users now associate TNs with many Internet applications other than		Internet endpoints as well as telephones, users now associate TNs
	telephony. This has generated new interest in models similar to		with many Internet applications other than telephony. This has
	those in place for administering freephone services in the United		generated new interest in models similar to those in place for
	States, where a user purchases a number through a sort of number		administering freephone services in the United States, where a user
	registrar and controls its administration (such as routing) on their		purchases a number through a sort of number registrar and controls
	own, typically using Internet services to directly make changes to		its administration (such as routing) on their own, typically using
	the service associated with telephone numbers.		Internet services to directly make changes to the service associated
			with telephone numbers.
	Most TNs today are assigned to specific geographies, at both an		Most TNs today are assigned to specific geographies, at both an
	international level and within national numbering plans. Numbering		international level and within national numbering plans. Numbering
	practices today are tightly coupled with the manner that service		practices today are tightly coupled with the manner that service
	providers interconnect, as well as how TNs are routed and		providers interconnect, as well as how TNs are routed and
	administered: the PSTN was carefully designed to delegate switching		administered: the PSTN was carefully designed to delegate switching
	intelligence geographically. In interexchange carrier routing in		intelligence geographically. In interexchange carrier routing in
	North America, for example, calls to a particular TN are often handed		North America, for example, calls to a particular TN are often handed
	off to the terminating service provider close to the geography where		off to the terminating service provider close to the geography where
	that TN is assigned. But the overwhelming success of mobile		that TN is assigned. But the overwhelming success of mobile
	telephones has increasing eroded the connection between numbers and		telephones has increasingly eroded the connection between numbers and
	regions. Furthermore, the topology of IP networks is not anchored to		regions. Furthermore, the topology of IP networks is not anchored to
	geography in the same way that the telephone network is. In an		geography in the same way that the telephone network is. In an
	Internet environment, establishing a network architecture for routing		Internet environment, establishing a network architecture for routing
	TNs could depend little on geography. Adapting TNs to the Internet		TNs could depend little on geography, relying instead on network
	requires more security, richer datasets and more complex query and		topologies or other architectural features. Adapting TNs to the
	response capabilities than previous efforts have provided.		Internet requires more security, richer datasets and more complex
			query and response capabilities than previous efforts have provided.
	This document will create a common understanding of the problem		This document attempts to create a common understanding of the
	statement related to allocating, managing, and resolving TNs in an IP		problem statement related to allocating, managing, and resolving TNs
	environment. It outlines a framework and lists motivating use cases		in an IP environment. It outlines a framework and lists motivating
	for creating IP-based mechanisms for TNs. It is important to		use cases for creating IP-based mechanisms for TNs. It is important
	acknowledge at the outset that there are various evolving		to acknowledge at the outset that there are various evolving
	international and national policies and processes related to TNs, and		international and national policies and processes related to TNs, and
	any solutions need to be flexible enough to account for variations in		any solutions need to be flexible enough to account for variations in
	policy and requirements.		policy and requirements.
	2. Definitions		2. Definitions
	This section provides definitions for actors, data types and data		This section provides definitions for actors, data types and data
	management architectures as they are discussed in this document.		management architectures as they are discussed in this document.
	Different numbering spaces may instantiate these roles and concepts		Different numbering spaces may instantiate these roles and concepts
	differently: practices that apply to non-geographic freephone		differently: practices that apply to non-geographic freephone
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 17 ¶
	diverse requirements for telephone number acquisition, management,		diverse requirements for telephone number acquisition, management,
	and retrieval on the Internet.		and retrieval on the Internet.
	2.1. Actors		2.1. Actors
	The following roles of actors are defined in this document:		The following roles of actors are defined in this document:
	Numbering Authority: A regulatory body within a country that manages		Numbering Authority: A regulatory body within a country that manages
	that country's TNs. The Numbering Authority decides national		that country's TNs. The Numbering Authority decides national
	numbering policy for the nation, region, or other domain for which		numbering policy for the nation, region, or other domain for which
	it has authority, including what TNs can be allocated, and which		it has authority, including what TNs can be allocated, which are
	are reserved.		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. There are two subtypes of Registries: an		to other entities. Traditional registries are single entities
	Authoritative Registry and a Distributed Registry. The general		with sole authority and responsibility for specific numbering
	term Registry in this document refers to both kinds of Registries.		resources, though distributed registries (see Section 2.3) are
			also in the scope of this framework.
	Authoritative Registry: An authoritative Registry is a single entity
	with sole responsibility for specific numbering resources.
	Distributed Registry: Distributed Registries are multiple Registries
	responsible for the same numbering resources.
	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, through		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 its assignees and collects		business relationships with number assignees (defined below) and
	administrative information from them.		collects 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, or third-party		communication service to a User; perhaps a vendor, a service
	integrator.		bureau, or third-party integrator.
	User: An individual reachable through a communications service;		User: An individual reachable through a communications service;
	usually a customer of a communication service provider.		usually a customer of a communication service provider.
	Government Entity: An entity that, due to legal powers deriving from		Government Entity: An entity that, due to legal powers deriving from
	national policy, has privileged access to information about number		national policy, has privileged access to information about number
	administration under certain conditions.		administration under certain conditions.
	Note that an individual, company or other entity may act in one or		Note that an individual, organization, or other entity may act in one
	more of the roles above; for example, a company may be a CSP and also		or more of the roles above; for example, a company may be a CSP and
	a Registrar. Although Numbering Authorities are listed as actors,		also a Registrar. Although Numbering Authorities are listed as
	they are unlikely to actually participate in the protocol flows		actors, they are unlikely to actually participate in the protocol
	themselves, though in some situations a Numbering Authority and		flows themselves, though in some situations a Numbering Authority and
	Registry may be the same administrative entity.		Registry may be the same administrative entity.
	All actors that are recipients of numbering resources, be they a CSP,		All actors that are recipients of numbering resources, be they a CSP,
	Service Enabler, or User, can also be said to have a relationship to		Service Enabler, or User, can also be said to have a relationship to
	a Registry of either an assignee or delegate:		a Registry of either an assignee or delegate:
	Assignee: An actor that is assigned a TN directly by a Registrar; an		Assignee: An actor that is assigned a TN directly by a Registrar; an
	assignee always has a direct relationship with a Registrar.		assignee always has a direct relationship with a Registrar.
	Delegate: An actor that is delegated a TN from an assignee or		Delegate: An actor that is delegated a TN from an assignee or
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 34 ¶
	Figure 1: Chain of Number Assignment		Figure 1: Chain of Number Assignment
	2.2. Data Types		2.2. Data Types
	The following data types are defined in this document:		The following data types are defined in this document:
	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 performance as access to this data is		does not require real-time access as this data is not required for
	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, service features, and so on, and		includes addressing data and service features. Since this data is
	typically does require real-time performance, in so far as this		necessary to complete calls, it must be obtained in real time.
	data typically must be queried during call set-up.
	Administrative and service data can fit into three categories:		Administrative and service data can fit into three categories:
	Public: data that anyone can access, for example a list of which		Public: Anyone can access public data. Such data might include a
	numbering resources (unallocated number ranges) are available for		list of which numbering resources (unallocated number ranges) are
	acquisition from the Registry.		available for acquisition from the Registry.
	Semi-restricted: data that a subset of actors can access, for		Semi-restricted: Only a subset of actors can access semi-restricted
	example CSPs may be able to access other CSP's service data.		data. For example CSPs may be able to access other CSP's service
			data.
	Restricted: data that is only available to a small subset of actors,		Restricted: Only a small subset of actors can access restricted
	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
	This framework generally assumes that administrative and service data		This framework generally assumes that administrative and service data
	is maintained by CSPs, Registrars, and Registries. The role of a		is maintained by CSPs, Registrars, and Registries. The terms
	Registry described here is a "thin" one, where the Registry manages		"registrar" and "registry" are familiar from DNS operations, and
	basic allocation information for the numbering space, such as		indeed the DNS provides an obvious inspiration for the relationships
	information about whether or not the number is assigned, and if		between those entities described here. Protocols for transferring
	assigned, by which Registrar. It is the Registrar that in turn		names between registries and registrars have been standardized in the
	manages detailed administrative data about those assignments, such as		DNS space for some time (see [14]). Similarly, the division between
	contact or billing information for the assignee. In some models,		service data acquired by resolving names with the DNS protocol vs.
	CSPs and Registrars will be composed (the same administrative		administrative data about names acquired through WHOIS [15] is
	entity), and in others the Registry and Registrar may similarly be		directly analogous to the distinction between service and
	composed. Typically, service data resides largely at the CSP itself,		administrative data described in Section 2.2. The major difference
	though in some models a "thicker" Registry may itself contain a		between the data management architecture of the DNS and this
	pointer to the servicing CSP for a number or number block. In		framework is that the distinction between the CSP and User, due to
	addition to traditional centralized Registries, this framework also		historical policies of the telephone network, will often not exactly
	supports environments where the same data is being managed by		correspond to the distinction between a name service and a registrant
			in the DNS world - a User in the telephone network is today at least
			rarely in a direct relationship with a Registrar comparable to that
			of a DNS registrant.
			The role of a Registry described here is a "thin" one, where the
			Registry manages basic allocation information for the numbering
			space, such as information about whether or not the number is
			assigned, and if assigned, by which Registrar. It is the Registrar
			that in turn manages detailed administrative data about those
			assignments, such as contact or billing information for the assignee.
			In some models, CSPs and Registrars will be combined (the same
			administrative entity), and in others the Registry and Registrar may
			similarly be composed. Typically, service data resides largely at
			the CSP itself, though in some models a "thicker" Registry may itself
			contain a pointer to the servicing CSP for a number or number block.
			In addition to traditional centralized Registries, this framework
			also supports environments where the same data is being managed by
	multiple administrative entities, and stored in many locations. A		multiple administrative entities, and stored in many locations. A
	distribute registry system is discussed further in [16].		distributed registry system is discussed further in [19]. To support
			those use cases, it is important to distinguish the following:
	Data store: a service that stores and enables access to		Data store: A Data Store is a service that stores and enables access
	administrative and/or service data.		to administrative and/or service data.
	Reference Address: a URL that dereferences to the location of the		Reference Address: A Reference Address is a URL that dereferences to
	data store.		the location of the data store.
	Distributed data stores: refers to administrative or service data		Distributed data stores: In a Distributed Data Store, administrative
	being stored with multiple actors. For example, CSPs could		or service data can be stored with multiple actors. For example,
	provision their service data to multiple other CSPs.		CSPs could provision their service data to multiple other CSPs.
	Distributed Registries: refers to multiple Registries managing the		Distributed Registries: Multiple Registries can manage the same
	same numbering resource. Actors could interact with one or		numbering resource. In these architectures, actors could interact
	multiple Registries. The Registries would update each other when		with one or multiple Registries. The Registries would update each
	change occurs. The challenge is to ensure there are no clashes,		other when change occurs. The Registries have to ensure that data
	e.g., two Registries assigning the same TN to two different		remains consistent, e.g. that the same TN is not assigned to two
	actors.		different actors.
	3. Framework		3. Framework
	The framework outlined in this document requires three Internet-based		The framework outlined in this document requires three Internet-based
	mechanisms for managing and resolving telephone numbers (TNs) in an		mechanisms for managing and resolving telephone numbers (TNs) in an
	IP environment. These mechanisms will likely reuse existing		IP environment. These mechanisms will likely reuse existing
	protocols for sharing structured data; it is unlikely that new		protocols for sharing structured data; it is unlikely that new
	protocol development work will be required, though new information		protocol development work will be required, though new information
	models specific to the data itself will be a major focus of framework		models specific to the data itself will be a major focus of framework
	development. Likely candidates for reuse here include work done in		development. Likely candidates for reuse here include work done in
	DRINKS [4] and WEIRDS [12], as well as the TeRI [13] framework.		DRINKS [4] and WEIRDS [12], as well as the TeRI [16] framework.
	These protocol mechanisms are scoped in a way that makes them likely		These protocol mechanisms are scoped in a way that makes them likely
	to apply to a broad range of future policies for number		to apply to a broad range of future policies for number
	administration. It is not the purpose of this framework to dictate		administration. It is not the purpose of this framework to dictate
	number policy, but instead to provide tools that will work with		number policy, but instead to provide tools that will work with
	policies as they evolve going forward. These mechanisms therefore do		policies as they evolve going forward. These mechanisms therefore do
	not assume that number administration is centralized, nor that number		not assume that number administration is centralized, nor that number
	allocations are restricted to any category of service providers,		allocations are restricted to any category of service providers,
	though these tools must and will work in environments with those		though these tools must and will work in environments with those
	properties.		properties.
	skipping to change at page 9, line 36 ¶		skipping to change at page 9, line 50 ¶
	The three mechanisms are:		The three mechanisms are:
	Acquisition: a protocol mechanism for acquiring TNs, including an		Acquisition: a protocol mechanism for acquiring TNs, including an
	enrollment process.		enrollment process.
	Management: a protocol mechanism for associating data with TNs.		Management: a protocol mechanism for associating data with TNs.
	Retrieval: a protocol mechanism for retrieving data about TNs.		Retrieval: a protocol mechanism for retrieving data about TNs.
	The acquisition mechanism will enable actors to acquire TNs for use		The acquisition mechanism will enable actors to acquire TNs for use
	with a communications service. The acquisition mechanism will		with a communications service by requesting numbering resources from
	provide a means to request numbering resources from a service		a service operated by a Registrar, CSP or similar actor. TNs may be
	operated by a Registrar, CSP or similar actor. TNs may be requested		requested either on a number-by-number basis, or as inventory blocks.
	either on a number-by-number basis, or as inventory blocks. Any
	actor who grants numbering resources will retain metadata about the		Any actor who grants numbering resources will retain metadata about
	assignment, including the responsible organization or individual to		the assignment, including the responsible organization or individual
	whom numbers have been assigned.		to whom numbers have been assigned.
	The management mechanism will let actors provision data associated		The management mechanism will let actors provision data associated
	with TNs. For example, if a User has been assigned a TN, they may		with TNs. For example, if a User has been assigned a TN, they may
	select a CSP to provide a particular service associated with the TN,		select a CSP to provide a particular service associated with the TN,
	or a CSP may assign a TN to a User upon service activation. In		or a CSP may assign a TN to a User upon service activation. In
	either case, a mechanism is needed to provision data associated with		either case, a mechanism is needed to provision data associated with
	the TN at that CSP.		the TN at that CSP, and to extend those data sets as CSPs (and even
			Users) require.
	The retrieval mechanism will enable actors to learn information about		The retrieval mechanism will enable actors to learn information about
	TNs, typically by sending a request to a CSP. For some information,		TNs. For real-time service data, this typically involves sending a
	an actor may need to send a request to a Registry rather than a CSP.		request to a CSP; for other information, an actor may need to send a
	Different parties may be authorized to receive different information		request to a Registry rather than a CSP. Different parties may be
	about TNs.		authorized to receive different information about TNs.
	As an example, a CSP might use the acquisition interface to acquire a		As an example, a CSP might use the acquisition interface to acquire a
	chunk of numbers from a Registrar. Users might then provision		chunk of numbers from a Registrar. Users might then provision
	administrative data associated with those numbers at the CSP through		administrative data associated with those numbers at the CSP through
	the management interface, and query for service data relating to		the management interface, and query for service data relating to
	those numbers through the retrieval interface of the CSP.		those numbers through the retrieval interface of the CSP.
	+--------+		+--------+
	|Registry|		|Registry|
	+---+----+		+---+----+
	skipping to change at page 10, line 36 ¶		skipping to change at page 11, line 27 ¶
	\ CSP |		\ CSP |
	+---+---+		+---+---+
	A A		A A
	| |		| |
	Management | | Retrieval		Management | | Retrieval
	| |		| |
	| |		| |
	+-------++ ++-------+		+-------++ ++-------+
	| User | | User |		| User | | User |
	+--------+ +--------+		+--------+ +--------+
			(delegate) (caller)
	Figure 2: Example of the Three Interfaces		Figure 2: Example of the Three Interfaces
	4. Use Cases		4. Use Cases
	The high-level use cases in this section will provide an overview of		The high-level use cases in this section will provide an overview of
	the expected operation of the three interfaces in the MODERN problem		the expected operation of the three interfaces in the MODERN problem
	space.		space:
	4.1. Acquisition		4.1. Acquisition
	There are various scenarios for how TNs can be acquired by the		There are various scenarios for how TNs can be acquired by the
	relevant actors: a CSP, Service Enabler, or User. There are three		relevant actors, that is, a CSP, Service Enabler, and a User. There
	actors from which numbers can be acquired: a Registrar, a CSP and a		are three actors from which numbers can be acquired: a Registrar, a
	User (presumably one who is delegating to another party). It is		CSP and a User (presumably one who is delegating to another party).
	assumed that Registrars are either composed with Registries, or that		It is assumed that Registrars are either the same entity as
	Registrars have established business relationships with Registries		Registries, or that Registrars have established business
	that enable them to distribute the numbers that the Registries here		relationships with Registries that enable them to distribute the
	administer. In these use cases, a User may acquire TNs either from a		numbers that the Registries administer. In these use cases, a User
	CSP or a Registry, or from an intermediate delegate.		may acquire TNs either from a CSP or a Registry, or from an
			intermediate delegate.
	4.1.1. CSP Acquires TNs from Registrar		4.1.1. CSP Acquires TNs from Registrar
	The most fundamental and traditional numbering use case is one where		The most traditional number acquisition use case is one where a CSP,
	a CSP, such as a carrier, requests a block of numbers from a		such as a carrier, requests a block of numbers from a Registrar to
	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 what qualifications they possess for requesting TNs. The		the CSP and assesses whether or not CSPs meet the policy restrictions
	CSP may then request TNs from within a specific pool of numbers in		for acquiring TNs. The CSP may then request TNs from within a
	the authority of the Registry; such as region, mobile, wireline,		specific pool of numbers in the authority of the Registry; such as
	tollfree, etc. The Registrar must authenticate and authorize the		region, mobile, wireline, or freephone. The Registrar must
	CSP, and then either grant or deny a request. When an assignment		authenticate and authorize the CSP, and then either grant or deny a
	occurs, the Registry creates and stores administrative information		request. When an assignment occurs, the Registry creates and stores
	related to the assignment such as TN status and Registrar contact		administrative information related to the assignment such as TN
	information, and removes the specific TN(s) from the pool of those		status and Registrar contact information, and removes the specific
	that are available for assignment. As a part of the acquisition and		TN(s) from the pool of those that are available for assignment. As a
	assignment process, the Registry provides any necessary credentials		part of the acquisition and assignment process, the Registry provides
	(for example, STIR certificates [14]) to the Registrar to be used to		any necessary credentials (for example, STIR certificates [17]) to
	prove the assignment for future transactions.		the Registrar to be used to prove the assignment for future
			transactions.
	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,		national 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 interoperability. 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		4.1.2. User Acquires TNs from CSP
	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 User creates or has a relationship with the CSP, and subscribes to		A User creates or has a relationship with the CSP, and subscribes to
	a communications service which includes the use of a TN. The CSP		a communications service which includes the use of a TN. The CSP
	collects and stores administrative data about the User. The CSP then		collects and stores administrative data about the User. The CSP then
	activates the User on their network and creates any necessary service		activates the User on their network and creates any necessary service
	data to enable interoperability with other CSPs. The CSP could also		data to enable connectivity with other CSPs. The CSP could also
	update public or privileged databases accessible by other Actors.		update public or privileged databases accessible by other Actors.
	The CSP provides any necessary credentials to the User (for example,		The CSP provides any necessary credentials to the User (for example,
	a STIR certificate [14]) to prove the assignment for future		a STIR certificate [17]) to prove the assignment for future
	transactions. Such credential could be delegated from the one		transactions. Such credential could be delegated from the one
	provided by the Registrar to the CSP to continue the chain of		provided by the Registrar to the CSP to continue the chain of
	assignment.		assignment.
	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.
	4.1.3. CSP Delegates TNs to Another CSP		4.1.3. CSP Delegates TNs to Another CSP
	A reseller or a service bureau might acquire a block of numbers from		A reseller or a service bureau might acquire a block of numbers from
	a CSP to be issued to Users.		a CSP to be issued to Users.
	In this case, the delegate CSP has a business relationship with the		In this case, the delegate CSP (as defined in Section 2.1) has a
	assignee CSP. The assignee CSP collects and stores administrative		business relationship with the assignee CSP. The assignee CSP
	data about the delegate. The assignee then activates the delegate on		collects and stores administrative data about the delegate. The
	their network and creates any necessary service data to enable		assignee then activates the delegate on their network and creates any
	interoperability with other CSPs. The CSP could also update public		necessary service data to enable interconnection with other CSPs.
	or privileged databases accessible by other Actors. The CSP provides		The CSP could also update public or privileged databases accessible
	any necessary credentials to the delegate CSP (for example, a STIR		by other Actors. The CSP provides any necessary credentials to the
	certificate [14]) to prove the assignment for future transactions.		delegate CSP (for example, a STIR certificate [17]) to prove the
	Such credentials could be delegated from the one provided by the		assignment for future transactions. Such credentials could be
	Registry to the CSP to continue the chain of assignment.		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		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.		acquire new TNs from the Registrar as part of the assignment process.
	If it assigns it from its existing inventory it would remove the		If it assigns it from its existing inventory it would remove the
	specific TN from the pool of those available for assignment. It may		specific TN from the pool of those available for assignment. It may
	also update the Registrar about the assignment so the Registrar has		also update the Registrar about the assignment so the Registrar has
	current assignment data. The Delegate may need to provide		current assignment data. The delegate may have the same obligations
	utilization and assignment data to the Registry, either directly or		to provide utilization data to the Registry as the assignee, per
	through the CSP.		Section 4.1.1
	4.1.4. User Acquires TNs from a Delegate		4.1.4. User Acquires TNs from a Delegate
	Acquiring a TN from a delegate follows the process in Section 4.1.2,		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. In		as it should be similar to how a User acquires TNs from a CSP. But
	this case, the delegate re-delegating the TNs would be performing		in this case, the delegate re-delegating the TNs would be performing
	functions done by the CSP, e.g., providing any credentials,		functions done by the CSP, e.g., providing any credentials,
	collecting administrative data, creative service data, and so on.		collecting administrative data, or creative service data.
	4.1.5. User Acquires Numbers from Registrar		4.1.5. User Acquires TNs from Registrar
	Today, a user wishing to acquire a freephone number may browse the		Today, a user wishing to acquire a freephone number may browse the
	existing inventory through one or more Registrars, comparing their		existing inventory through one or more Registrars, comparing their
	prices and services. Each such Registrar either is a CSP, or has a		prices and services. Each such Registrar either is a CSP, or has a
	business relationship with a CSP to provide services for that		business relationship with one or more CSPs to provide services for
	freephone number.		that freephone number.
	Acquiring a TN from a Registrar follows the process in Section 4.1.1,		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.		as it should be similar to how a CSP acquires TNs from a Registrar.
	In this case, the User must establish some business relationship		In this case, the User must establish some business relationship
	directly to a Registrar, similarly to how such functions are		directly with a Registrar, similarly to how such functions are
	conducted today when Users purchase domain names. For the purpose of		conducted today when Users purchase domain names. For the purpose of
	status information kept by the Registry, TNs assigned to a User are		status information kept by the Registry, TNs assigned to a User are
	always considered assigned, not inventory.		always considered assigned, not inventory.
	In this use case, after receiving a number assignment from the		In this use case, after receiving a number assignment from the
	Registrar, a User will then obtain communications service from a CSP,		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		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		will associate service information for that TN, e.g., service
	address, and make it available to other CSPs to enable		address, and make it available to other CSPs to enable
	interoperability.		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
	administrative contacts, and the actors involved in providing service		administrative contacts, and the actors involved in providing service
	to the TN. Protocol interactions for administrative data will		to the TN. Protocol interactions for administrative data will
	therefore predominantly occur between CSPs and Users to the		therefore predominantly occur between CSPs and Users to the
	Registrar, or between Users and delegate CSPs to the CSP.		Registrar, or between Users and delegate CSPs to the CSP.
	Most administrative data is not a good candidate for a distributed		Some administrative data may be private, and would thus require
	data store model. Access to it does not require real-time		special handling in a distributed data store model. Access to it
	performance therefore local caches are not necessary. And it will		does not require real-time performance therefore local caches are not
	include sensitive information such as user and contact data.		necessary. And it will include sensitive information such as user
			and contact data.
	Some of the data could lend itself to being publicly available, such		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. CSP to 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) and		of changes would be terminating service (see Section 4.2.3.2),
	changing a CSP or delegate. Changes should be authenticated by a		changing the name or address of a User or organization, or changing a
	credential to prove administrative responsibility for the TN.		CSP or delegate. Changes should be authenticated by a credential to
			prove administrative responsibility for the TN.
	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. User to 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
	notify 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 to the CSP/Registrar's		Registry maintains a reference address (see Section 2.3) to the CSP/
	administrative data store so relevant actors have the ability to		Registrar's administrative data store so relevant actors have the
	access the data. Alternatively a CSP could send the administrative		ability to access the data. Alternatively, a CSP could send the
	data to an external Registrar to store. If there is a delegate		administrative data to an external Registrar to store. If there is a
	between the CSP and user, they will have to ensure there is a		delegate between the CSP and user, they will have to ensure there is
	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		4.2.1.3. User to Registrar
	If the User has a direct relationship with the Registrar, then		If the User has a direct relationship with the Registrar, then
	naturally the user could provision administrative data associated		naturally the user could provision administrative data associated
	with their TN directly to the Registrar. This is the case, for		with their TN directly to the Registrar. This is the case, for
	example, with the freephone example, where a User has a business		example, with the freephone example, where a User has a business
	relationship with its freephone provider, and the freephone provider		relationship with its freephone provider, and the freephone provider
	maintains account and billing data. While delegates necessarily are		maintains account and billing data. While delegates may not
	not assignees, some environments as an optimization might want to		ordinarily have a direct relationship to a Registrar, some
	support a model where the delegate updates the Registrar directly on		environments as an optimization might want to support a model where
	changes, as opposed to sending that data to the CSP or through the		the delegate updates the Registrar directly on changes, as opposed to
	CSP to the Registrar. As stated already, the protocol should enable		sending that data to the CSP or through the CSP to the Registrar. As
	Users to acquire TNs directly from a Registrar, which Registrar may		stated already, the protocol should enable Users to acquire TNs
	or may not also act as a CSP. In these cases the updates would be		directly from a Registrar, which Registrar may or may not also act as
	similar to that described in Section 4.2.1.1.		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 possible		CSPs typically create and manage service data, however, it is
	that delegates and Users could as well. For most use cases involving		possible that delegates and Users could as well. For most use cases
	individual Users, it is anticipated that lower-level service		involving individual Users, it is anticipated that lower-level
	information changes would be communicated to CSPs via existing		service information changes (such as an end-user device receiving a
	protocols (like the baseline SIP REGISTER [2] method) rather than		new IP address) would be communicated to CSPs via existing protocols.
	through any new interfaces defined by MODERN.		For example, the baseline SIP REGISTER [2] method, even for bulk
			operations [13], would likely be used rather than through any new
			interfaces defined by MODERN.
	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.		service address such as a SIP URI and associate it with the TN. The
	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 provide data directly
	to other CSPs.		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
	skipping to change at page 16, line 24 ¶		skipping to change at page 17, line 15 ¶
	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 use cases that were not
	covered in other sections of 4.2.		covered in other sections of 4.2.
	4.2.3.1. Changing the CSP for an Existing Communications Service		4.2.3.1. Changing the CSP for an Existing Communications Service
	A User who subscribes to a communications service, and received their		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		TN from that CSP, wishes to retain the same TN but move their service
	to a different CSP. The User provides their credential to the new		to a different CSP. The User provides their credential to the new
	CSP and the CSP initiates the change in service.		CSP and the CSP initiates the change in service
	In the simplest scenario, where there's an authoritative composed		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 new CSP provides
	the new service data with the User's credential to the Registry/		the new service data with the User's credential to the Registry/
	Registrar, which then makes the change. The old credential is		Registrar, which then makes the change. The old credential is
	revoked and a new one is provided. The new CSP or the Registrar		revoked and a new one is provided. The new CSP or the Registrar
	would send a notification to the old CSP, so they can disable		would send a notification to the old CSP, so they can disable
	service. The old CSP will undo any delegations to the User,		service. The old CSP will undo any delegations to the User,
	including invalidating any cryptographic credentials (e.g. STIR		including invalidating any cryptographic credentials (e.g., STIR
	certificates [13]) previously granted to the User. Any service data		certificates [13]) 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 provide their credential to the old CSP, and the old CSP
	initiates the change in service.		initiates the change in service. Alternatively, a User could go
			directly to a Registrar to initiate a port. The framework should
			support all of these potential flows.
	If there was a distributed Registry that maintained service data, the		Note that in cases with a distributed Registry that maintained
	Registry would also have to update the other Registries of the		service data, the Registry would also have to update the other
	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		A User who subscribes to a communications service, and received their
	TN from the CSP, wishes to terminate their service. At this time,		TN from the CSP, wishes to terminate their service. At this time,
	the CSP will undo any delegations to the User, including invalidating		the CSP will undo any delegations to the User, including invalidating
	any cryptographic credentials (e.g. STIR certificates [13])		any cryptographic credentials (e.g., STIR certificates [13])
	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.		information it provisioned in the Registrar. However, per the policy
			of the Numbering Authority, Registrars and CSPs may be required to
			preserve historical data that will be accessible to Government
			Entities or others through audits, even if it is no longer
			retrievable through service interfaces.
	The TN will change state from assigned to unassigned, 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
	the Registry, CSP, or delegate's pool of available TNs and would		the Registry, CSP, or delegate's pool of available TNs and would
	likely enter an ageing process.		likely enter an ageing process.
	In an alternative use case, a User who received their own TN		In an alternative use case, a User who received their own TN
	assignment directly from a Registrar terminates their service with a		assignment directly from a Registrar terminates their service with a
	CSP. At this time, the User might terminate their assignment from		CSP. At this time, the User might terminate their assignment from
	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 and service data will
	fall into the semi-restricted category: access to this information		fall into the semi-restricted category: access to this information
	may require some form of authorization, though service data crucial		may require some form of authorization, though service data crucial
	to reachability will need to be accessible. In some environments,		to reachability will need to be accessible. In some environments,
	it's possible that none of the service data will be considered		it's possible that none of the service data will be considered
	public.		public.
	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		Under most circumstances, a CSP wants its communications service to
	be publicly reachable through TNs, so the retrieval interface		be publicly reachable through TNs, so the retrieval interface
	supports public interfaces that permit clients to query for service		supports public interfaces that permit clients to query for service
	data about a TN. Some service data may however require that the		data about a TN. Some service data may however require that the
	client by authorized to receive it, per the use case in Section 4.3.3		client be authorized to receive it, per the use case in Section 4.3.3
	below.		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
	A CSP is having service problems completing calls to a specific TN,		Consider a case in which a CSP is having service problems completing
	so it wants to contact the CSP serving that TN. The Registry		calls to a specific TN, so it wants to contact the CSP serving that
	authorizes the originating CSP to access this information. It		TN. The Registry authorizes the originating CSP to access this
	initiates a query to the Registry, the Registry verifies the		information. It initiates a query to the Registry, the Registry
	requestor and the requested data and Registry responds with the		verifies the requestor and the requested data and Registry responds
	serving CSP and contact data.		with the serving CSP and contact data.
	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 the Registry. In that case, the CSP has the
	data in a local distributed data store and it initiates the query to		data in a local distributed data store and it initiates the query to
	the local data store. The local data store responds with the CSP and		the local data store. The local data store responds with the CSP and
	contact data. No verification is necessary because it was done when		contact data. No verification is necessary because it was done when
	the CSP was authorized to receive the data store.		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		A User on a CSP's network calls a TN. The CSP initiates a query for
	service data associated with the TN to complete the call, and will		service data associated with the TN to complete the call, and will
	receive special service data because the CSP operates in a closed		receive special service data because the CSP operates in a closed
	environment where different CSPs receive different responses, and		environment where different CSPs receive different responses, and
	only authorized CSPs may access service data. The query and response		only authorized CSPs may access service data. The query and response
	must have real-time performance. There are multiple scenarios for		must have real-time performance.
	the query and response.
	In a distributed data store model each CSP distributes its updated		In a distributed data store model each CSP distributes its updated
	service data to all other CSPs. The originating CSP has the service		service data to all other CSPs. The originating CSP has the service
	data in its local data store and queries it. The local data store		data in its local data store and queries it. The local data store
	responds with the service data. The service data can be a reference		responds with the service data. The service data in the response can
	address to a data store maintained by the serving CSP or it can be		be a reference address to a data store maintained by the serving CSP,
	the service address itself. In the case where it's a reference		or it can be the service address itself. In the case where the
	address the query would go to the serving CSP and they would verify		response gives a reference address, a subsequent query would go to
	the requestor and the requested data and respond. In the case where		the serving CSP, who would in turn authorize the requestor for the
	it's the service address it would process the call using that.		requested data and respond appropriate. In the case where the
			original response contains the service address, the requestor would
			use that service address as the destination for the call.
	In some environments, aspects of the service data may reside at the		In some environments, aspects of the service data may reside at the
	Registry itself (for example, the assigned CSP for a TN), and thus a		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
	In this case, a Government Entity wishes to access information about		A Government Entity wishes to access information about a particular
	a particular User, who subscribes to a communications service. The		User, who subscribes to a communications service. The entity that
	entity that operates the Registry on behalf of the National Authority		operates the Registry on behalf of the National Authority in this
	in this case has some pre-defined relationship with the Government		case has some pre-defined relationship with the Government Entity.
	Entity. When the CSP acquired TNs from the National Authority, it		When the CSP acquired TNs from the National Authority, it was a
	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.		National Authority.
	5. Acknowledgments		5. Acknowledgments
	We would like to thank Henning Schulzrinne for his contributions to		We would like to thank Henning Schulzrinne and Adam Roach for their
	this problem statement and framework, and to thank Pierce Gorman for		contributions to this problem statement and framework, and to thank
	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.
	7. Security Considerations		7. Security Considerations
	The acquisition, management, and retrieval of administrative and		The acquisition, management, and retrieval of administrative and
	service data associated with telephone numbers raises a number of		service data associated with telephone numbers raises a number of
	security issues.		security issues.
	skipping to change at page 21, line 39 ¶		skipping to change at page 22, line 33 ¶
	for the Session Initiation Protocol (SIP) and the Real-		for the Session Initiation Protocol (SIP) and the Real-
	time Applications and Infrastructure Area", BCP 67,		time Applications and Infrastructure Area", BCP 67,
	RFC 5727, DOI 10.17487/RFC5727, March 2010,		RFC 5727, DOI 10.17487/RFC5727, March 2010,
	<http://www.rfc-editor.org/info/rfc5727>.		<http://www.rfc-editor.org/info/rfc5727>.
	[12] Newton, A. and S. Hollenbeck, "Registration Data Access		[12] Newton, A. and S. Hollenbeck, "Registration Data Access
	Protocol (RDAP) Query Format", RFC 7482,		Protocol (RDAP) Query Format", RFC 7482,
	DOI 10.17487/RFC7482, March 2015,		DOI 10.17487/RFC7482, March 2015,
	<http://www.rfc-editor.org/info/rfc7482>.		<http://www.rfc-editor.org/info/rfc7482>.
	[13] Peterson, J., "A Framework and Information Model for		[13] Roach, A., "Registration for Multiple Phone Numbers in the
			Session Initiation Protocol (SIP)", RFC 6140,
			DOI 10.17487/RFC6140, March 2011,
			<http://www.rfc-editor.org/info/rfc6140>.
			[14] Hollenbeck, S., "Generic Registry-Registrar Protocol
			Requirements", RFC 3375, DOI 10.17487/RFC3375, September
			2002, <http://www.rfc-editor.org/info/rfc3375>.
			[15] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
			DOI 10.17487/RFC3912, September 2004,
			<http://www.rfc-editor.org/info/rfc3912>.
			[16] Peterson, J., "An Architecture and Information Model for
	Telephone-Related Information (TeRI)", draft-peterson-		Telephone-Related Information (TeRI)", draft-peterson-
	modern-teri-00 (work in progress), October 2015.		modern-teri-02 (work in progress), October 2016.
	[14] 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-06 (work in progress), July 2016.		certificates-11 (work in progress), October 2016.
	[15] 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.
	[16] Bellur, H. and C. Wendt, "Distributed Registry Protocol",		[19] Bellur, H. and C. Wendt, "Distributed Registry Protocol",
	draft-wendt-modern-drip-00 (work in progress), October		draft-wendt-modern-drip-01 (work in progress), July 2016.
	2015.
	[17] Rosenberg, J. and H. Schulzrinne, "Session Initiation		[20] Rosenberg, J. and H. Schulzrinne, "Session Initiation
	Protocol (SIP): Locating SIP Servers", RFC 3263,		Protocol (SIP): Locating SIP Servers", RFC 3263,
	DOI 10.17487/RFC3263, June 2002,		DOI 10.17487/RFC3263, June 2002,
	<http://www.rfc-editor.org/info/rfc3263>.		<http://www.rfc-editor.org/info/rfc3263>.
	Authors' Addresses		Authors' Addresses
	Jon Peterson		Jon Peterson
	Neustar, Inc.		Neustar, Inc.
	1800 Sutter St Suite 570		1800 Sutter St Suite 570
	Concord, CA 94520		Concord, CA 94520
End of changes. 88 change blocks.
	270 lines changed or deleted		316 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/