draft-ietf-drinks-spprov-07.txt		draft-ietf-drinks-spprov-08.txt
	DRINKS J-F. Mule		DRINKS J-F. Mule
	Internet-Draft CableLabs		Internet-Draft CableLabs
	Intended status: Standards Track K. Cartwright		Intended status: Standards Track K. Cartwright
	Expires: October 21, 2011 TNS		Expires: January 13, 2012 TNS
	S. Ali		S. Ali
	NeuStar		NeuStar
	A. Mayrhofer		A. Mayrhofer
	enum.at GmbH		enum.at GmbH
	April 19, 2011		July 12, 2011
	Session Peering Provisioning Protocol		Session Peering Provisioning Protocol
	draft-ietf-drinks-spprov-07		draft-ietf-drinks-spprov-08
	Abstract		Abstract
	This document defines a protocol for provisioning session		This document defines a protocol for provisioning session
	establishment data into Session Data Registries and SIP Service		establishment data into Session Data Registries and SIP Service
	Provider data stores. The provisioned data is typically used by		Provider data stores. The provisioned data is typically used by
	various network elements for session peering.		various network elements for session peering.
	This document describes the Session Peering Provisioning Protocol		This document describes the Session Peering Provisioning Protocol
	used by clients to provision registries. The document provides a set		used by clients to provision registries. The document provides a set
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	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 October 21, 2011.		This Internet-Draft will expire on January 13, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Protocol High Level Design . . . . . . . . . . . . . . . . . . 9		3. Protocol High Level Design . . . . . . . . . . . . . . . . . . 9
	3.1. Protocol Layering . . . . . . . . . . . . . . . . . . . . 9		3.1. Protocol Layering . . . . . . . . . . . . . . . . . . . . 9
	3.2. Protocol Data Model . . . . . . . . . . . . . . . . . . . 10		3.2. Protocol Data Model . . . . . . . . . . . . . . . . . . . 10
	4. Transport Protocol Requirements . . . . . . . . . . . . . . . 14		4. Transport Protocol Requirements . . . . . . . . . . . . . . . 14
	4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 14		4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 14
	4.2. Request and Response Model . . . . . . . . . . . . . . . . 14		4.2. Request and Response Model . . . . . . . . . . . . . . . . 14
	4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 15		4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 14
	4.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 15		4.4. Time value . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.5. Confidentiality and Integrity . . . . . . . . . . . . . . 15		4.5. Authentication . . . . . . . . . . . . . . . . . . . . . . 15
	4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 15		4.6. Authorization . . . . . . . . . . . . . . . . . . . . . . 15
	4.7. Request and Response Sizes . . . . . . . . . . . . . . . . 16		4.7. Confidentiality and Integrity . . . . . . . . . . . . . . 15
	4.8. Request and Response Correlation . . . . . . . . . . . . . 16		4.8. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 15
	4.9. Request Acknowledgement . . . . . . . . . . . . . . . . . 16		4.9. Request and Response Sizes . . . . . . . . . . . . . . . . 15
	4.10. Mandatory Transport . . . . . . . . . . . . . . . . . . . 16		4.10. Request and Response Correlation . . . . . . . . . . . . . 16
			4.11. Request Acknowledgement . . . . . . . . . . . . . . . . . 16
			4.12. Mandatory Transport . . . . . . . . . . . . . . . . . . . 16
	5. Base Protocol Data Structures . . . . . . . . . . . . . . . . 17		5. Base Protocol Data Structures . . . . . . . . . . . . . . . . 17
	5.1. Request and Response Structures . . . . . . . . . . . . . 17		5.1. Request and Response Structures . . . . . . . . . . . . . 17
	5.1.1. Update Request and Response Structures . . . . . . . . 17		5.1.1. Update Request and Response Structures . . . . . . . . 17
	5.1.2. Query Request and Response Structures . . . . . . . . 20		5.1.2. Query Request and Response Structures . . . . . . . . 20
	5.2. Response Codes and Messages . . . . . . . . . . . . . . . 22		5.2. Response Codes and Messages . . . . . . . . . . . . . . . 23
	5.3. Basic Object Type and Organization Identifiers . . . . . . 24		5.3. Basic Object Type and Organization Identifiers . . . . . . 25
	6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 26		6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 26
	6.1. Add Destination Group Operation . . . . . . . . . . . . . 26		6.1. Add Destination Group Operation . . . . . . . . . . . . . 26
	6.2. Get Destination Groups Operation . . . . . . . . . . . . . 27		6.2. Get Destination Groups Operation . . . . . . . . . . . . . 27
	6.3. Add Public Identifier Operation . . . . . . . . . . . . . 28		6.3. Add Public Identifier Operation . . . . . . . . . . . . . 28
	6.4. Get Public Identifiers Operation . . . . . . . . . . . . . 33		6.4. Get Public Identifiers Operation . . . . . . . . . . . . . 33
	6.5. Add Route Group Operation . . . . . . . . . . . . . . . . 33		6.5. Add Route Group Operation . . . . . . . . . . . . . . . . 33
	6.6. Get Route Groups Operation . . . . . . . . . . . . . . . . 38		6.6. Get Route Groups Operation . . . . . . . . . . . . . . . . 38
	6.7. Add Route Record Operation . . . . . . . . . . . . . . . . 39		6.7. Add Route Record Operation . . . . . . . . . . . . . . . . 39
	6.8. Get Route Records Operation . . . . . . . . . . . . . . . 43		6.8. Get Route Records Operation . . . . . . . . . . . . . . . 43
	6.9. Add Route Group Offer Operation . . . . . . . . . . . . . 44		6.9. Add Route Group Offer Operation . . . . . . . . . . . . . 44
	skipping to change at page 4, line 7		skipping to change at page 4, line 7
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
	11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 80		11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 80
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 93
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 94		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 94
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 94		13.1. Normative References . . . . . . . . . . . . . . . . . . . 94
	13.2. Informative References . . . . . . . . . . . . . . . . . . 94		13.2. Informative References . . . . . . . . . . . . . . . . . . 94
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96
	1. Introduction		1. Introduction
	Service providers and enterprises use registries to make call or		Service providers and enterprises use registries to make session
	session routing decisions for Voice over IP, SMS and MMS traffic		routing decisions for Voice over IP, SMS and MMS traffic exchanges.
	exchanges. This document is narrowly focused on the provisioning		This document is narrowly focused on the provisioning protocol for
	protocol for these registries. This protocol prescribes a way for an		these registries. This protocol prescribes a way for an entity to
	entity to provision session-related data into a registry. The data		provision session-related data into a registry. The data being
	being provisioned can be optionally shared with other participating		provisioned can be optionally shared with other participating peering
	peering entities. The requirements and use cases driving this		entities. The requirements and use cases driving this protocol have
	protocol have been documented in		been documented in [I-D.ietf-drinks-usecases-requirements]. The
	[I-D.ietf-drinks-usecases-requirements]. The reader is expected to		reader is expected to be familiar with the terminology defined in the
	be familiar with the terminology defined in the previously mentioned		previously mentioned document.
	document.
	Three types of provisioning flows have been described in the use case		Three types of provisioning flows have been described in the use case
	document: client to registry provisioning, registry to local data		document: client to registry provisioning, registry to local data
	repository and registry-to-registry. This document addresses a		repository and registry to registry. This document addresses client
	subset (client-to-registry provisioning) by defining a Session		to registry aspect to fulfill the need to provision Session
	Peering Provisioning Protocol (SPPP) for provisioning Session		Establishment Data (SED). The protocol that supports flow of
	Establishment Data (SED) into a Registry (arrow "1" in the figure		messages to facilitate client to registry provisioning is referred to
	below). While the other "provisioning flows" are shown below as		as Session Peering Provisioning Protocol (SPPP).
	separate message flows, no determination has been made for whether
	one common baseline protocol could be used for all three, or whether
	distinct protocols are required.
	*------------* *------------*		Please note that the role of the "client" and the "server" only
	(1). Provisioning SED | | (3).Registry | |		applies to the connection, and those roles are not related in any way
	-----------------------> | Registry |<------------->| Registry |		to the type of entity that participates in a protocol exchange. For
	data into Registries| | to Registry | |		example, a registry might also include a "client" when such a
	*------------* exchanges *------------*		registry initiates a connection (for example, for data distribution
			to SSP).
			*--------* *------------* *------------*
			| | (1). Client | | (3).Registry | |
			| Client | ------------> | Registry |<------------->| Registry |
			| | to Registry | | to Registry | |
			*--------* *------------* *------------*
	/ \ \		/ \ \
	/ \ \		/ \ \
	/ \ \		/ \ \
	/ \ v		/ \ v
	/ \ ...		/ \ ...
	/ \		/ \
	/ (2). \		/ (2). Distrib \
	/ Distributing \		/ Registry data \
	/ SED \		/ to local data \
	V V		V store V
	+----------+ +----------+		+----------+ +----------+
	|Local Data| |Local Data|		|Local Data| |Local Data|
	|Repository| |Repository|		|Repository| |Repository|
	+----------+ +----------+		+----------+ +----------+
	Three Registry Provisioning Flows		Three Registry Provisioning Flows
	Figure 1		Figure 1
	The data provisioned for session establishment is typically used by		The data provisioned for session establishment is typically used by
	various downstream SIP signaling systems to route a call to the next		various downstream SIP signaling systems to route a call to the next
	hop associated with the called domain. These systems typically use a		hop associated with the called domain. These systems typically use a
	local data store ("Local Data Repository") as their source of session		local data store ("Local Data Repository") as their source of session
	routing information. More specifically, the SED data is the set of		routing information. More specifically, the SED data is the set of
	parameters that the outgoing signaling path border elements (SBEs)		parameters that the outgoing signaling path border elements (SBEs)
	need to initiate the session. See [RFC5486] for more details.		need to initiate the session. See [RFC5486] for more details.
	A "terminating" SIP Service Provider (SSP) provisions SED into the		A "terminating" SIP Service Provider (SSP) provisions SED into the
	registry to be selectively shared with other peer SSPs.		registry to be selectively shared with other peer SSPs.
	Subsequently, a Registry may distribute the provisioned data into		Subsequently, a registry may distribute the provisioned data into
	local Data Repositories used for look-up queries (identifier -> URI)		local data repositories used for look-up queries (identifier -> URI)
	or for lookup and location resolution (identifier -> URI -> ingress		or for lookup and location resolution (identifier -> URI -> ingress
	SBE of terminating SSP). In some cases, the Registry may		SBE of terminating SSP). In some cases, the registry may
	additionally offer a central query resolution service (not shown in		additionally offer a central query resolution service (not shown in
	the above figure).		the above figure).
	A key requirement for the SPPP protocol is to be able to accommodate		A key requirement for the SPPP protocol is to be able to accommodate
	two basic deployment scenarios:		two basic deployment scenarios:
	1. A Local Data Repository serves a Look-Up Function (LUF) to		1. A resolution system returns a Look-Up Function (LUF) that
	determine the target domain to assist in call routing (as		comprises of the target domain to assist in call routing (as
	described in [RFC5486]). In this case, the querying entity may		described in [RFC5486]). In this case, the querying entity may
	use other means to perform the Location Routing Function (LRF)		use other means to perform the Location Routing Function (LRF)
	which in turn helps determine the actual location of the		which in turn helps determine the actual location of the
	Signaling Function in that domain.		Signaling Function in that domain.
	2. A Local Data Repository serves both a Look-Up function (LUF) and		2. A resolution system returns both a Look-Up function (LUF) and
	Location Routing Function (LRF) to locate the SED data fully.		Location Routing Function (LRF) to locate the SED data fully.
	In terms of protocol design, SPPP protocol is agnostic to the		In terms of protocol design, SPPP is agnostic to the transport. This
	transport. This document includes the description of the data model		document includes the description of the data model and the means to
	and the means to enable protocol operations within a request and		enable protocol operations within a request and response structure.
	response structure. To encourage interoperability, the protocol		To encourage interoperability, the protocol supports extensibility
	supports extensibility aspects.		aspects.
	Transport requirements are provided in this document to help with the		Transport requirements are provided in this document to help with the
	selection of the optimum transport mechanism.		selection of the optimum transport mechanism.
	([I-D.ietf-drinks-sppp-over-soap]) identifies a SOAP transport		([I-D.ietf-drinks-sppp-over-soap]) identifies a SOAP transport
	mechanism for SPPP.		mechanism for SPPP.
	This document is organized as follows:		This document is organized as follows:
	o Section 2 provides the terminology;		o Section 2 provides the terminology;
	o Section 3 provides an overview of the SPPP protocol, including		o Section 3 provides an overview of the SPPP, including the
	the layering approach, functional entities and data model;		layering approach, functional entities and data model;
	o Section 4 specifies requirements for SPPP transport protocols;		o Section 4 specifies requirements for SPPP transport protocols;
	o Section 5 describes the base protocol data structures including		o Section 5 describes the base protocol data structures including
	the request and response elements (Section 5.1), the response		the request and response elements (Section 5.1), the response
	codes and messages (Section 5.2) and the basic object type most		codes and messages (Section 5.2) and the basic object type most
	first class objects extend from;		first class objects extend from;
	o Section 6 and Section 7 describe the main protocol commands and		o Section 6 and Section 7 describe the main protocol commands and
	examples;		examples;
	skipping to change at page 7, line 26		skipping to change at page 7, line 26
	SPPP: Session Peering Provisioning Protocol, the protocol used to		SPPP: Session Peering Provisioning Protocol, the protocol used to
	provision data into a Registry (see arrow labeled "1." in Figure 1		provision data into a Registry (see arrow labeled "1." in Figure 1
	of [I-D.ietf-drinks-usecases-requirements]). It is the primary		of [I-D.ietf-drinks-usecases-requirements]). It is the primary
	scope of this document.		scope of this document.
	SPDP: Session Peering Distribution Protocol, the protocol used to		SPDP: Session Peering Distribution Protocol, the protocol used to
	distribute data to Local Data Repository (see arrow labeled "2."		distribute data to Local Data Repository (see arrow labeled "2."
	in Figure 1 of [I-D.ietf-drinks-usecases-requirements]).		in Figure 1 of [I-D.ietf-drinks-usecases-requirements]).
	Client: An application that supports an SPPP Client; it is		Client: An application that supports an SPPP client; it is
	sometimes referred to as a "Registry Client".		sometimes referred to as a "registry client".
	Registry: The Registry operates a master database of Session		Registry: The Registry operates a master database of Session
	Establishment Data for one or more Registrants.		Establishment Data for one or more Registrants.
	A Registry acts as an SPPP Server.		A Registry acts as an SPPP server.
	Registrant: In this document, we extend the definition of a		Registrant: In this document we extend the definition of a
	Registrant based on [RFC4725]. The Registrant is the end-user,		Registrant based on [RFC4725]. The Registrant is the end-user,
	the person or organization who is the "holder" of the Session		the person or organization that is the "holder" of the Session
	Establishment Data being provisioned into the Registry. For		Establishment Data being provisioned into the Registry by a
	example, in [I-D.ietf-drinks-usecases-requirements], a Registrant		Registrar. For example, in
	is pictured as a SIP Service Provider in Figure 2.		[I-D.ietf-drinks-usecases-requirements], a Registrant is pictured
			as a SIP Service Provider in Figure 2.
	A Registrant is uniquely identified by its ID.		Within the confines of a Registry, a Registrant is uniquely
			identified by a well-known ID.
	Registrar: In this document, we also extend the definition of a		Registrar: In this document we extend the definition of a Registrar
	Registrar from [RFC4725]. A Registrar performs provisioning		from [RFC4725]. A Registrar is an entity that performs
	operations on behalf of a Registrant by interacting with the		provisioning operations on behalf of a Registrant by interacting
	Registry, in our case via the SPPP protocol defined in this		with the Registry via SPPP operations. In other words the
	document.		Registrar is the SPPP Client. The Registrar and Registrant roles
			are logically separate to allow, but not require, a single
			Registrar to perform provisioning operations on behalf of more
			than one Registrant.
			Peering Organization: A Peering Organization is an entity to which
			a Registrant's Route Groups are made visible using the operations
			of SPPP.
	3. Protocol High Level Design		3. Protocol High Level Design
	This section introduces the structure of the data model and provides		This section introduces the structure of the data model and provides
	the information framework for the SPPP protocol. An overview of the		the information framework for the SPPP. An overview of the protocol
	protocol operations is first provided with a typical deployment		operations is first provided with a typical deployment scenario. The
	scenario. The data model is then defined along with all the objects		data model is then defined along with all the objects manipulated by
	manipulated by the protocol and their relationships.		the protocol and their relationships.
	3.1. Protocol Layering		3.1. Protocol Layering
	SPPP is a simple request/reply protocol that allows a client		SPPP is a simple request/reply protocol that allows a client
	application to submit provisioning data and query requests to a		application to submit provisioning data and query requests to a
	server. The SPPP data structures are designed to be protocol		server. The SPPP data structures are designed to be protocol
	agnostic. Concerns regarding encryption, non-repudiation, and		agnostic. Concerns regarding encryption, non-repudiation, and
	authentication are beyond the scope of this document. For more		authentication are beyond the scope of this document. For more
	details, please refer to the Transport Protocol Requirements section.		details, please refer to the Transport Protocol Requirements section.
	skipping to change at page 10, line 38		skipping to change at page 10, line 38
	5. The data object layer defines the base set of SPPP data objects		5. The data object layer defines the base set of SPPP data objects
	that can be included in update operations or returned in		that can be included in update operations or returned in
	operation responses.		operation responses.
	3.2. Protocol Data Model		3.2. Protocol Data Model
	The data model illustrated and described in Figure 3 defines the		The data model illustrated and described in Figure 3 defines the
	logical objects and the relationships between these objects that the		logical objects and the relationships between these objects that the
	SPPP protocol supports. SPPP defines the protocol operations through		SPPP protocol supports. SPPP defines the protocol operations through
	which an SPPP Client populates a Registry with these logical objects.		which an SPPP client populates a egistry with these logical objects.
	Various clients belonging to different Registrars may use the		Various clients belonging to different egistrars may use the protocol
	protocol for populating the Registry's data.		for populating the registry's data.
	The logical structure presented below is consistent with the		The logical structure presented below is consistent with the
	terminology and requirements defined in		terminology and requirements defined in
	[I-D.ietf-drinks-usecases-requirements].		[I-D.ietf-drinks-usecases-requirements].
	+-------------+ +------------------+		+-------------+ +------------------+
	| all object | |Organization: |		| all object | |Organization: |
	| types | |orgId |		| types |----->|orgId |
	+------+------+ | |		+------+------+ | |
	+------------>| |		All objects are +------------------+
	All objects are +------------------+		associated with an ^
	associated with an ^		organization to |A Route Group is
	organization to |A Route Group is		identify the |associated with +-----[abstract]-+
	identify the |associated with		object's registrant |zero or more Peering | Route Record: |
	object's registrant |zero or more Peering		|Organizations | rrName, |
	|Organizations		| | priority, |
	|		+--------+--------------+ | extension |
	+--------+--------------+		|Route Group: |------->| |
	|Route Group: | +-----[abstract]-+		| rant, | +----------------+
	| rant, | | Route Record: |		| rgName, | ^
	| rgName, | | rrName, |		| destGrpRef, | |
	| destGrpRef, +------->| priority, |		| isInSvc, | |Various types
	| isInSvc, | | extension |		| rrRef, | |of Route
	| rrRef, | | |		| peeringOrg, | |Records...
	| peeringOrg, | +----------------+		| sourceIdent, | +-----+------------+
	| sourceIdent, | ^		| priority, | | | |
	| priority, | |		| extension | +----+ +-------+ +----+
	| extension | |Various types		+-----------------------+ | URI| | NAPTR | | NS |
	+-----------------------+ |of Route		| +----+ +-------+ +----+
	| |Records...		|
	| +------+------------...		| +----------[abstract]-+
	| | | |		| |Public Identifier: |
	| +----+ +-------+ +----+		| | |
	v | URI| | NAPTR | | NS |		| | rant, |
	+----------------+-----+ +----+ +-------+ +----+		v | publicIdentifier, |
	|Destination |		+----------------------+ | destGrpRef, |
	|Group: | +----------[abstract]-+		| Dest Group: |<----| rrRef, |
	| rant, | |Public Identifier: |		| rant, | | extension |
	| dgName, | | |		| dgName, | +---------------------+
	| extension, | | rant, |		| extension | ^
	+----------------------+ | publicIdentifier, |		+----------------------+ |Various types
	| destGrpRef, |		|of Public
	| rrRef, |		|Identifiers...
	| extension |		+---------+-------+------------...
	+---------------------+		| | | |
	^		+------+ +-----+ +-----+ +-----+
	|Various types		| TN | | TNP | | TNR | | RN |
	|of Public		+------+ +-----+ +-----+ +-----+
	|Identifiers...
	+---------+-------+------------...
	| | | |
	+------+ +-----+ +-----+ +-----+
	| TN | | TNP | | TNR | | RN |
	+------+ +-----+ +-----+ +-----+
	SPPP Data Model		SPPP Data Model
	Figure 3		Figure 3
	The objects and attributes that comprise the data model can be		The objects and attributes that comprise the data model can be
	described as follows (objects listed from the bottom up):		described as follows (objects listed from the bottom up):
	o Public Identifier:		o Public Identifier:
	From a broad perspective a public identifier is a well known		From a broad perspective a public identifier is a well-known
	attribute that is used as the key to perform resolution lookups.		attribute that is used as the key to perform resolution lookups.
	Within the context of SPPP, a Public Identifier object can be a		Within the context of SPPP, a public identifier object can be a
	telephone number, a range of telephone numbers, a PSTN Routing		telephone number, a range of telephone numbers, a PSTN Routing
	Number (RN), or a TN prefix.		Number (RN), or a TN prefix.
	An SPPP Public Identifier is associated with a Destination Group		An SPPP Public Identifier is associated with a Destination Group
	to create a logical grouping of Public Identifiers that share a		to create a logical grouping of Public Identifiers that share a
	common set of Routes.		common set of Routes.
	A TN Public Identifier may optionally be associated with zero or		A TN Public Identifier may optionally be associated with zero or
	more individual Route Records. This ability for a Public		more individual Route Records. This ability for a Public
	Identifier to be directly associated with a set of Route Records		Identifier to be directly associated with a set of Route Records
	skipping to change at page 12, line 33		skipping to change at page 12, line 33
	Destination Group, supports the use cases where the target URI		Destination Group, supports the use cases where the target URI
	contains data specifically tailored to an individual TN Public		contains data specifically tailored to an individual TN Public
	Identifier.		Identifier.
	o Destination Group:		o Destination Group:
	A named collection of zero or more Public Identifiers that can be		A named collection of zero or more Public Identifiers that can be
	associated with one or more Route Groups for the purpose of		associated with one or more Route Groups for the purpose of
	facilitating the management of their common routing information.		facilitating the management of their common routing information.
	o Route Group:		o Route Group:
	A Route Group contains a set of references to Route Records, a set		A Route Group contains a set of Route Record references, a set of
	of Destination Group references, and a set of peering organization		Destination Group references, and a set of peering organization
	identifiers. This is used to establish a three part relationships		identifiers. This is used to establish a three part relationships
	between a set of Public Identifiers and their common routing		between a set of Public Identifiers, the routing information (SED)
	information (SED), and the list of peering organizations whose		shared across the Public Identifiers, and the list of peering
	query responses may include that routing information in their		organizations whose query responses from the resolution system may
	query responses. To support the use cases defined in [I-D.ietf-		include the routing information from a given route group. In
	drinks-usecases-requirements], this document defines the following		addition, the sourceIdent element within a Route Group, in concert
	types of Route Records: NAPTRType, NSType, and URIType. The		with the set of peering organization identifiers, enables fine-
	sourceIdent element within a Route Group, in concert with the set		grained source based routing. For further details about the Route
	of peering organization identifiers enables fine grained source		Group and source based routing, refer to the definitions and
	based routing. Further details about the Route Group and source		descriptions of the Route Group operations found later in this
	based routing refer to the definitions and descriptions of the		document.
	Route Group operations found later in this document.
	o Route Record:		o Route Record:
	A Route Record contains the data that a resolution system returns		A Route Record contains the data that a resolution system returns
	in response to a successful query for a Public Identifier. Route		in response to a successful query for a Public Identifier. Route
	Recoords are associated with a Route Group for SED that is not		Records are generally associated with a Route Group when the SED
	specific to a Public Identifier.		within is not specific to a Public Identifier.
	To support the use cases defined in		To support the use cases defined in
	[I-D.ietf-drinks-usecases-requirements], SPPP protocol defines
	three type of Route Records: URIType, NAPTRType, and NSType.		[I-D.ietf-drinks-usecases-requirements], SPPP defines three type
	These Route Records extend the abstract type RteRecType and		of Route Records: URIType, NAPTRType, and NSType. These Route
	inherit the common attribute 'priority' that is meant for setting		Records extend the abstract type RteRecType and inherit the common
	precedence across the route records defined within a Route Group		attribute 'priority' that is meant for setting precedence across
	in a protocol agnostic fashion.		the route records defined within a Route Group in a protocol
			agnostic fashion.
	o Organization:		o Organization:
	An Organization is an entity that may fulfill any combination of		An Organization is an entity that may fulfill the role of a
	three roles: Registrant, Registrar, and Peering Organization. All		Registrant or of the peering organization. All SPPP objects are
	SPPP objects are associated with an organization identifier to		associated with an organization identifier to identify each
	identify each object's registrant, while tracking the identity of		object's registrant, while tracking the identity of the registrar
	the registrar that provisioned each SPPP object is left as a		that provisioned each SPPP object is left as a matter of policy
	matter of policy for an SPPP implementation. A Route Group object		for an SPPP implementation. A Route Group object is also
	is also associated with a set of zero or more organization		associated with a set of zero or more organization identifiers
	identifiers that identify the peering organization(s) whose		that identify the peering organization(s) whose resolution query
	resolution query responses may include the routing information		responses may include the routing information (SED) defined in the
	(SED) defined in the Route Records within that Route Group.		Route Records within that Route Group. A peering organization is
			an entity that the registrant intends to share the SED data with.
			A route group SPPP object is associated with a set of zero or more
			organization identifiers that identify the peering organizations
			whose resolution query responses may include the routing
			information (SED) defined in the route records within that route
			group.
	4. Transport Protocol Requirements		4. Transport Protocol Requirements
	This section provides requirements for transport protocols suitable		This section provides requirements for transport protocols suitable
	for SPPP. More specifically, this section specifies the services,		for SPPP. More specifically, this section specifies the services,
	features, and assumptions that SPPP delegates to the chosen transport		features, and assumptions that SPPP delegates to the chosen transport
	and envelope technologies.		and envelope technologies.
	Two different groups of use cases are specified in
	[I-D.ietf-drinks-usecases-requirements]. One group of use cases
	describes the provisioning of data by a client into a Registry
	(Section 3.1 of the above referenced document), while the other group
	describes the distribution of data into local data repositories
	(Section 3.2). The current version of this document focuses on the
	first set of use cases (client to registry provisioning).
	These use cases may involve the provisioning of very small data sets
	like the modification or update of a single public identifier. Other
	provisioning operations may deal with huge datasets like the
	"download" of a whole local number portability database to a
	Registry.
	As a result, a transport protocol for SPPP must be very flexible and
	accommodate various sizes of data set sizes.
	For the reasons outlined above, it is conceivable that provisioning
	and distributing may use different transport protocols. This
	document focuses on the provisioning protocol.
	4.1. Connection Oriented		4.1. Connection Oriented
	The SPPP protocol follows a model where a Client establishes a		The SPPP follows a model where a client establishes a connection to a
	connection to a Server in order to further exchange provisioning		server in order to further exchange SPPP messages over such point-to-
	transactions over such point-to-point connection. A transport		point connection. A transport protocol for SPPP MUST therefore be
	protocol for SPPP MUST therefore be connection oriented.		connection oriented.
	Note that the role of the "Client" and the "Server" only applies to
	the connection, and those roles are not related in any way to the
	type of entity that participates in a protocol exchange. For
	example, a Registry might also include a "Client" when such a
	Registry initiates a connection (for example, for data distribution
	to SSP).
	4.2. Request and Response Model		4.2. Request and Response Model
	Provisioning operations in SPPP follow the request - response model,		Provisioning operations in SPPP follow the request-response model,
	where a transaction is initiated by a Client using a Request command,		where a client sends a request message to initiate a transaction and
	and the Server responds to the Client by means of a Response.		the server responds with a response. Multiple subsequent request-
			response exchanges MAY be performed over a single persistent
	Multiple subsequent request-response exchanges MAY be performed over		connection.
	a single connection.
	Therefore, a transport protocol for SPPP MUST follow the request-		Therefore, a transport protocol for SPPP MUST follow the request-
	response model by allowing a response to be sent to the request		response model by allowing a response to be sent to the request
	initiator.		initiator.
	4.3. Connection Lifetime		4.3. Connection Lifetime
	Some use cases involve provisioning a single request to a network		Some use cases involve provisioning a single request to a network
	element - connections supporting such provisioning requests might be		element. Connections supporting such provisioning requests might be
	short-lived, and only established on demand.		short-lived, and may be established only on demand. Other use cases
			involve either provisioning a large dataset, or a constant stream of
	Other use cases involve either provisioning a huge set of data, or a		small updates, either of which would likely require long-lived
	constant stream of small updates, which would require long-lived
	connections.		connections.
	Therefore, a protocol suitable for SPPP SHOULD support short lived as		Therefore, a protocol suitable for SPPP SHOULD be able to support
	well as long lived connections.		both short-lived as well as long-lived connections.
	4.4. Authentication		4.4. Time value
	Many use cases require the Server to authenticate the Client, and		Some SPPP request and response messages include time value(s) defined
	potentially also the Client to authenticate the Server. While		as type xs:dateTime, a built-in W3C XML Schema Datatype. Use of
	authentication of the Server by the Client is expected to be used		unqualified local time is discouraged as it can lead to
	only to prevent impersonation of the Server, authentication of the		interoperability issues. The value of time attribute MUST BE
	Client by the Server is expected to be used to identify and further		expressed in Coordinated Universal Time (UTC) format without the
	authorize the Client to certain resources on the Server.		timezone digits.
	Therefore, an SPPP transport protocol MUST provide means for a Server		"2010-05-30T09:30:10Z" is an example of an acceptable time value for
	to authenticate and authorize a Client, and MAY provide means for		use in SPPP message. "2010-05-30T06:30:10+3:00" is a valid UTC time,
	Clients to authenticate a Server.		but it is not approved for use in SPPP message.
	4.5. Confidentiality and Integrity		4.5. Authentication
	Data that is transported over the protocol is deemed confidential.		All SPPP objects are associated with a registrant identifier. SPPP
	Therefore, a transport protocol suitable for SPPP MUST ensure		Clients provisions SPPP objects on behalf of registrants. An
	confidentiality and integrity protection by providing encryption		authenticated SPP Client is a registrar. Therefore, the SPPP
	capabilities.		transport protocol MUST provide means for an SPPP server to
			authenticate an SPPP Client.
	Additionally, a DRINKS protocol MUST NOT use an unreliable lower-		4.6. Authorization
	layer transport protocol that does not provide confidentiality and
	integrity protection.
	4.6. Near Real Time		After successful authentication of the SPPP client as a registrar the
			registry performs authorization checks to determine if the registrar
			is authorized to act on behalf of the Registrant whose identifier is
			included in the SPPP request. Refer to the Security Considerations
			section for further guidance.
	Many use cases require near real-time responses from the Server.		4.7. Confidentiality and Integrity
	Therefore, a DRINKS transport protocol MUST support near-real-time
	response to requests submitted by the Client.
	4.7. Request and Response Sizes		In some deployments, the SPPP objects that an SPPP registry manages
			can be private in nature. As a result it MAY NOT be appropriate to
			for transmission in plain text over a connection to the SPPP
			registry. Therefore, the transport protocol SHOULD provide means for
			end-to-end encryption between the SPPP client and server.
	SPPP covers a range of use cases - from cases where provisioning a		For some SPPP implementations, it may be acceptable for the data to
	single public identifier will create very small request and response		be transmitted in plain text, but the failure to detect a change in
	sizes to cases where millions of data records are submitted or		data after it leaves the SPPP client and before it is received at the
	retrieved in one transaction. Therefore, a transport protocol		server, either by accident or with a malicious intent, will adversely
	suitable for SPPP MUST support a great variety of request and		affect the stability and integrity of the registry. Therefore, the
	response sizes.		transport protocol SHOULD provide means for data integrity
			protection.
	A transport protocol MAY allow splitting large chunks of data into		4.8. Near Real Time
	several smaller chunks.
	4.8. Request and Response Correlation		Many use cases require near real-time responses from the server.
			Therefore, a DRINKS transport protocol MUST support near real-time
			response to requests submitted by the client.
			4.9. Request and Response Sizes
			Use of SPPP may involve simple updates that may consist of small
			number of bytes, such as, update of a single public identifier.
			Other provisioning operations may constitute large number of datasets
			as in adding millions records to a registry. As a result, a suitable
			transport protocol for SPPP SHOULD accommodate datasets of various
			sizes.
			4.10. Request and Response Correlation
	A transport protocol suitable for SPPP MUST allow responses to be		A transport protocol suitable for SPPP MUST allow responses to be
	correlated with requests.		correlated with requests.
	4.9. Request Acknowledgement		4.11. Request Acknowledgement
	Data transported in the SPPP protocol is likely crucial for the		Data transported in the SPPP is likely crucial for the operation of
	operation of the communication network that is being provisioned.		the communication network that is being provisioned. A SPPP client
			responsible for provisioning SED to the registry has a need to know
			if the submitted requests have been processed correctly.
	Failed transactions can lead to situations where a subset of public		Failed transactions can lead to situations where a subset of public
	identifiers (or even SSPs) might not be reachable, or situations		identifiers or even SSPs might not be reachable, or the provisioning
	where the provisioning state of the network is inconsistent.		state of the network is inconsistent.
	Therefore, a transport protocol for SPPP MUST provide a Response for		Therefore, a transport protocol for SPPP MUST provide a response for
	each Request, so that a Client can identify whether a Request		each request, so that a client can identify whether a request
	succeeded or failed.		succeeded or failed.
	4.10. Mandatory Transport		4.12. Mandatory Transport
	As of this writing of this revision, one transport protocol proposal
	has been provided in [I-D.ietf-drinks-sppp-over-soap].
	This section will define a mandatory transport protocol to be		At the time of this writing, a choice of transport protocol has been
	compliant with this RFC.		provided in [I-D.ietf-drinks-sppp-over-soap]. To encourage
			interoperability, the SPPP server MUST provide support for this
			transport protocol. With time, it is possible that other transport
			layer choices may surface that agree with the requirements discussed
			above.
	5. Base Protocol Data Structures		5. Base Protocol Data Structures
	SPPP uses a common model and a common set of data structures for most		SPPP uses a common model and a common set of data structures for most
	of the supported operations and object types. This section describes		of the supported operations and object types. This section describes
	these common data structures.		these common data structures.
	5.1. Request and Response Structures		5.1. Request and Response Structures
	An SPPP client interacts with an SPPP server by using one of the		An SPPP client interacts with an SPPP server by using one of the
	skipping to change at page 18, line 11		skipping to change at page 18, line 11
	<simpleType name="TransIdType">		<simpleType name="TransIdType">
	<restriction base="string"/>		<restriction base="string"/>
	</simpleType>		</simpleType>
	<simpleType name="MinorVerType">		<simpleType name="MinorVerType">
	<restriction base="unsignedLong"/>		<restriction base="unsignedLong"/>
	</simpleType>		</simpleType>
	The data elements within the <spppUpdateRequest> element are		The data elements within the <spppUpdateRequest> element are
	described as follows:		described as follows:
	o clientTransId: Zero or one client generated transaction ID that,		o clientTransId: Zero or one client-generated transaction ID that,
	within the context of the SPPP client, identifies this request.		within the context of the SPPP client, identifies this request.
	This value can be used at the discretion of the SPPP client to		This value can be used at the discretion of the SPPP client to
	track, log or correlate requests and their responses. This		track, log or correlate requests and their responses. SPPP
	value is also echoed back to the client in the SPPP update		server MUST echo back this value to the client in the
	response. An SPPP server will not check this value for		corresponding response to the incoming request. SPPP server
	uniqueness.		will not check this value for uniqueness.
	o minorVer: Zero or one minor version identifier, indicating the		o minorVer: Zero or one minor version identifier, indicating the
	minor version of the SPPP API that the client is attempting to		minor version of the SPPP API that the client is attempting to
	use. This is used in conjunction with the major version		use. This is used in conjunction with the major version
	identifier in the XML namespace to identify the version of SPPP		identifier in the XML namespace to identify the version of SPPP
	that the client is using. If the element is not present, the		that the client is using. If the element is not present, the
	server assumes that the client is using the latest minor version		server assumes that the client is using the latest minor version
	supported by the SPPP server for the given major version. The		supported by the SPPP server for the given major version. The
	versions supported by a given SPPP server can be retrieved by		versions supported by a given SPPP server can be retrieved by
	the client using the SPPP server menu operation described later		the client using the SPPP server menu operation described later
	skipping to change at page 20, line 9		skipping to change at page 20, line 9
	<extension base="spppb:ResultCodeType">		<extension base="spppb:ResultCodeType">
	<sequence>		<sequence>
	<element name="rqstObj" type="spppb:BasicUpdateRqstType"/>		<element name="rqstObj" type="spppb:BasicUpdateRqstType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	An <spppUpdateResponse> contains the elements necessary for the SPPP		An <spppUpdateResponse> contains the elements necessary for the SPPP
	client to precisely determine the overal result of the request, and		client to precisely determine the overall result of the request, and
	if an error occurred, it provides information about the specific		if an error occurred, it provides information about the specific
	object, data element, or condition caused the error.		object, data element, or condition caused the error.
	The data elements within the SPPP update response are described as		The data elements within the SPPP update response are described as
	follows:		follows:
	o clientTransId: Zero or one client transaction ID. This value is		o clientTransId: Zero or one client transaction ID. This value is
	simply an echo of the client transaction ID that SPPP client		simply an echo of the client transaction ID that SPPP client
	passed into the SPPP update request.		passed into the SPPP update request. When included in the
			request, the SPPP server MUST return it in the corresponding
			response message.
	o serverTransId: Exactly one server transaction ID that identifies		o serverTransId: Exactly one server transaction ID that identifies
	this request for tracking purposes. This value is guaranteed to		this request for tracking purposes. This value MUST be unique
	be unique for a given SPPP server.		for a given SPPP server.
	o overallResult: Exactly one response code and message pair that		o overallResult: Exactly one response code and message pair that
	explicitly identifies the result of the request. See the		explicitly identifies the result of the request. See the
	Response Code section for further details.		Response Code section for further details.
	o rqstObjResult: An optional response code, response message, and		o rqstObjResult: An optional response code, response message, and
	BasicRqstObject triplet. This element will be present only if		BasicRqstObject triplet. This element will be present only if
	an object level error condition occurs, and indicates exactly		an object level error has occurred. It indicates the error
	which error condition occurred and exactly which request object		condition and the exact request object that contributed to the
	that was passed in caused the error condition. The contained		error. The response code will reflect the exact error. See the
	BasicRqstObject is simply an echo of the request object instance		Response Code section for further details.
	that caused the error, while the response code and message
	indicate the error condition for this object. See the Response
	Code section for further details.
	o ext: This is the standard extension element for this object.		o ext: This is the standard extension element for this object.
	Refer to the Extensibility section for more details.		Refer to the Extensibility section for more details.
	5.1.2. Query Request and Response Structures		5.1.2. Query Request and Response Structures
			At times, on behalf of the registrant, the registrar may need to have
			access to SPPP objects that were previously provisioned in the
			registry. A few examples include logging, auditing, and pre-
			provisioning dependency checking. This query mechanism is limited to
			aid provisioning scenarios and should not be confused with query
			protocols provided as part of the resolution system (e.g. ENUM and
			SIP).
	An SPPP query request is wrapped within the <spppQueryRequest>		An SPPP query request is wrapped within the <spppQueryRequest>
	element while an SPPP query response is wrapped within an		element while an SPPP query response is wrapped within an
	<spppQueryResponse> element. The following two sub-sections describe		<spppQueryResponse> element. The following two sub-sections describe
	these two element structures.		these two element structures.
	5.1.2.1. Query Request		5.1.2.1. Query Request
	An SPPP query request object is contained within the generic		An SPPP query request object is contained within the generic
	<spppQueryRequest> element.		<spppQueryRequest> element.
	skipping to change at page 22, line 26		skipping to change at page 22, line 30
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="overallResult" type="spppb:ResultCodeType"/>		<element name="overallResult" type="spppb:ResultCodeType"/>
	<element name="resultSet" type="spppb:BasicObjType"		<element name="resultSet" type="spppb:BasicObjType"
	minOccurs="0" maxOccurs=" unbounded"/>		minOccurs="0" maxOccurs=" unbounded"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	An <spppQueryResponse> contains the elements necessary for the SPPP		An <spppQueryResponse> contains the elements necessary for the SPPP
	client to precisely determine the overal result of the query, and if		client to precisely determine the overall result of the query, and if
	an error occurred, exactly what condition caused the error.		an error occurred, exactly what condition caused the error.
	The data elements within the SPPP query response are described as		The data elements within the SPPP query response are described as
	follows:		follows:
	o overallResult: Exactly one response code and message pair that		o overallResult: Exactly one response code and message pair that
	explicitly identifies the result of the request. See the		explicitly identifies the result of the request. See the
	Response Code section for further details.		Response Code section for further details.
	o resultSet: The set of zero or more objects that matched the		o resultSet: The set of zero or more objects that matched the
	skipping to change at page 24, line 45		skipping to change at page 25, line 26
	existing object do not exist. If the data elements used to		existing object do not exist. If the data elements used to
	uniquely identify an object are malformed, then response code		uniquely identify an object are malformed, then response code
	2104 SHOULD be returned.		2104 SHOULD be returned.
	5.3. Basic Object Type and Organization Identifiers		5.3. Basic Object Type and Organization Identifiers
	This section introduces the basic object type that most first class		This section introduces the basic object type that most first class
	objects derive from.		objects derive from.
	All first class objects extend the basic object type BasicObjType		All first class objects extend the basic object type BasicObjType
	which contains the identifier of the registrant organization that		that contains the identifier of the registrant organization that owns
	owns this object, the date and time that the object was created by		this object, the date and time that the object was created by the
	the server, and the date and time that the object was last modified.		server, and the date and time that the object was last modified.
	<complexType name="BasicObjType" abstract="true">		<complexType name="BasicObjType" abstract="true">
	<sequence>		<sequence>
	<element name="rant" type="spppb:OrgIdType"/>		<element name="rant" type="spppb:OrgIdType"/>
	<element name="cDate" type="dateTime" minOccurs="0"/>		<element name="cDate" type="dateTime" minOccurs="0"/>
	<element name="mDate" type="dateTime" minOccurs="0"/>		<element name="mDate" type="dateTime" minOccurs="0"/>
	<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>		<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	skipping to change at page 27, line 10		skipping to change at page 27, line 10
	<sequence>		<sequence>
	<element name="dgName" type="spppb:ObjNameType"/>		<element name="dgName" type="spppb:ObjNameType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	The DestGrpType object is composed of the following elements:		The DestGrpType object is composed of the following elements:
	o base: All first class objects extend BasicObjType which contains		o base: All first class objects extend BasicObjType that contains
	the ID of the registrant organization that owns this object, the		the ID of the registrant organization that owns this object, the
	date and time that the object was created by the server, and the		date and time that the object was created by the server, and the
	date and time that the object was last modified. If the client		date and time that the object was last modified. If the client
	passed in either the created date or the modification date, the		passed in either the created date or the modification date, the
	server will ignore them. The server sets these two date/time		server will ignore them. The server sets these two date/time
	values.		values.
	o dgName: The character string that contains the name of the		o dgName: The character string that contains the name of the
	Destination Group. This uniquely identifies this object within		Destination Group. This uniquely identifies this object within
	the context of the registrant ID (a child element of the base		the context of the registrant ID (a child element of the base
	skipping to change at page 27, line 34		skipping to change at page 27, line 34
	this document.		this document.
	As with the responses to all update operations, the result of the		As with the responses to all update operations, the result of the
	AddDestGrpRqstType operation is contained in the generic		AddDestGrpRqstType operation is contained in the generic
	spppUpdateResponse data structure described in an earlier sections of		spppUpdateResponse data structure described in an earlier sections of
	this document. For a detailed description of the spppUpdateResponse		this document. For a detailed description of the spppUpdateResponse
	data structure refer to that section of the document.		data structure refer to that section of the document.
	6.2. Get Destination Groups Operation		6.2. Get Destination Groups Operation
	The getDestGrpsRqst operation allows a client to get the properties		The getDestGrpsRqst operation allows an SPPP client to get the
	of Destination Group objects that a registrar organization is		properties of Destination Group objects that a registrar is
	authorized to view. The server will attempt to find a Destination		authorized to view on behalf of the registrant. The server will
	Group object that has the registrant ID and destination group name		attempt to find a Destination Group object that has the registrant ID
	pair contained in each ObjKeyType object instance. If there are no		and destination group name pair contained in each ObjKeyType object
	matching Destination Groups found then an empty result set will be		instance. If there are no matching Destination Groups found then an
	returned. If the set of ObjKeyType objects passed in is empty then		empty result set will be returned. If no ObjKeyType objects are
	the server will return the list of Destination Group objects that the		found in the request then the server will return the list of all
	querying registrar has the authority to view.		Destination Group objects in the registry. If no matching records
			can be located then an empty result set will be returned.
	The element passed into the spppQueryRequest element for this		The element passed into the spppQueryRequest element for this
	operation is an instance of type GetDestGrpsRqstType, which extends		operation is an instance of type GetDestGrpsRqstType, which extends
	BasicQueryRqstType and contains zero or more ObjKeyType objects. Any		BasicQueryRqstType and contains zero or more ObjKeyType objects. Any
	limitation on the maximum number of objects that may be passed into		limitation on the maximum number of objects that may be passed into
	or returned by this operation is a policy decision and not limited by		or returned by this operation is a policy decision and not limited by
	the protocol. The XSD declaration of the operation is as follows:		the protocol. The XSD declaration of the operation is as follows:
	<complexType name="GetDestGrpsRqstType">		<complexType name="GetDestGrpsRqstType">
	<complexContent>		<complexContent>
	skipping to change at page 28, line 29		skipping to change at page 28, line 29
	Refer to that section of the document for a detailed description of		Refer to that section of the document for a detailed description of
	the spppQueryResponse element.		the spppQueryResponse element.
	6.3. Add Public Identifier Operation		6.3. Add Public Identifier Operation
	A Public Identifier is the search key used for locating the session		A Public Identifier is the search key used for locating the session
	establishment data (SED). In many cases, a Public Identifier is		establishment data (SED). In many cases, a Public Identifier is
	attributed to the end user who has a retail relationship with the		attributed to the end user who has a retail relationship with the
	service provider or registrant organization. SPPP supports the		service provider or registrant organization. SPPP supports the
	notion of the carrier-of-record as defined in RFC 5067. Therefore,		notion of the carrier-of-record as defined in RFC 5067. Therefore,
	the Registrant under which the Public Identity is being created can		the registrant under which the Public Identity is being created can
	optionally claim to be a carrier-of-record.		optionally claim to be a carrier-of-record.
	SPPP identifies two types of Public Identifiers: telephone numbers		SPPP identifies two types of Public Identifiers: telephone numbers
	(TN), and the routing numbers (RN). SPPP provides structures to		(TN), and the routing numbers (RN). SPPP provides structures to
	manage a single TN, a contiguous range of TNs, and a TN prefix.		manage a single TN, a contiguous range of TNs, and a TN prefix.
	The abstract XML schema type definition PubIDType is a generalization		The abstract XML schema type definition PubIDType is a generalization
	for the concrete the Public Identifier schema types. PubIDType		for the concrete the Public Identifier schema types. PubIDType
	element 'dgName' represents the name of the destination group that a		element 'dgName' represents the name of the destination group that a
	given Public Identifier is a member of. Because a Destination Group		given Public Identifier is a member of. Because a Destination Group
	is uniquely identified by its composite business key, which is		is uniquely identified by its composite business key, which is
	comprised of its Registrant ID, rantId, and its name, dgName, the		comprised of its registrant ID, rantId, and its name, dgName, the
	Public Identity's containing Destination Group is identified by the		Public Identity's containing Destination Group is identified by the
	Public Identity's dgName element and the Public Identity's registrant		Public Identity's dgName element and the Public Identity's registrant
	ID, rantId, element. The PubIDType object structure is defined as		ID, rantId, element. The PubIDType object structure is defined as
	follows:		follows:
	<complexType name="PubIdType" abstract="true">		<complexType name="PubIdType" abstract="true">
	<complexContent>		<complexContent>
	<extension base="spppb:BasicObjType">		<extension base="spppb:BasicObjType">
	<sequence>		<sequence>
	<element name="dgName" type="spppb:ObjNameType" minOccurs="0"/>		<element name="dgName" type="spppb:ObjNameType" minOccurs="0"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	A registrant can add a Public Identifier using the AddPubIdRqstType		A registrant can add a Public Identifier using the AddPubIdRqstType
	operation. To complete the add request, AddPubIdRqstType XML		operation. To complete the add request, AddPubIdRqstType XML
	instance is populated into the <spppUpdateRequest> element. A Public		instance is populated into the <spppUpdateRequest> element. A Public
	Identifier may provisioned as a member of a Destination Group or		Identifier may be provisioned as a member of a Destination Group or
	provisioned outside of a Destination Group. A Public Identifier that		provisioned outside of a Destination Group. A Public Identifier that
	is provisioned as a member of a Destionation Group is intended to be		is provisioned as a member of a Destination Group is intended to be
	associated with its SED through the Route Group(s) that are		associated with its SED through the Route Group(s) that are
	associated with its containing Destination Group. A Public		associated with its containing Destination Group. A Public
	Identifier that is not provisioned as a member of a Destionation		Identifier that is not provisioned as a member of a Destination Group
	Group is intended to be associated with its SED through the Route		is intended to be associated with its SED through the Route Records
	Records that are directly associated with the Public Identifier. If		that are directly associated with the Public Identifier. If a Public
	a Public Identifier being added already exists then that Public		Identifier being added already exists then that Public Identifier
	Identifier will be replaced with the newly provisioned Public		will be replaced with the newly provisioned Public Identifier.
	Identifier.
	A telephone number is provisioned using the TNType, an extension of		A telephone number is provisioned using the TNType, an extension of
	PubIDType. Each TNType object is uniquely identified by the		PubIDType. Each TNType object is uniquely identified by the
	combination of its tn element, and the unique key of its parent		combination of its <tn> element, and the unique key of its parent
	Destination Group (dgName and rantId). In other words a given		Destination Group (dgName and rantId). In other words a given
	telephone number string may exist within one or more Destination		telephone number string may exist within one or more Destination
	Groups, but must not exist more than once within a Destination Group.		Groups, but must not exist more than once within a Destination Group.
	TNType is defined as follows:		TNType is defined as follows:
	<complexType name="TNType">		<complexType name="TNType">
	<complexContent>		<complexContent>
	<extension base="spppb:PubIdType">		<extension base="spppb:PubIdType">
	<sequence>		<sequence>
	<element name="tn" type="string"/>		<element name="tn" type="string"/>
	skipping to change at page 30, line 4		skipping to change at page 29, line 49
	<extension base="spppb:PubIdType">		<extension base="spppb:PubIdType">
	<sequence>		<sequence>
	<element name="tn" type="string"/>		<element name="tn" type="string"/>
	<element name="rrRef" type="spppb:RteRecRefType"		<element name="rrRef" type="spppb:RteRecRefType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<element name="corInfo" type="spppb:CORInfoType"		<element name="corInfo" type="spppb:CORInfoType"
	minOccurs="0"/>		minOccurs="0"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	TNType consists of the following attributes:		TNType consists of the following attributes:
	o tn: Telephone number to be added to the Registry.		o tn: Telephone number to be added to the registry.
	o rrRef: Optional reference to route records that are directly		o rrRef: Optional reference to route records that are directly
	associated with the TN Public Identifier. Following the SPPP		associated with the TN Public Identifier. Following the SPPP
	data model, the route record could be a protocol agnostic		data model, the route record could be a protocol agnostic
	URIType or another type.		URIType or another type.
	o corInfo: corInfo is an optional parameter of type CORInfoType		o corInfo: corInfo is an optional parameter of type CORInfoType
	that allows the registrant organization to set forth a claim to		that allows the registrant organization to set forth a claim to
	be the carrier-of-record [see RFC 5067]. This is done by		be the carrier-of-record [see RFC 5067]. This is done by
	setting the value of <corClaim> element of the CORInfoType		setting the value of <corClaim> element of the CORInfoType
	object structure to "true". The other two parameters of the		object structure to "true". The other two parameters of the
	CORInfoType, <cor> and <corDate> are set by the Registry to		CORInfoType, <cor> and <corDate> are set by the registry to
	describe the outcome of the carrier-of-record claim by the		describe the outcome of the carrier-of-record claim by the
	registrant. In general, inclusion of <corInfo> parameter is		registrant. In general, inclusion of <corInfo> parameter is
	useful if the Registry has the authority information, such as,		useful if the registry has the authority information, such as,
	the number portability data, etc., in order to qualify whether		the number portability data, etc., in order to qualify whether
	the registrant claim can be satisfied. If the carrier-of-record		the registrant claim can be satisfied. If the carrier-of-record
	claim disagrees with the authority data in the Registry, whether		claim disagrees with the authority data in the registry, whether
	the TN add operation fails or not is a matter of policy and it		the TN add operation fails or not is a matter of policy and it
	is beyond the scope of this document. In the response message		is beyond the scope of this document. In the response message
	<spppUpdateResponse>, the SPPP Server must include the <cor>		<spppUpdateResponse>, the SPPP server must include the <cor>
	parameter of the <corInfo> element to let the registrant know		parameter of the <corInfo> element to let the registrant know
	the outcome of the claim.		the outcome of the claim.
	A routing number is provisioned using the RNType, an extension of		A routing number is provisioned using the RNType, an extension of
	PubIDType. SSPs that possess the number portability data may be able		PubIDType. SSPs that possess the number portability data may be able
	to leverage the RN search key to discover the ingress routes for		to leverage the RN search key to discover the ingress routes for
	session establishment. Therefore, the registrant organization can		session establishment. Therefore, the registrant organization can
	add the RN and associate it with the appropriate destination group to		add the RN and associate it with the appropriate destination group to
	share the route information. Each RNType object is uniquely		share the route information. Each RNType object is uniquely
	identified by the combination of its rn element, and the unique key		identified by the combination of its <rn> element, and the unique key
	of its parent Destination Group (dgName and rantId). In other words		of its parent Destination Group (dgName and rantId). In other words
	a given routing number string may exist within one or more		a given routing number string may exist within one or more
	Destination Groups, but must not exist more than once within a		Destination Groups, but must not exist more than once within a
	Destination Group. RNType is defined as follows:		Destination Group. RNType is defined as follows:
	<complexType name="RNType">		<complexType name="RNType">
	<complexContent>		<complexContent>
	<extension base="spppb:PubIdType">		<extension base="spppb:PubIdType">
	<sequence>		<sequence>
	<element name="rn" type="string"/>		<element name="rn" type="string"/>
	skipping to change at page 31, line 30		skipping to change at page 31, line 30
	o corInfo: Optional <corInfo> element of type CORInfoType.		o corInfo: Optional <corInfo> element of type CORInfoType.
	TNRType structure is used to provision a contiguous range of		TNRType structure is used to provision a contiguous range of
	telephone numbers. The object definition requires a starting TN and		telephone numbers. The object definition requires a starting TN and
	an ending TN that together define the span of the TN range. Use of		an ending TN that together define the span of the TN range. Use of
	TNRType is particularly useful when expressing a TN range that does		TNRType is particularly useful when expressing a TN range that does
	not include all the TNs within a TN block or prefix. The TNRType		not include all the TNs within a TN block or prefix. The TNRType
	definition accommodates the open number plan as well such that the		definition accommodates the open number plan as well such that the
	TNs that fall between the start and end TN range may include TNs with		TNs that fall between the start and end TN range may include TNs with
	different length variance. Whether the Registry can accommodate the		different length variance. Whether the registry can accommodate the
	open number plan semantics is a matter of policy and is beyond the		open number plan semantics is a matter of policy and is beyond the
	scope of this document. Each TNRType object is uniquely identified		scope of this document. Each TNRType object is uniquely identified
	by the combination of its startTn and endTn elements, and the unique		by the combination of its <startTn> and <endTn> elements, and the
	key of its parent Destination Group (dgName and rantId). In other		unique key of its parent Destination Group (dgName and rantId). In
	words a given TN Range may exist within one or more Destination		other words a given TN Range may exist within one or more Destination
	Groups, but must not exist more than once within a Destination Group.		Groups, but must not exist more than once within a Destination Group.
	TNRType object structure definition is as follows:		TNRType object structure definition is as follows:
	<complexType name="TNRType">		<complexType name="TNRType">
	<complexContent>		<complexContent>
	<extension base="spppb:PubIdType">		<extension base="spppb:PubIdType">
	<sequence>		<sequence>
	<element name="startTn" type="string"/>		<element name="startTn" type="string"/>
	<element name="endTn" type="string"/>		<element name="endTn" type="string"/>
	<element name="corInfo" type="spppb:CORInfoType"		<element name="corInfo" type="spppb:CORInfoType"
	skipping to change at page 32, line 19		skipping to change at page 32, line 19
	o startTn: Starting TN in the TN range		o startTn: Starting TN in the TN range
	o endTn: The last TN in the TN range		o endTn: The last TN in the TN range
	o corInfo: Optional <corInfo> element of type CORInfoType		o corInfo: Optional <corInfo> element of type CORInfoType
	In some cases, it is useful to describe a set of TNs with the help of		In some cases, it is useful to describe a set of TNs with the help of
	the first few digits of the telephone number, also referred to as the		the first few digits of the telephone number, also referred to as the
	telephone number prefix or a block. A given TN prefix may include		telephone number prefix or a block. A given TN prefix may include
	TNs with different length variance in support of open number plan.		TNs with different length variance in support of open number plan.
	Once again, whether the Registry supports the open number plan		Once again, whether the registry supports the open number plan
	semantics is a matter of policy and it is beyond the scope of this		semantics is a matter of policy and it is beyond the scope of this
	document. The TNPType data structure is used to provision a TN		document. The TNPType data structure is used to provision a TN
	prefix. Each TNPType object is uniquely identified by the		prefix. Each TNPType object is uniquely identified by the
	combination of its tnPrefix element, and the unique key of its parent		combination of its <tnPrefix> element, and the unique key of its
	Destination Group (dgName and rantId). TNPType is defined as		parent Destination Group (dgName and rantId). TNPType is defined as
	follows:		follows:
	<complexType name="TNPType">		<complexType name="TNPType">
	<complexContent>		<complexContent>
	<extension base="spppb:PubIdType">		<extension base="spppb:PubIdType">
	<sequence>		<sequence>
	<element name="tnPrefix" type="string"/>		<element name="tnPrefix" type="string"/>
	<element name="corInfo" type="spppb:CORInfoType"		<element name="corInfo" type="spppb:CORInfoType"
	minOccurs="0"/>		minOccurs="0"/>
	</sequence>		</sequence>
	skipping to change at page 35, line 36		skipping to change at page 35, line 36
	<complexType name="RteRecRefType">		<complexType name="RteRecRefType">
	<sequence>		<sequence>
	<element name="rrKey" type="spppb:ObjKeyType"/>		<element name="rrKey" type="spppb:ObjKeyType"/>
	<element name="priority" type="unsignedShort"/>		<element name="priority" type="unsignedShort"/>
	<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>		<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	The RteGrpType object is composed of the following elements:		The RteGrpType object is composed of the following elements:
	o base: All first class objects extend BasicObjType which contains		o base: All first class objects extend BasicObjType that contains
	the ID of the registrant organization that owns this object, the		the ID of the registrant organization that owns this object, the
	date and time that the object was created by the server, and the		date and time that the object was created by the server, and the
	date and time that the object was last modified. If the client		date and time that the object was last modified. If the client
	passes in either the created date or the modification date, the		passes in either the created date or the modification date, the
	server will ignore them. The server sets these two date/time		server will ignore them. The server sets these two date/time
	values.		values.
	o rgName: The character string that contains the name of the Route		o rgName: The character string that contains the name of the Route
	Group. It uniquely identifies this object within the context of		Group. It uniquely identifies this object within the context of
	the registrant ID (a child element of the base element as		the registrant ID (a child element of the base element as
	skipping to change at page 38, line 20		skipping to change at page 38, line 20
	this document.		this document.
	As with the responses to all update operations, the result of the		As with the responses to all update operations, the result of the
	AddRteGrpRqstType operation is contained in the generic		AddRteGrpRqstType operation is contained in the generic
	spppUpdateResponse data structure described in an earlier sections of		spppUpdateResponse data structure described in an earlier sections of
	this document. For a detailed description of the spppUpdateResponse		this document. For a detailed description of the spppUpdateResponse
	data structure refer to that section of the document.		data structure refer to that section of the document.
	6.6. Get Route Groups Operation		6.6. Get Route Groups Operation
	The getRteGrpsRqst operation allows a client to get the properties of		The getRteGrpsRqst operation allows a SPPP client to get the
	Route Group objects that a registrar organization is authorized to		properties of Route Group objects that the registrar is authorized to
	view. The server will attempt to find a Route Group object that has		view on behalf of the registrant. The server will attempt to find a
	the registrant ID and route group name pair contained in each		Route Group object that has the registrant ID and route group name
	ObjKeyType object instance. If the set of ObjKeyType objects is		pair contained in each ObjKeyType object instance. If no ObjKeyType
	empty then the server will return the list of Route Group objects		objects are found in the request then the server will return the list
	that the querying client has the authority to view. If there are no		of all Route Group objects that belongs to the registrant. If there
	matching Route Groups found then an empty result set will be		are no matching Route Groups found then an empty result set will be
	returned.		returned.
	The element passed into the spppQueryRequest element for this		The element passed into the spppQueryRequest element for this
	operation is an instance of type GetRteGrpsRqstType, which extends		operation is an instance of type GetRteGrpsRqstType, which extends
	BasicUpdateRqstType and contains zero or more ObjKeyType objects.		BasicUpdateRqstType and contains zero or more ObjKeyType objects.
	Any limitation on the maximum number of objects that may be passed		Any limitation on the maximum number of objects that may be passed
	into or returned by this operation is a policy decision and not		into or returned by this operation is a policy decision and not
	limited by the protocol. The XSD declaration of the operation is as		limited by the protocol. The XSD declaration of the operation is as
	follows:		follows:
	skipping to change at page 39, line 16		skipping to change at page 39, line 16
	Refer to that section of the document for a detailed description of		Refer to that section of the document for a detailed description of
	the spppQueryResponse element.		the spppQueryResponse element.
	6.7. Add Route Record Operation		6.7. Add Route Record Operation
	As described in the introductory sections, a Route Group represents a		As described in the introductory sections, a Route Group represents a
	combined grouping of Route Records that define route information.		combined grouping of Route Records that define route information.
	However, Route Records need not be created to just serve a single		However, Route Records need not be created to just serve a single
	Route Group. Route Records can be created and managed to serve		Route Group. Route Records can be created and managed to serve
	multiple Route Groups. As a result, a change to the properties of a		multiple Route Groups. As a result, a change to the properties of a
	network node, for example, that is used for multiple routes, would		network node used for multiple routes, would necessitate just a
	necessitate just a single update operation to change the properties		single update operation to change the properties of that node. The
	of that node. The change would then be reflected in all the Route		change would then be reflected in all the Route Groups whose route
	Groups whose route record set contains a reference to that node.		record set contains a reference to that node.
	The AddRteRecRqstType operation creates or overwrites a Route Record		The AddRteRecRqstType operation creates or overwrites a Route Record
	object. If a Route Record with the given name and registrant ID		object. If a Route Record with the given name and registrant ID
	(which together comprise the unique key or a Route Record) does not		(which together comprise the unique key or a Route Record) does not
	exist, then the server MUST create the Route Record. If a Route		exist, then the server MUST create the Route Record. If a Route
	Record with the given name and registrant ID does exist, then the		Record with the given name and registrant ID does exist, then the
	server MUST replace the current properties of the Route Record with		server MUST replace the current properties of the Route Record with
	the properties passed into the AddRteRecRqstType operation. The XSD		the properties passed into the AddRteRecRqstType operation. The XSD
	declarations of the AddRteRecRqstType operation request object are as		declarations of the AddRteRecRqstType operation request object are as
	follows:		follows:
	skipping to change at page 40, line 18		skipping to change at page 40, line 18
	<sequence>		<sequence>
	<element name="rrName" type="spppb:ObjNameType"/>		<element name="rrName" type="spppb:ObjNameType"/>
	<element name="priority" type="unsignedShort" minOccurs="0"/>		<element name="priority" type="unsignedShort" minOccurs="0"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	The RteRecType object is composed of the following elements:		The RteRecType object is composed of the following elements:
	o base: All first class objects extend BasicObjType which contains		o base: All first class objects extend BasicObjType that contains
	the ID of the registrant organization that owns this object, the		the ID of the registrant organization that owns this object, the
	date and time that the object was created by the server, and the		date and time that the object was created by the server, and the
	date and time that the object was last modified. If the client		date and time that the object was last modified. If the client
	passes in either the created date or the modification date, the		passes in either the created date or the modification date, the
	server will ignore them. The server sets these two date/time		server will ignore them. The server sets these two date/time
	values.		values.
	o rrName: The character string that contains the name of the Route		o rrName: The character string that contains the name of the Route
	Record. It uniquely identifies this object within the context		Record. It uniquely identifies this object within the context
	of the registrant ID (a child element of the base element as		of the registrant ID (a child element of the base element as
	skipping to change at page 40, line 42		skipping to change at page 40, line 42
	a relative value weighting of one Route Record over another.		a relative value weighting of one Route Record over another.
	The manner in which this value is used, perhaps in conjunction		The manner in which this value is used, perhaps in conjunction
	with other factors, is a matter of policy.		with other factors, is a matter of policy.
	As described above, route records are based on an abstract type:		As described above, route records are based on an abstract type:
	RteRecType. The concrete types that use RteRecType as an extension		RteRecType. The concrete types that use RteRecType as an extension
	base are NAPTRType, NSType, and URIType. The definitions of these		base are NAPTRType, NSType, and URIType. The definitions of these
	types are included below. The NAPTRType object is comprised of the		types are included below. The NAPTRType object is comprised of the
	data elements necessary for a NAPTR that contains routing information		data elements necessary for a NAPTR that contains routing information
	for a Route Group. The NSType object is comprised of the data		for a Route Group. The NSType object is comprised of the data
	elements necessary for a Name Server that points to another DNS		elements necessary for a DNS name server that points to another DNS
	server that contains the desired routing information. The NSType is		server that contains the desired routing information. The NSType is
	relevant only when the resolution protocol is ENUM. The URIType		relevant only when the resolution protocol is ENUM. The URIType
	object is comprised of the data elements necessary to house a URI.		object is comprised of the data elements necessary to house a URI.
	The data provisioned in a Registry can be leveraged for many purposes		The data provisioned in a registry can be leveraged for many purposes
	and queried using various protocols including SIP, ENUM and others.		and queried using various protocols including SIP, ENUM and others.
	It is for this reason that a route record type offers a choice of URI		It is for this reason that a route record type offers a choice of URI
	and DNS resource record types. URIType fulfills the need for both		and DNS resource record types. URIType fulfills the need for both
	SIP and ENUM protocols. When a given URIType is associated to a		SIP and ENUM protocols. When a given URIType is associated to a
	destination group, the user part of the replacement string <uri> that		destination group, the user part of the replacement string <uri> that
	may require the Public Identifier cannot be preset. As a SIP		may require the Public Identifier cannot be preset. As a SIP
	Redirect, the resolution server will apply <ere> pattern on the input		Redirect, the resolution server will apply <ere> pattern on the input
	Public Identifier in the query and process the replacement string by		Public Identifier in the query and process the replacement string by
	substituting any back reference(s) in the <uri> to arrive at the		substituting any back reference(s) in the <uri> to arrive at the
	final URI that is returned in the SIP Contact header. For an ENUM		final URI that is returned in the SIP Contact header. For an ENUM
	skipping to change at page 42, line 32		skipping to change at page 42, line 32
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	The NAPTRType object is composed of the following elements:		The NAPTRType object is composed of the following elements:
	o order: Order value in an ENUM NAPTR, relative to other NAPTRType		o order: Order value in an ENUM NAPTR, relative to other NAPTRType
	objects in the same Route Group.		objects in the same Route Group.
	o svcs: ENUM service(s) that are served by the SBE. This field's		o svcs: ENUM service(s) that are served by the SBE. This field's
	value must be of the form specified in [RFC3761] (e.g., E2U+		value must be of the form specified in [RFC6116] (e.g., E2U+
	pstn:sip+sip). The allowable values are a matter of policy and		pstn:sip+sip). The allowable values are a matter of policy and
	not limited by this protocol.		not limited by this protocol.
	o regx: NAPTR's regular expression field. If this is not included		o regx: NAPTR's regular expression field. If this is not included
	then the Repl field must be included.		then the Repl field must be included.
	o repl: NAPTR replacement field, should only be provided if the		o repl: NAPTR replacement field, should only be provided if the
	Regex field is not provided, otherwise it will be ignored by the		Regex field is not provided, otherwise the server will ignore it
	server.
	o ttl: Number of seconds that an addressing server may cache this		o ttl: Number of seconds that an addressing server may cache this
	NAPTR.		NAPTR.
	o ext: Point of extensibility described in a previous section of		o ext: Point of extensibility described in a previous section of
	this document.		this document.
	The NSType object is composed of the following elements:		The NSType object is composed of the following elements:
	o hostName: Fully qualified host name of the name server.		o hostName: Fully qualified host name of the name server.
	o ipAddr: Zero or more objects of type IpAddrType. Each object		o ipAddr: Zero or more objects of type IpAddrType. Each object
	holds an IP Address and the IP Address type, IPv4 or IP v6.		holds an IP Address and the IP Address type, IPv4 or IP v6.
	o ttl: Number of seconds that an addressing server may cache this		o ttl: Number of seconds that an addressing server may cache this
	Name Server.		DNS name server.
	o ext: Point of extensibility described in a previous section of		o ext: Point of extensibility described in a previous section of
	this document.		this document.
	The URIType object is composed of the following elements:		The URIType object is composed of the following elements:
	o ere: The POSIX Extended Regular Expression (ere) as defined in		o ere: The POSIX Extended Regular Expression (ere) as defined in
	[RFC3986].		[RFC3986].
	o uri: the URI as defined in [RFC3986]. In some cases, this will		o uri: the URI as defined in [RFC3986]. In some cases, this will
	skipping to change at page 43, line 33		skipping to change at page 43, line 33
	resolution server to arrive at the final usable URI.		resolution server to arrive at the final usable URI.
	As with the responses to all update operations, the result of the		As with the responses to all update operations, the result of the
	AddRteRecRqstType operation is contained in the generic		AddRteRecRqstType operation is contained in the generic
	spppUpdateResponse data structure described in an earlier sections of		spppUpdateResponse data structure described in an earlier sections of
	this document. For a detailed description of the spppUpdateResponse		this document. For a detailed description of the spppUpdateResponse
	data structure refer to that section of the document.		data structure refer to that section of the document.
	6.8. Get Route Records Operation		6.8. Get Route Records Operation
	The getRteRecsRqst operation allows a client to get the properties of		The getRteRecsRqst operation allows a SPPP client to get the
	Route Record objects that a registrar organization is authorized to		properties of Route Record objects that a registrar is authorized to
	view. The server will attempt to find a Route Record object that has		view on behalf of the registrant. The server will attempt to find a
	the registrant ID and route record name pair contained in each		Route Record object that has the registrant ID and route record name
	ObjKeyType object instance. If the set of ObjKeyType objects is		pair contained in each ObjKeyType object instance. If no ObjKeyType
	empty then the server will return the list of Route Record objects		objects are found in the request then the server will return the list
	that the querying client has the authority to view. If there are no		of all Route Record that belongs to the registrant. If there are no
	matching Route Record found then an empty result set will be		matching Route Record found then an empty result set will be
	returned.		returned.
	The element passed into the spppQueryRequest element for this		The element passed into the spppQueryRequest element for this
	operation is an instance of type GetRteRecsRqstType, which extends		operation is an instance of type GetRteRecsRqstType, which extends
	BasicUpdateRqstType and contains zero or more ObjKeyType objects.		BasicUpdateRqstType and contains zero or more ObjKeyType objects.
	Any limitation on the maximum number of objects that may be passed		Any limitation on the maximum number of objects that may be passed
	into or returned by this operation is a policy decision and not		into or returned by this operation is a policy decision and not
	limited by the protocol. The XSD declaration of the operation is as		limited by the protocol. The XSD declaration of the operation is as
	follows:		follows:
	skipping to change at page 44, line 38		skipping to change at page 44, line 38
	requests (a data recipient, also know as a peering organization).		requests (a data recipient, also know as a peering organization).
	The registrant offers access to a Route Group by submitting a Route		The registrant offers access to a Route Group by submitting a Route
	Group Offer. The data recipient can then accept or reject that		Group Offer. The data recipient can then accept or reject that
	offer. Not until access to a Route Group has been offered and		offer. Not until access to a Route Group has been offered and
	accepted will the data recipient's organization ID be included in the		accepted will the data recipient's organization ID be included in the
	peeringOrg list in a Route Group object, and that Route Group's		peeringOrg list in a Route Group object, and that Route Group's
	peering information become a candidate for inclusion in the responses		peering information become a candidate for inclusion in the responses
	to the resolution requests submitted by that data recipient. The		to the resolution requests submitted by that data recipient. The
	AddRteGrpOffersRqstType operation creates or overwrites one or more		AddRteGrpOffersRqstType operation creates or overwrites one or more
	Route Group Offer objects. If a Route Group Offer for the given		Route Group Offer objects. If a Route Group Offer for the given
	Route Group object key and the offeredTo Org ID does not exist, then		Route Group object key and the <offeredTo> Org ID does not exist,
	the server creates the Route Group Offer object. If a such a Route		then the server creates the Route Group Offer object. If a such a
	Group Offer does exist, then the server replaces the current object		Route Group Offer does exist, then the server replaces the current
	with the new object. The XSD declarations of the operation request		object with the new object. The XSD declarations of the operation
	object are as follows:		request object are as follows:
	<complexType name="AddRteGrpOfferRqstType">		<complexType name="AddRteGrpOfferRqstType">
	<complexContent>		<complexContent>
	<extension base="spppb:BasicUpdateRqstType">		<extension base="spppb:BasicUpdateRqstType">
	<sequence>		<sequence>
	<element name="rteGrpOffer" type="spppb:RteGrpOfferType"/>		<element name="rteGrpOffer" type="spppb:RteGrpOfferType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	skipping to change at page 46, line 6		skipping to change at page 46, line 6
	</complexType>		</complexType>
	<simpleType name="RteGrpOfferStatusType">		<simpleType name="RteGrpOfferStatusType">
	<restriction base="token">		<restriction base="token">
	<enumeration value="offered"/>		<enumeration value="offered"/>
	<enumeration value="accepted"/>		<enumeration value="accepted"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	The RteGrpOfferType object is composed of the following elements:		The RteGrpOfferType object is composed of the following elements:
	o base: All first class objects extend BasicObjType which contains		o base: All first class objects extend BasicObjType that contains
	the ID of the registrant organization that owns this object, the		the ID of the registrant organization that owns this object, the
	date and time that the object was created by the server, and the		date and time that the object was created by the server, and the
	date and time that the object was last modified. If the client		date and time that the object was last modified. If the client
	passed in either the created date or the modification date, the		passed in either the created date or the modification date, the
	will ignore them. The server sets these two date/time values.		will ignore them. The server sets these two date/time values.
	o rteGrpOfferKey: The object that identifies the route that is or		o rteGrpOfferKey: The object that identifies the route that is or
	has been offered and the organization that it is or has been		has been offered and the organization that it is or has been
	offered to. The combination of these three data elements		offered to. The combination of these three data elements
	uniquely identify a Route Group Offer.		uniquely identify a Route Group Offer.
	o status: The status of the offer, offered or accepted. This		o status: The status of the offer, offered or accepted. The
	status is controlled by the server. It is automatically set to		server controls the status. It is automatically set to
	"offered" when ever a new Route Group Offer is added, and is		"offered" when ever a new Route Group Offer is added, and is
	automatically set to "accepted" if and when that offer is		automatically set to "accepted" if and when that offer is
	accepted. The value of the element is ignored when passed in by		accepted. The value of the element is ignored when passed in by
	the client.		the client.
	o offerDateTime: Date and time in GMT when the Route Group Offer		o offerDateTime: Date and time in UTC when the Route Group Offer
	was added.		was added.
	o acceptDateTime: Date and time in GMT when the Route Group Offer		o acceptDateTime: Date and time in UTC when the Route Group Offer
	was accepted.		was accepted.
	As with the responses to all update operations, the result of the		As with the responses to all update operations, the result of the
	AddRteGrpOfferRqstType operation is contained in the generic		AddRteGrpOfferRqstType operation is contained in the generic
	spppUpdateResponse data structure described in an earlier sections of		spppUpdateResponse data structure described in an earlier sections of
	this document. For a detailed description of the spppUpdateResponse		this document. For a detailed description of the spppUpdateResponse
	data structure refer to that section of the document.		data structure refer to that section of the document.
	6.10. Accept Route Group Offer Operation		6.10. Accept Route Group Offer Operation
	skipping to change at page 47, line 40		skipping to change at page 47, line 40
	option of rejecting a Route Group Offer. Furthermore, that offer may		option of rejecting a Route Group Offer. Furthermore, that offer may
	be rejected, regardless of whether or not it has been previously		be rejected, regardless of whether or not it has been previously
	accepted. The RejectRteGrpOffersRqstType operation is used for these		accepted. The RejectRteGrpOffersRqstType operation is used for these
	purposes and is called by, or on behalf of, the data recipient to		purposes and is called by, or on behalf of, the data recipient to
	accept a Route Group Offer that is pending in the "offered" status or		accept a Route Group Offer that is pending in the "offered" status or
	is in the "accepted" status for the data recipient's organization ID.		is in the "accepted" status for the data recipient's organization ID.
	If a Route Group Offer for the given Route Group Offer key (route		If a Route Group Offer for the given Route Group Offer key (route
	name, route registrant ID, data recipient's organization ID) exists		name, route registrant ID, data recipient's organization ID) exists
	in either the offered or accepted status, then the server deletes		in either the offered or accepted status, then the server deletes
	that Route Group Offer object, and, if appropriate, removes the data		that Route Group Offer object, and, if appropriate, removes the data
	recipients organization ID from the list of peeringOrg IDs for that		recipient's organization ID from the list of peeringOrg IDs for that
	Route Group. If the Route Group Offer does not exist, then the		Route Group. If the Route Group Offer does not exist, then the
	server returns the appropriate error code, 2105. The XSD		server returns the appropriate error code, 2105. The XSD
	declarations for the operation request object are as follows:		declarations for the operation request object are as follows:
	<complexType name="RejectRteGrpOfferRqstType">		<complexType name="RejectRteGrpOfferRqstType">
	<complexContent>		<complexContent>
	<extension base="spppb:BasicUpdateRqstType">		<extension base="spppb:BasicUpdateRqstType">
	<sequence>		<sequence>
	<element name="rteGrpOfferKey" type="spppb:RteGrpOfferKeyType"/>		<element name="rteGrpOfferKey" type="spppb:RteGrpOfferKeyType"/>
	</sequence>		</sequence>
	skipping to change at page 48, line 27		skipping to change at page 48, line 27
	BasicUpdateRqstType and contains a RteGrpOfferKeyType object.		BasicUpdateRqstType and contains a RteGrpOfferKeyType object.
	As with the responses to all update operations, the result of the		As with the responses to all update operations, the result of the
	RejectRteGrpOfferRqstType operation is contained in the generic		RejectRteGrpOfferRqstType operation is contained in the generic
	spppUpdateResponse data structure described in an earlier sections of		spppUpdateResponse data structure described in an earlier sections of
	this document. For a detailed description of the spppUpdateResponse		this document. For a detailed description of the spppUpdateResponse
	data structure refer to that section of the document.		data structure refer to that section of the document.
	6.12. Get Route Group Offers Operation		6.12. Get Route Group Offers Operation
	The getRteGrpOffersRqst operation allows a client to get the		The getRteGrpOffersRqst operation allows a SPPP client to get the
	properties of zero or more Route Group Offer objects that registrar		properties of zero or more Route Group Offer objects that registrar
	is authorized to view. The server will attempt to find Route Group		is authorized to view on behalf of the registrant. The server will
	Offer objects that have all the properties specified in the criteria		attempt to find Route Group Offer objects that have all the
	passed into the operation. If no criteria is passed in then the		properties specified in the criteria passed into the operation. If
	server will return the list of Route Group Offer objects that the		no criteria is passed in then the server will return the list of
	querying client has the authority to view. If there are no matching		Route Group Offer objects that belongs to the registrant. If there
	Route Group Offers found then an empty result set will be returned.		are no matching Route Group Offers found then an empty result set
			will be returned.
	The element passed into the spppQueryRequest element for this		The element passed into the spppQueryRequest element for this
	operation is an instance of GetRteGrpOffersRqstType, which extends		operation is an instance of GetRteGrpOffersRqstType, which extends
	BasicQueryRqstType and contains the criteria that the returned Route		BasicQueryRqstType and contains the criteria that the returned Route
	Group Offer objects must match. Any limitation on the maximum number		Group Offer objects must match. Any limitation on the maximum number
	of objects that may be returned by this operation is a policy		of objects that may be returned by this operation is a policy
	decision and not limited by the protocol. The XSD declaration of the		decision and not limited by the protocol. The XSD declaration of the
	operation is as follows:		operation is as follows:
	<complexType name="GetRteGrpOffersRqstType">		<complexType name="GetRteGrpOffersRqstType">
	skipping to change at page 50, line 15		skipping to change at page 50, line 15
	6.13. Egress Route Operations		6.13. Egress Route Operations
	In a high-availability environment, the originating SSP likely has		In a high-availability environment, the originating SSP likely has
	more than one egress paths to the ingress SBE of the target SSP. If		more than one egress paths to the ingress SBE of the target SSP. If
	the originating SSP wants to exercise greater control and choose a		the originating SSP wants to exercise greater control and choose a
	specific egress SBE to be associated to the target ingress SBE, it		specific egress SBE to be associated to the target ingress SBE, it
	can do so using the AddEgrRteRqstType object.		can do so using the AddEgrRteRqstType object.
	Lets assume that the target SSP has offered to share one or more		Lets assume that the target SSP has offered to share one or more
	ingress route information and that the originating SSP has accepted		ingress route information and that the originating SSP has accepted
	the offer. In order to add the egress route to the Registry, the		the offer. In order to add the egress route to the registry, the
	originating SSP uses a valid regular expression to rewrite ingress		originating SSP uses a valid regular expression to rewrite ingress
	route in order to include the egress SBE information. Also, more		route in order to include the egress SBE information. Also, more
	than one egress route can be associated with a given ingress route in		than one egress route can be associated with a given ingress route in
	support of fault-tolerant configurations. The supporting SPPP		support of fault-tolerant configurations. The supporting SPPP
	protocol structure provides a way to include route precedence		structure provides a way to include route precedence information to
	information to help manage traffic to more than one outbound egress		help manage traffic to more than one outbound egress SBE.
	SBE.
	An egress route is identified by type EgrRteType and its object		An egress route is identified by type EgrRteType and its object
	structure is shown below:		structure is shown below:
	<complexType name="EgrRteType">		<complexType name="EgrRteType">
	<complexContent>		<complexContent>
	<extension base="spppb:BasicObjType">		<extension base="spppb:BasicObjType">
	<sequence>		<sequence>
	<element name="egrRteName" type="spppb:ObjNameType"/>		<element name="egrRteName" type="spppb:ObjNameType"/>
	<element name="pref" type="unsignedShort"/>		<element name="pref" type="unsignedShort"/>
	skipping to change at page 50, line 44		skipping to change at page 50, line 43
	<element name="ingrRteRec" type="spppb:ObjKeyType"		<element name="ingrRteRec" type="spppb:ObjKeyType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>		<element name="ext" type="spppb:ExtAnyType" minOccurs="0"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	The EgrRteType object is composed of the following elements:		The EgrRteType object is composed of the following elements:
	o base: All first class objects extend BasicObjType which contains		o base: All first class objects extend BasicObjType that contains
	the ID of the registrant organization that owns this object, the		the ID of the registrant organization that owns this object, the
	date and time that the object was created by the server, and the		date and time that the object was created by the server, and the
	date and time that the object was last modified. If the client		date and time that the object was last modified. If the client
	passes in either the created date or the modification date, the		passes in either the created date or the modification date, the
	server will ignore them. The server sets these two date/time		server will ignore them. The server sets these two date/time
	values.		values.
	o egrRteName: The name of the egress route.		o egrRteName: The name of the egress route.
	o pref: The preference of this egress route relative to other		o pref: The preference of this egress route relative to other
	skipping to change at page 52, line 18		skipping to change at page 52, line 18
	<sequence>		<sequence>
	<element name="objKey" type="spppb:ObjKeyType"		<element name="objKey" type="spppb:ObjKeyType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	6.14. Delete Operation		6.14. Delete Operation
	In order to remove an object from the Registry, an authorized entity		In order to remove an object from the registry, an authorized entity
	can send the <spppUpdateRequest> to the Registry with a corresponding		can send the <spppUpdateRequest> to the registry with a corresponding
	delete BasicUpdateRqstType object. Each 'Add' operation in SPPP has		delete BasicUpdateRqstType object. Each 'Add' operation in SPPP has
	a corresponding 'Del' operation, which is used to delete the		a corresponding 'Del' operation, which is used to delete the
	respective object type from the Registry. If the entity that issued		respective object type from the registry. If the entity that issued
	the command is not authorized to perform this operation an		the command is not authorized to perform this operation an
	appropriate error code will be returned in the <spppUpdateRespnonse>		appropriate error code will be returned in the <spppUpdateRespnonse>
	message.		message.
	As an example, DelPubIdRqstType is used to delete Public Identifiers		As an example, DelPubIdRqstType is used to delete Public Identifiers
	The DelPubIdsRqstType object definition is shown below:		The DelPubIdsRqstType object definition is shown below:
	<complexType name="DelPubIdRqstType">		<complexType name="DelPubIdRqstType">
	<complexContent>		<complexContent>
	<extension base="spppb:BasicUpdateRqstType">		<extension base="spppb:BasicUpdateRqstType">
	skipping to change at page 53, line 25		skipping to change at page 53, line 25
	by the SPPP implementation as part of fulfilling the deletion		by the SPPP implementation as part of fulfilling the deletion
	request. Furthermore, route group offers relating that route		request. Furthermore, route group offers relating that route
	group must also be deleted as part of fulfilling the deletion		group must also be deleted as part of fulfilling the deletion
	request.		request.
	o Route Records: When a route record is deleted any references		o Route Records: When a route record is deleted any references
	between that route record and any route group must be removed by		between that route record and any route group must be removed by
	the SPPP implementation as part of fulfilling the deletion		the SPPP implementation as part of fulfilling the deletion
	request.		request.
	o Puplic Identifiers: When a public identifier is deleted any		o Public Identifiers: When a public identifier is deleted any
	references between that public identifier and its containing		references between that public identifier and its containing
	destination group must be removed by the SPPP implementation as		destination group must be removed by the SPPP implementation as
	part of fulfilling the deletion request. And any route records		part of fulfilling the deletion request. And any route records
	contained directly within that Public Identifier must be deleted		contained directly within that Public Identifier must be deleted
	by the SPPP implementation as part of fulfilling the deletion		by the SPPP implementation as part of fulfilling the deletion
	request.		request.
	7. SPPP Examples		7. SPPP Examples
	This section shows XML message exchange between two SIP Service		This section shows XML message exchange between two SIP Service
	Providers (SSP) and a Registry. For the sake of simplicity, the		Providers (SSP) and a registry. For the sake of simplicity, the
	transport wrapper for the SPPP protocol is left out. The SPPP		transport wrapper for the SPPP is left out. The SPPP messages in
	protocol messages in this section are valid XML instances that		this section are valid XML instances that conform to the SPPP schema
	conform to the SPPP schema version within this document.		version within this document.
	In this sample use case scenario, SSP1 and SSP2 provision resource		In this sample use case scenario, SSP1 and SSP2 provision resource
	data in the registry and use SPPP constructs to selectively share the		data in the registry and use SPPP constructs to selectively share the
	route groups. In the figure below, SSP2 has two ingress SBE		route groups. In the figure below, SSP2 has two ingress SBE
	instances that are associated with the public identities that SSP2		instances that are associated with the public identities that SSP2
	has the retail relationship with. Also, the two SBE instances for		has the retail relationship with. Also, the two SBE instances for
	SSP1 are used to show how to use SPPP protocol to associate route		SSP1 are used to show how to use SPPP to associate route preferences
	preferences for the destination ingress routes and exercise greater		for the destination ingress routes and exercise greater control on
	control on outbound traffic to the peer's ingress SBEs.		outbound traffic to the peer's ingress SBEs.
	---------------+ +------------------		---------------+ +------------------
	| |		| |
	+------+ +------+		+------+ +------+
	| sbe1 | | sbe2 |		| sbe1 | | sbe2 |
	+------+ +------+		+------+ +------+
	SSP1 | | SSP2		SSP1 | | SSP2
	+------+ +------+		+------+ +------+
	| sbe3 | | sbe4 |		| sbe3 | | sbe4 |
	+------+ +------+		+------+ +------+
	iana-en:111 | | iana-en:222		iana-en:111 | | iana-en:222
	---------------+ +------------------		---------------+ +------------------
	| |		| |
	| |		| |
	| SPPP +------------------+ SPPP |		| SPPP +------------------+ SPPP |
	+------->| Registry |<--------+		+------->| Registry |<--------+
	+------------------+		+------------------+
	7.1. Add Destination Group		7.1. Add Destination Group
	SSP2 adds a destination group to the Registry for use later. The		SSP2 adds a destination group to the registry for use later. The
	SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for		SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for
	tracking purposes. The name of the destination group is set to		tracking purposes. The name of the destination group is set to
	DEST_GRP_SSP2_1		DEST_GRP_SSP2_1
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateRequest		<spppUpdateRequest
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<clientTransId>txid-5555</clientTransId>		<clientTransId>txid-5555</clientTransId>
	<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"		<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
	xsi:type="ns1:AddDestGrpRqstType">		xsi:type="ns1:AddDestGrpRqstType">
	<destGrp>		<destGrp>
	<ns1:rant>iana-en:222</ns1:rant>		<ns1:rant>iana-en:222</ns1:rant>
	<dgName>DEST_GRP_SSP2_1</dgName>		<dgName>DEST_GRP_SSP2_1</dgName>
	</destGrp>		</destGrp>
	</rqst>		</rqst>
	</spppUpdateRequest>		</spppUpdateRequest>
	The Registry processes the request and return a favorable response		The registry processes the request and return a favorable response
	confirming successful creation of the named destination group. Also,		confirming successful creation of the named destination group. Also,
	besides returning a unique transaction identifier, Registry also		besides returning a unique transaction identifier, Registry also
	returns the matching client transaction identifier from the request		returns the matching client transaction identifier from the request
	message back to the SPPP client.		message back to the SPPP client.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateResponse		<spppUpdateResponse
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<clientTransId>tx_5555</clientTransId>		<clientTransId>tx_5555</clientTransId>
	<serverTransId>tx_id_12346</serverTransId>		<serverTransId>tx_id_12346</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>success</msg>		<msg>success</msg>
	</overallResult>		</overallResult>
	</spppUpdateResponse>		</spppUpdateResponse>
	7.2. Add Route Records		7.2. Add Route Records
	SSP2 adds an ingress routes in the Registry.		SSP2 adds an ingress routes in the registry.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateRequest		<spppUpdateRequest
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"		<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
	xsi:type="ns1:AddRteRecRqstType">		xsi:type="ns1:AddRteRecRqstType">
	<rteRec xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"		<rteRec xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
	xsi:type="ns1:NAPTRType">		xsi:type="ns1:NAPTRType">
	skipping to change at page 56, line 27		skipping to change at page 56, line 27
	<flags>u</flags>		<flags>u</flags>
	<svcs>E2U+sip</svcs>		<svcs>E2U+sip</svcs>
	<regx>		<regx>
	<ere>^(.*)$</ere>		<ere>^(.*)$</ere>
	<repl>sip:\1@sbe2.ssp2.example.com</repl>		<repl>sip:\1@sbe2.ssp2.example.com</repl>
	</regx>		</regx>
	</rteRec>		</rteRec>
	</rqst>		</rqst>
	</spppUpdateRequest>		</spppUpdateRequest>
	The Registry returns a success response.		The registry returns a success response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateResponse		<spppUpdateResponse
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<serverTransId>tx_id_11145</serverTransId>		<serverTransId>tx_id_11145</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request successful</msg>		<msg>Request successful</msg>
	</overallResult>		</overallResult>
	</spppUpdateResponse>		</spppUpdateResponse>
	7.3. Add Route Records -- URIType		7.3. Add Route Records -- URIType
	SSP2 adds another ingress routes in the Registry and makes use of		SSP2 adds another ingress routes in the registry and makes use of
	URIType		URIType
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateRequest>		<spppUpdateRequest>
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"		<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
	xsi:type="ns1:AddRteRecRqstType">		xsi:type="ns1:AddRteRecRqstType">
	<rteRec xsi:type="ns1:URIType">		<rteRec xsi:type="ns1:URIType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<rrName>RTE_SSP2_SBE4</rrName>		<rrName>RTE_SSP2_SBE4</rrName>
	<ere>^(.*)$</ere>		<ere>^(.*)$</ere>
	<uri>sip:\1;npdi@sbe4.ssp2.example.com</uri>		<uri>sip:\1;npdi@sbe4.ssp2.example.com</uri>
	</rteRec>		</rteRec>
	</rqst>		</rqst>
	</spppUpdateRequest>		</spppUpdateRequest>
	The Registry returns a success response.		The registry returns a success response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateResponse		<spppUpdateResponse
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<serverTransId>tx_id_11145</serverTransId>		<serverTransId>tx_id_11145</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request successful</msg>		<msg>Request successful</msg>
	skipping to change at page 58, line 29		skipping to change at page 58, line 29
	</rrKey>		</rrKey>
	<priority>100</priority>		<priority>100</priority>
	</rrRef>		</rrRef>
	<dgName>DEST_GRP_SSP2_1</dgName>		<dgName>DEST_GRP_SSP2_1</dgName>
	<isInSvc>true</isInSvc>		<isInSvc>true</isInSvc>
	<ns1:priority>10</ns1:priority>		<ns1:priority>10</ns1:priority>
	</rteGrp>		</rteGrp>
	</rqst>		</rqst>
	</spppUpdateRequest>		</spppUpdateRequest>
	To confirm successful processing of this request, Registry returns a		To confirm successful processing of this request, registry returns a
	well-known resolution code '1000' to the SSP2 client.		well-known resolution code '1000' to the SSP2 client.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateResponse		<spppUpdateResponse
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<serverTransId>tx_id_12345</serverTransId>		<serverTransId>tx_id_12345</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	skipping to change at page 59, line 24		skipping to change at page 59, line 24
	<cDate>2010-05-30T09:30:10Z</cDate>		<cDate>2010-05-30T09:30:10Z</cDate>
	<dgName>DEST_GRP_SSP2_1</dgName>		<dgName>DEST_GRP_SSP2_1</dgName>
	<tn>+12025556666</tn>		<tn>+12025556666</tn>
	<corInfo>		<corInfo>
	<corClaim>true</corClaim>		<corClaim>true</corClaim>
	</corInfo>		</corInfo>
	</pi>		</pi>
	</rqst>		</rqst>
	</spppUpdateRequest>		</spppUpdateRequest>
	Assuming that the Registry has access to TN authority data and it		Assuming that the registry has access to TN authority data and it
	performs the required checks to verify that SSP2 is in fact the		performs the required checks to verify that SSP2 is in fact the
	service provider of record for the given TN, the request is processed		service provider of record for the given TN, the request is processed
	successfully. In the response message, the Registry sets the value		successfully. In the response message, the registry sets the value
	of <cor> to "true" in order to confirm SSP2 claim as the carrier of		of <cor> to "true" in order to confirm SSP2 claim as the carrier of
	record and the <corDate> reflects the time when the carrier of record		record and the <corDate> reflects the time when the carrier of record
	claim is processed.		claim is processed.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateResponse		<spppUpdateResponse
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<clientTransId>txid-5577</clientTransId>		<clientTransId>txid-5577</clientTransId>
	skipping to change at page 64, line 28		skipping to change at page 64, line 28
	<offeredTo>iana-en:111</offeredTo>		<offeredTo>iana-en:111</offeredTo>
	</rteGrpOfferKey>		</rteGrpOfferKey>
	<status>offered</status>		<status>offered</status>
	<offerDateTime>2006-05-04T18:13:51.0Z</offerDateTime>		<offerDateTime>2006-05-04T18:13:51.0Z</offerDateTime>
	</rteGrpOffer>		</rteGrpOffer>
	</rqst>		</rqst>
	</spppUpdateRequest>		</spppUpdateRequest>
	Registry completes the request successfully and confirms that the		Registry completes the request successfully and confirms that the
	SSP1 will now have the opportunity to weigh in on the offer and		SSP1 will now have the opportunity to weigh in on the offer and
	either accept or reject it. The Registry may employ out-of-band		either accept or reject it. The registry may employ out-of-band
	notification mechanisms for quicker updates to SSP1 so they can act		notification mechanisms for quicker updates to SSP1 so they can act
	faster, though this topic is beyond the scope of this document.		faster, though this topic is beyond the scope of this document.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateResponse		<spppUpdateResponse
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
	xmlns="urn:ietf:params:xml:ns:sppp:base:1">		xmlns="urn:ietf:params:xml:ns:sppp:base:1">
	<serverTransId>tx_id_12277798</serverTransId>		<serverTransId>tx_id_12277798</serverTransId>
	<overallResult>		<overallResult>
	skipping to change at page 73, line 19		skipping to change at page 73, line 19
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd">		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd">
	<serverTransId>txid-982543123</serverTransId>		<serverTransId>txid-982543123</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Success</msg>		<msg>Success</msg>
	</overallResult>		</overallResult>
	</spppUpdateResponse>		</spppUpdateResponse>
	7.18. Delete Public Identity		7.18. Delete Public Identity
	SSP2 choses to de-activate the TN and remove it from the Registry.		SSP2 choses to de-activate the TN and remove it from the registry.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<spppUpdateRequest xmlns="urn:ietf:params:xml:ns:sppp:base:1"		<spppUpdateRequest xmlns="urn:ietf:params:xml:ns:sppp:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd">		xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd">
	<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"		<rqst xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
	xsi:type="ns1:DelPubIdRqstType">		xsi:type="ns1:DelPubIdRqstType">
	<pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"		<pi xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1"
	xsi:type="ns1:TNType">		xsi:type="ns1:TNType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	skipping to change at page 77, line 21		skipping to change at page 77, line 21
	XML is case sensitive. Unless stated otherwise, XML specifications		XML is case sensitive. Unless stated otherwise, XML specifications
	and examples provided in this document MUST be interpreted in the		and examples provided in this document MUST be interpreted in the
	character case presented to develop a conforming implementation.		character case presented to develop a conforming implementation.
	This section discusses a small number of XML-related considerations		This section discusses a small number of XML-related considerations
	pertaining to SPPP.		pertaining to SPPP.
	8.1. Namespaces		8.1. Namespaces
	All SPPP protocol elements are defined in the namespaces in the IANA		All SPPP elements are defined in the namespaces in the IANA
	Considerations section and in the Formal Protocol Specification		Considerations section and in the Formal Protocol Specification
	section of this document.		section of this document.
	8.2. Versioning and Character Encoding		8.2. Versioning and Character Encoding
	All XML instances SHOULD begin with an <?xml?> declaration to		All XML instances SHOULD begin with an <?xml?> declaration to
	identify the version of XML that is being used, optionally identify		identify the version of XML that is being used, optionally identify
	use of the character encoding used, and optionally provide a hint to		use of the character encoding used, and optionally provide a hint to
	an XML parser that an external schema file is needed to validate the		an XML parser that an external schema file is needed to validate the
	XML instance.		XML instance.
	skipping to change at page 78, line 7		skipping to change at page 78, line 7
	attribute in the XML declaration is OPTIONAL if UTF-8 encoding is		attribute in the XML declaration is OPTIONAL if UTF-8 encoding is
	used. SPPP clients and servers MUST accept a UTF-8 BOM if present,		used. SPPP clients and servers MUST accept a UTF-8 BOM if present,
	though emitting a UTF-8 BOM is NOT RECOMMENDED.		though emitting a UTF-8 BOM is NOT RECOMMENDED.
	Example XML declarations:		Example XML declarations:
	<?xml?> version="1.0" encoding="UTF-8" standalone="no"?>		<?xml?> version="1.0" encoding="UTF-8" standalone="no"?>
	9. Security Considerations		9. Security Considerations
	SPPP implementations manage data that is considered confidential and		Many SPPP implementations manage data that is considered confidential
	critical. Furthermor, SPPP implementations can support provisioning		and critical. Furthermore, SPPP implementations can support
	activities for multiple registrars and registrants. As a result any		provisioning activities for multiple registrars and registrants. As
	SPPP implementation must address the requirements for		a result any SPPP implementation must address the requirements for
	confidentiality, authentication, and authorization.		confidentiality, authentication, and authorization.
	With respect to confidentiality and authentication, the transport		With respect to confidentiality and authentication, the transport
	protocol section contains some security properties that the transport		protocol requirements section of this document contains security
	protocol must provide so that authenticated endpoints can exchange		properties that the transport protocol must provide so that
	data confidentially and with integrity protection.		authenticated endpoints can exchange data confidentially and with
			integrity protection. Refer to that section and the resulting
			transport protocol specification document for the specific solutions
			to authentication and confidentiality.
	With respect to authorization, the SPPP server implementation must		With respect to authorization, the SPPP server implementation must
	define and implement a set of authorization rules that precisely		define and implement a set of authorization rules that precisely
	address (1) which registrars will be authorized to create/modify/		address (1) which registrars will be authorized to create/modify/
	delete each SPPP object type for given registrant(s) and (2) which		delete each SPPP object type for given registrant(s) and (2) which
	registrars will be authorized to view/get each SPPP object type for a		registrars will be authorized to view/get each SPPP object type for
	given registrant(s). These authorization rules are left as a matter		given registrant(s). These authorization rules are a matter of
	of policy and are not specified within the context of SPPP. However,		policy and are not specified within the context of SPPP. However,
	any SPPP implementation must specify these authorization rules in		any SPPP implementation must specify these authorization rules in
	order to function in a realiable and safe manner.		order to function in a reliable and safe manner.
	10. IANA Considerations		10. IANA Considerations
	This document uses URNs to describe XML namespaces and XML schemas		This document uses URNs to describe XML namespaces and XML schemas
	conforming to a registry mechanism described in [RFC3688].		conforming to a registry mechanism described in [RFC3688].
	Two URI assignments are requested.		Two URI assignments are requested.
	Registration request for the SPPP XML namespace:		Registration request for the SPPP XML namespace:
	urn:ietf:params:xml:ns:sppp:base:1		urn:ietf:params:xml:ns:sppp:base:1
	skipping to change at page 80, line 7		skipping to change at page 80, line 7
	known enterprise namespaces.		known enterprise namespaces.
	This document makes the following assignments for the OrgIdType		This document makes the following assignments for the OrgIdType
	namespaces:		namespaces:
	Namespace OrgIdType namespace string		Namespace OrgIdType namespace string
	---- ----------------------------		---- ----------------------------
	IANA Enterprise Numbers iana-en		IANA Enterprise Numbers iana-en
	11. Formal Specification		11. Formal Specification
	This section provides the draft XML Schema Definition for the SPPP		This section provides the draft XML Schema Definition for SPPP.
	protocol.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"		<schema xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
	xmlns="http://www.w3.org/2001/XMLSchema"		xmlns="http://www.w3.org/2001/XMLSchema"
	targetNamespace="urn:ietf:params:xml:ns:sppp:base:1"		targetNamespace="urn:ietf:params:xml:ns:sppp:base:1"
	elementFormDefault="qualified" xml:lang="EN">		elementFormDefault="qualified" xml:lang="EN">
	<annotation>		<annotation>
	<documentation>		<documentation>
	------------------ Object Type Definitions --------------		------------------ Object Type Definitions --------------
	</documentation>		</documentation>
	skipping to change at page 94, line 11		skipping to change at page 94, line 11
	Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa		Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa
	Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard		Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard
	Shockey, Samuel Melloul, and Sumanth Channabasappa.		Shockey, Samuel Melloul, and Sumanth Channabasappa.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-drinks-sppp-over-soap]		[I-D.ietf-drinks-sppp-over-soap]
	Cartwright, K., "SPPP Over SOAP and HTTP",		Cartwright, K., "SPPP Over SOAP and HTTP",
	draft-ietf-drinks-sppp-over-soap-02 (work in progress),		draft-ietf-drinks-sppp-over-soap-04 (work in progress),
	February 2011.		July 2011.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and		[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
	Languages", BCP 18, RFC 2277, January 1998.		Languages", BCP 18, RFC 2277, January 1998.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	skipping to change at page 94, line 45		skipping to change at page 94, line 45
	(work in progress), March 2011.		(work in progress), March 2011.
	[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO		[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
	10646", RFC 2781, February 2000.		10646", RFC 2781, February 2000.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
	Resource Identifiers (URI) Dynamic Delegation Discovery
	System (DDDS) Application (ENUM)", RFC 3761, April 2004.
	[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation		[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
	Architecture", RFC 4725, November 2006.		Architecture", RFC 4725, November 2006.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	October 2008.		October 2008.
	[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia		[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
	Interconnect (SPEERMINT) Terminology", RFC 5486,		Interconnect (SPEERMINT) Terminology", RFC 5486,
	March 2009.		March 2009.
			[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
			Uniform Resource Identifiers (URI) Dynamic Delegation
			Discovery System (DDDS) Application (ENUM)", RFC 6116,
			March 2011.
	Authors' Addresses		Authors' Addresses
	Jean-Francois Mule		Jean-Francois Mule
	CableLabs		CableLabs
	858 Coal Creek Circle		858 Coal Creek Circle
	Louisville, CO 80027		Louisville, CO 80027
	USA		USA
	Email: jfm@cablelabs.com		Email: jfm@cablelabs.com
End of changes. 129 change blocks.
	396 lines changed or deleted		408 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/