draft-ietf-drinks-spp-protocol-over-soap-09.txt		rfc7878.txt
	DRINKS K. Cartwright		Internet Engineering Task Force (IETF) K. Cartwright
	Internet-Draft V. Bhatia		Request for Comments: 7878 V. Bhatia
	Intended status: Standards Track TNS		Category: Standards Track TNS
	Expires: October 5, 2016 J-F. Mule		ISSN: 2070-1721 J-F. Mule
	CableLabs		Apple Inc.
	A. Mayrhofer		A. Mayrhofer
	nic.at GmbH		nic.at GmbH
	April 3, 2016		August 2016
	Session Peering Provisioning (SPP) Protocol over SOAP		Session Peering Provisioning (SPP) Protocol over SOAP
	draft-ietf-drinks-spp-protocol-over-soap-09
	Abstract		Abstract
	The Session Peering Provisioning Framework (SPPF) specifies the data		The Session Peering Provisioning Framework (SPPF) specifies the data
	model and the overall structure to provision session establishment		model and the overall structure to provision Session Establishment
	data into Session Data Registries and SIP Service Provider data		Data (SED) into Session Data Registries and SIP Service Provider data
	stores. To utilize this framework one needs a substrate protocol.		stores. To utilize this framework, one needs a substrate protocol.
	Given that Simple Object Access Protocol (SOAP) is currently widely		Given that the Simple Object Access Protocol (SOAP) is currently
	used for messaging between elements of such provisioning systems,		widely used for messaging between elements of such provisioning
	this document specifies the usage of SOAP (via HTTPS) as the		systems, this document specifies the usage of SOAP (via HTTPS) as the
	substrate protocol for SPPF. The benefits include leveraging		substrate protocol for SPPF. The benefits include leveraging
	prevalent expertise, and a higher probability that existing		prevalent expertise and a higher probability that existing
	provisioning systems will be able to easily migrate to using an SPPF		provisioning systems will be able to easily migrate to using an SPPF-
	based protocol.		based protocol.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on October 5, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7878.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4		3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4
	4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 7		4. HTTP(S) Features and SPPP over SOAP . . . . . . . . . . . . . 7
	5. Authentication, Integrity and Confidentiality . . . . . . . . 7		5. Authentication, Integrity, and Confidentiality . . . . . . . 7
	6. Language Identification . . . . . . . . . . . . . . . . . . . 7		6. Language Identification . . . . . . . . . . . . . . . . . . . 7
	7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 7		7. SPPP SOAP Data Structures . . . . . . . . . . . . . . . . . . 7
	7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 8		7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 8
	7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8		7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8
	7.1.2. Public Identifier Object Key . . . . . . . . . . . . 9		7.1.2. Public Identifier Object Key . . . . . . . . . . . . 9
	7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10		7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10
	7.2. Operation Request and Response Structures . . . . . . . . 11		7.2. Operation Request and Response Structures . . . . . . . . 10
	7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11		7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 10
	7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14		7.2.2. Delete Operation Structure . . . . . . . . . . . . . 13
	7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17		7.2.3. Accept Operation Structure . . . . . . . . . . . . . 16
	7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20		7.2.4. Reject Operation Structure . . . . . . . . . . . . . 19
	7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23		7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 22
	7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26		7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 25
	7.2.7. Get SED Group Offers Operation Structure . . . . . . 27		7.2.7. Get SED Group Offers Operation Structure . . . . . . 26
	7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29		7.2.8. Generic Query Response . . . . . . . . . . . . . . . 28
	7.2.9. Get Server Details Operation Structure . . . . . . . 29		7.2.9. Get Server Details Operation Structure . . . . . . . 29
	7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31		7.3. Response Codes and Messages . . . . . . . . . . . . . . . 30
	7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33		7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 32
	8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33		8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 32
	9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33		9. SPPP over SOAP WSDL Definition . . . . . . . . . . . . . . . 32
	10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 45		10. SPPP over SOAP Examples . . . . . . . . . . . . . . . . . . . 44
	10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45		10.1. Add Destination Group . . . . . . . . . . . . . . . . . 44
	10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47		10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 46
	10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48		10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 47
	10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49		10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49
	10.5. Add Public Identifier -- Successful COR claim . . . . . 51		10.5. Add Public Identifier -- Successful COR Claim . . . . . 50
	10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53		10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 52
	10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54		10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 53
	10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55		10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 54
	10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57		10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 56
	10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 58		10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 58
	10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 59		10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 60
	10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 61		10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 61
	10.13. Get Destination Group . . . . . . . . . . . . . . . . . 62		10.13. Get Destination Group . . . . . . . . . . . . . . . . . 62
	10.14. Get Public Identifier . . . . . . . . . . . . . . . . . 64		10.14. Get Public Identifier . . . . . . . . . . . . . . . . . 64
	10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65		10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 66
	10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67		10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 68
	10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69		10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 70
	10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71		10.18. Delete Destination Group . . . . . . . . . . . . . . . . 72
	10.19. Delete Public Identifier . . . . . . . . . . . . . . . . 72		10.19. Delete Public Identifier . . . . . . . . . . . . . . . . 73
	10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73		10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 74
	10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74		10.21. Delete SED Group Offers Request . . . . . . . . . . . . 75
	10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 76		10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 76
	10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 77		10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 77
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 79		11. Security Considerations . . . . . . . . . . . . . . . . . . . 80
	11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80		11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81		13.1. Normative References . . . . . . . . . . . . . . . . . . 81
	14.1. Normative References . . . . . . . . . . . . . . . . . . 81		13.2. Informative References . . . . . . . . . . . . . . . . . 82
	14.2. Informative References . . . . . . . . . . . . . . . . . 82		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 82
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83
	1. Introduction		1. Introduction
	SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best		SPPF, defined in [RFC7877], is best supported by a transport and
	supported by a transport and messaging infrastructure that is		messaging infrastructure that is connection oriented, is request-
	connection oriented, request-response oriented, easily secured,		response oriented, is easily secured, supports propagation through
	supports propagation through firewalls in a standard fashion, and		firewalls in a standard fashion, and is easily integrated into back-
	that is easily integrated into back-office systems. This is due to		office systems. This is due to the fact that the client side of SPPF
	the fact that the client side of SPPF is likely to be integrated with		is likely to be integrated with organizations' operational support
	organizations' operational support systems that facilitate		systems that facilitate transactional provisioning of user addresses
	transactional provisioning of user addresses and their associated		and their associated SED. The server side of SPPF is likely to
	session establishment data. While the server side of SPPF is likely		reside in a separate organization's network, resulting in the SPPF
	to reside in a separate organization's network, resulting in the SPPF
	provisioning transactions traversing the Internet as they are		provisioning transactions traversing the Internet as they are
	propagated from the SPPF client to the SPPF server. Given the		propagated from the SPPF client to the SPPF server. Given the
	current state of industry practice and technologies, SOAP and HTTP(S)		current state of industry practice and technologies, SOAP and HTTP(S)
	are well suited for this type of environment. This document		are well suited for this type of environment. This document
	describes the specification for transporting SPPF XML structures,		describes the specification for transporting SPPF XML structures,
	using SOAP and HTTP(S) as substrates.		using SOAP and HTTP(S) as substrates.
	The specification in this document for transporting SPPF XML		The specification in this document for transporting SPPF XML
	structures over SOAP and HTTP(s) is primarily comprised of five		structures over SOAP and HTTP(S) is primarily comprised of five
	subjects: (1) a description of any applicable SOAP features, (2) any		subjects: (1) a description of any applicable SOAP features, (2) any
	applicable HTTP features, (3) security considerations, and perhaps		applicable HTTP features, (3) security considerations, (4) (perhaps
	most importantly, (4) the Web Services Description Language (WSDL)		most importantly) the Web Services Description Language (WSDL)
	definition for SPP Protocol over SOAP, and (5) "substrate" specific		definition for the SPP Protocol over SOAP, and (5) XML Schema
	XML Schema type definitions		Definition (XSD) types that are "substrate" specific.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. SOAP Features and Protocol Layering		3. SOAP Features and Protocol Layering
	The list of SOAP features that are explicitly used and required for		The list of SOAP features that are explicitly used and required for
	SPP Protocol over SOAP are limited. Most SOAP features are not		SPPP over SOAP are limited. Most SOAP features are not necessary for
	necessary for SPPF. SPP Protocol over SOAP primarily uses SOAP		SPPF. SPPP over SOAP primarily uses SOAP simply as a standard
	simply as a standard message envelope technology. The SOAP message		message-envelope technology. The SOAP message envelope is comprised
	envelope is comprised of the SOAP header and body. As described in		of the SOAP header and body. As described in the SOAP specification
	the SOAP specifications [SOAPREF], the SOAP header can contain		[SOAPREF], the SOAP header can contain optional, application-
	optional, application specific, information about the message. The		specific, information about the message. The SOAP body contains the
	SOAP body contains the SPPF message itself, whose structure is		SPPF message itself, whose structure is defined by the combination of
	defined by the combination of one of the WSDL operations defined in		one of the WSDL operations defined in this document and the SPPF XML
	this document and the SPPF XML data structures defined in this		data structures defined in this document and the SPPF document. SPPF
	document and the SPPF document. SPPF does not rely on any data		does not rely on any data elements in the SOAP header. All relevant
	elements in the SOAP header. All relevant data elements are defined		data elements are defined in the SPPF XML Schema described in
	in the SPPF XML schema described in		[RFC7877] and the SPPF WSDL types specification described in
	[I-D.draft-ietf-drinks-spp-framework] and the SPPF WSDL types		Section 9 of this document.
	specification described in this document and in
	[I-D.draft-ietf-drinks-spp-framework].
	WSDL is a widely standardized and adopted technology for defining the		WSDL is a widely standardized and adopted technology for defining the
	top-level structures of the messages that are transported within the		top-level structures of the messages that are transported within the
	body of a SOAP message. The WSDL definition for the SPPF SOAP		body of a SOAP message. The WSDL definition for the SPPF SOAP
	messages is defined later in this document, which imports by		messages is defined later in this document, which imports by
	reference the XML data types contained in the SPPF schema. The IANA		reference the XML data types contained in the SPPF schema. The IANA
	registry where the SPPF schema resides is described in the IETF XML		registry where the SPPF schema resides is described in "The IETF XML
	Registry [RFC3688].		Registry" [RFC3688].
	There are multiple structural styles that WSDL allows. The best		There are multiple structural styles that WSDL allows. The best
	practice for this type of application is what is sometimes referred		practice for this type of application is what is sometimes referred
	to as the "document/literal wrapped style". This style is generally		to as the "document/literal wrapped style". This style is generally
	regarded as an optimal approach that enhances maintainability,		regarded as an optimal approach that enhances maintainability,
	comprehension, portability, and, to a certain extent, performance.		comprehension, portability, and, to a certain extent, performance.
	It is characterized by setting the soapAction binding style as		It is characterized by setting the soapAction binding style as
	"document", the soapAction encoding style as "literal", and then		"document", the soapAction encoding style as "literal", and then
	defining the SOAP messages to simply contain a single data element		defining the SOAP messages to simply contain a single data element
	that "wraps" a data structure containing all the required input or		that "wraps" a data structure containing all the required input or
	output data elements. The figure below illustrates this high level		output data elements. The figure below illustrates this high-level
	technical structure as conceptual layers 3 through 6.		technical structure as conceptual layers 3 through 6.
	+-------------+		+-------------+
	(1) | Transport |Example:		(1) | Transport |Example:
	| Protocol | TCP, TLS, BEEP, etc.		| Protocol | TCP, TLS, BEEP, etc.
	+-------------+		+-------------+
	|		|
	V		V
	+-------------+		+-------------+
	(2) | Message |Example:		(2) | Message |Example:
	| Envelope | HTTP, SOAP, None, etc.		| Envelope | HTTP, SOAP, None, etc.
	+-------------+		+-------------+
	|		|
	V		V
	+--------------+		+--------------+
	+----| SOAP |---+		+----| SOAP |---+
	|(3) | Operation | |		|(3) | Operation | |
	Contains | +--------------+ | Contains		Contains | +--------------+ | Contains
	| Example: |		| Example: |
	V submitAddRqst V		V submitAddRqst V
	+--------------+ +-------------+		+--------------+ +-------------+
	|SOAP Request | |SOAP Response|		| SOAP Request | |SOAP Response|
	Example: | Message | (4) | Message | Example:		Example: | Message | (4) | Message | Example:
	spppAdd | (Operation | | (Operation | spppAdd		spppAdd | (Operation | | (Operation | spppAdd
	RequestMsg | Input) | | Output) | ResponseMsg		RequestMsg | Input) | | Output) | ResponseMsg
	+--------------+ +-------------+		+--------------+ +-------------+
	| |		| |
	Contains | | Contains		Contains | | Contains
	| |		| |
	V V		V V
	+---------------+ +---------------+		+--------------+ +---------------+
	Example: | Wrapped | (5) | Wrapped | Example:		Example: | Wrapped | (5) | Wrapped | Example:
	spppAdd |Request Object | |Response Object| spppAdd		spppAdd |Request Object| |Response Object| spppAdd
	Request +---------------+ +---------------+ Response		Request +--------------+ +---------------+ Response
	| |		| |
	Contains | | Contains		Contains | | Contains
	| |		| |
	V V		V V
	+-------------+ +---------------+		+--------------+ +---------------+
	| SPPF | | SPPF |		| SPPF | | SPPF |
	|XML Types | (6) | XML Types |		| XML Types | (6) | XML Types |
	+-------------+ +---------------+		+--------------+ +---------------+
	Figure 1: Layering and Technical Structure of the SPP Protocol over		Legend:
	SOAP Messages		BEEP = Blocks Extensible Exchange Protocol
			TLS = Transport Layer Security
	The operations supported by SPP Protocol over SOAP are normatively		Figure 1: Layering and Technical Structure of SPPP over SOAP Messages
	defined later in this document. Each SOAP operation defines a		The operations supported by SPPP over SOAP are normatively defined
	request/input message and a response/output message. Each such		later in this document. Each SOAP operation defines a request/input
	request and response message then contains a single object that wraps		message and a response/output message. Each such request and
	the SPPF XML data types that comprise the inputs and the outputs,		response message then contains a single object that wraps the SPPF
			XML data types that comprise the inputs and the outputs,
	respectively, of the SOAP operation.		respectively, of the SOAP operation.
	SOAP faults are not used by the SPP Protocol over SOAP. All success		SOAP faults are not used by the SPPP over SOAP. All success and
	and error responses are specified in Section 7.3 of this document.		error responses are specified in Section 7.3 of this document.
	However, if a SOAP fault were to occur, perhaps due to failures in		However, if a SOAP fault were to occur, perhaps due to failures in
	the SOAP message handling layer of a SOAP library, the client		the SOAP message handling layer of a SOAP library, the client
	application should capture and handle the fault. Specifics on how to		application should capture and handle the fault. Specifics on how to
	handle such SOAP faults, if they should occur, will be specific to		handle such SOAP faults, if they should occur, will be specific to
	the chosen SOAP implementation.		the chosen SOAP implementation.
	Implementations MUST use SOAP 1.2 [SOAPREF] or higher, and MUST		Implementations MUST use SOAP 1.2 [SOAPREF] or higher and MUST
	support SOAP 1.2. Implementations SHOULD use WSDL 1.1 [WSDLREF], and		support SOAP 1.2. Implementations SHOULD use WSDL 1.1 [WSDLREF] and
	MUST NOT use earlier versions. Use of WSDL versions greater than 1.1		MUST NOT use earlier versions. Use of WSDL versions greater than 1.1
	may introduce interopability problems with implementations that use		may introduce interoperability problems with implementations that use
	1.1.		1.1.
	SPPF is a request/reply framework that allows a client application to		SPPF is a request/reply framework that allows a client application to
	submit provisioning data and query requests to a server. The SPPF		submit provisioning data and query requests to a server. The SPPF
	data structures are designed to be protocol agnostic. Concerns		data structures are designed to be protocol agnostic. Concerns
	regarding encryption, non-repudiation, and authentication are beyond		regarding encryption, non-repudiation, and authentication are beyond
	the scope of this document. For more details, please refer to		the scope of this document. For more details, please refer to
	Section 4 ("Substrate Protocol Requirements") of		Section 4 ("Transport Substrate Protocol Requirements") of [RFC7877].
	[I-D.draft-ietf-drinks-spp-framework].
	As illustrated in the previous diagram, SPPF can be viewed as a set		As illustrated in the previous diagram, SPPF can be viewed as a set
	of layers that collectively define the structure of an SPPF request		of layers that collectively define the structure of an SPPF request
	and response. Layers 1 and 2 represent the transport, envelope, and		and response. Layers 1 and 2 represent the transport, envelope, and
	authentication technologies. This document defines layers 3, 4, 5,		authentication technologies. This document defines layers 3, 4, 5,
	and 6 for SPP Protocol over SOAP.		and 6 for SPPP over SOAP.
	1. Layer 1: The transport protocol layer represents the		1. Layer 1: The transport protocol layer represents the
	communication mechanism between the client and server. SPPF can		communication mechanism between the client and server. SPPF can
	be layered over any substrate protocol that provides a set of		be layered over any substrate protocol that provides a set of
	basic requirements defined in Section 4 of		basic requirements defined in Section 4 of [RFC7877].
	[I-D.draft-ietf-drinks-spp-framework].
	2. Layer 2: The message envelope layer is optional, but can provide		2. Layer 2: The message-envelope layer is optional but can provide
	features that are above the transport technology layer but below		features that are above the transport technology layer but below
	the application messaging layer. Technologies such as HTTP and		the application messaging layer. Technologies such as HTTP and
	SOAP are examples of messaging envelope technologies.		SOAP are examples of message-envelope technologies.
	3. Layers 3,4,5,6: The operation and message layers provide an		3. Layers 3, 4, 5, and 6: The operation and message layers provide
	envelope-independent and substrate-independent wrapper for the		an envelope-independent and substrate-independent wrapper for the
	SPPF data model objects that are being acted on (created,		SPPF data model objects that are being acted on (created,
	modified, queried).		modified, and queried).
	4. HTTP(s) Features and SPP Protocol over SOAP		4. HTTP(S) Features and SPPP over SOAP
	While SOAP is not tied to HTTP(S), for reasons described in the		While SOAP is not tied to HTTP(S), for reasons described in the
	introduction, HTTP(S) is a good choice as the substrate protocol for		Introduction, HTTP(S) is a good choice as the substrate protocol for
	the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent		the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent
	connection" feature, which allows multiple HTTP request/response		connection" feature, which allows multiple HTTP request/response
	pairs to be transported across a single HTTP connection. This is an		pairs to be transported across a single HTTP connection. This is an
	important performance optimization feature, particularly when the		important performance optimization feature, particularly when the
	connections is an HTTPS connection where the relatively time		connection is an HTTPS connection where the relatively time-consuming
	consuming TLS handshake has occurred.		TLS handshake has occurred.
	Implementations compliant with this document MUST use HTTP 1.1		Implementations compliant with this document MUST use HTTP 1.1
	[RFC7230] or higher. Also, implementations SHOULD use persistent		[RFC7230] or higher. Also, implementations SHOULD use persistent
	connections.		connections.
	5. Authentication, Integrity and Confidentiality		5. Authentication, Integrity, and Confidentiality
	To accomplish authentication, conforming SPP Protocol over SOAP		To accomplish authentication, conforming SPPP over SOAP clients and
	Clients and Servers MUST use HTTP Digest Authentication as defined in		servers MUST use HTTP Digest Authentication as defined in [RFC7235].
	[RFC2617].
	To achieve integrity and privacy, conforming SPP Protocol over SOAP		To achieve integrity and privacy, conforming SPPP over SOAP clients
	Clients and Servers MUST support Transport Layer Security (TLS) as		and servers MUST support TLS as defined in [RFC5246] as the secure
	defined in [RFC5246] as the secure transport mechanism. Use of TLS		transport mechanism. Use of TLS MUST follow the recommendations
	MUST follow the recommendations contained in [RFC7525]		contained in [RFC7525]
	6. Language Identification		6. Language Identification
	Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols		Section 9 of [RFC7877] requires protocols to provide a mechanism to
	to provide a mechanism to transmit language tags together with human-		transmit language tags together with human-readable messages. When
	readable messages. When conforming SPP Protocol SOAP servers use		conforming SPPP SOAP servers use such tagging, the XML "lang"
	such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126],		attribute ([W3C.REC-xml-20081126], Section 2.12) MUST be used.
	Section 2.12) MUST be used. Clients MAY use the HTTP "Accept-		Clients MAY use the HTTP "Accept-Language" header field (see
	Language" header field (see Section 5.3.5 of [RFC7231]) in order to		Section 5.3.5 of [RFC7231]) in order to indicate their language
	indicate their language preference.		preference.
	7. SPP Protocol SOAP Data Structures		7. SPPP SOAP Data Structures
	SPP Protocol over SOAP uses a set of XML based data structures for		SPPP over SOAP uses a set of XML-based data structures for all the
	all the supported operations and any parameters that those operations		supported operations and any parameters to which those operations are
	are applied to. As also mentioned earlier in this document, these		applied. As also mentioned earlier in this document, these XML
	XML structures are envelope-independent and substrate-independent.		structures are envelope independent and substrate independent. Refer
	Refer the "Protocol Operations" (Section 8) of this document for a		to "Protocol Operations" (Section 8) of this document for a
	description of all the operations that MUST be supported.		description of all the operations that MUST be supported.
	The following sections describe the definition all the XML data		The following sections describe the definitions of all the XML data
	structures.		structures.
	7.1. Concrete Object Key Types		7.1. Concrete Object Key Types
	Certain operations in SPPF require an object key that uniquely		Certain operations in SPPF require an object key that uniquely
	identifies the object(s) on which a given operation needs to be		identifies the object(s) on which a given operation needs to be
	performed. SPPF defines the XML structure of the any such object key		performed. SPPF defines the XML structure of any such object key in
	in an abstract manner and delegates the concrete representation to		an abstract manner and delegates the concrete representation to any
	any conforming substrate protocol. The following sub-sections define		conforming substrate protocol. The following subsections define the
	the various types of concrete object key types used in various		various types of concrete object key types used in various operations
	operations in SPP Protocol over SOAP.		in SPPP over SOAP.
	7.1.1. Generic Object Key		7.1.1. Generic Object Key
	Most objects in SPP Protocol over SOAP are uniquely identified by the		Most objects in SPPP over SOAP are uniquely identified by the
	attributes in the generic object key (Refer Section 5.2.1 "Generic		attributes in the generic object key (Refer to "Generic Object Key
	Object Key Type" of [I-D.draft-ietf-drinks-spp-framework] for		Type", Section 5.2.1 of [RFC7877], for details). The concrete XML
	details). The concrete XML representation of ObjKeyType is as below:		representation of ObjKeyType is as below:
	<complexType name="ObjKeyType">		<complexType name="ObjKeyType">
	<complexContent>		<complexContent>
	<extension base="sppfb:ObjKeyType">		<extension base="sppfb:ObjKeyType">
	<sequence>		<sequence>
	<element name="rant" type="sppfb:OrgIdType"/>		<element name="rant" type="sppfb:OrgIdType"/>
	<element name="name" type="sppfb:ObjNameType"/>		<element name="name" type="sppfb:ObjNameType"/>
	<element name="type" type="sppfs:ObjKeyTypeEnum"/>		<element name="type" type="sppfs:ObjKeyTypeEnum"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	The ObjKeyType has the data elements as described below:		The ObjKeyType has the data elements as described below:
	o rant: The identifier of the registrant organization that owns the		o rant: The identifier of the Registrant organization that owns the
	object.		object.
	o name: The character string that contains the name of the object.		o name: The character string that contains the name of the object.
	o type: The enumeration value that represents the type of SPPF		o type: The enumeration value that represents the type of SPPF
	object. For example, both a Destination Group and a SED Group can		object. For example, both a Destination Group and a SED Group can
	have the same name "TestObj" and be associated with same		have the same name "TestObj" and be associated with the same
	Registrant Id. Hence, to uniquely identify the object that		Registrant ID. Hence, to uniquely identify the object that
	represents a Destination Group with the name "TestObj", the type		represents a Destination Group with the name "TestObj", the type
	"DestGrp" must be specified when using this concrete ObjKeyType		"DestGrp" must be specified when using this concrete ObjKeyType
	structure to identify the Destination Group "TestObj".		structure to identify the Destination Group "TestObj".
	The object types in SPP Protocol over SOAP MUST adhere to the above		The object types in SPPP over SOAP MUST adhere to the above
	definition of generic object key, and are defined as an enumeration		definition of generic object key and are defined as an enumeration in
	in the XML data structure as follows:		the XML data structure as follows:
	<simpleType name="ObjKeyTypeEnum">		<simpleType name="ObjKeyTypeEnum">
	<restriction base="token">		<restriction base="token">
	<enumeration value="SedGrp"/>		<enumeration value="SedGrp"/>
	<enumeration value="DestGrp"/>		<enumeration value="DestGrp"/>
	<enumeration value="SedRec"/>		<enumeration value="SedRec"/>
	<enumeration value="EgrRte"/>		<enumeration value="EgrRte"/>
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	7.1.2. Public Identifier Object Key		7.1.2. Public Identifier Object Key
	Public Identifier type objects can further be of various sub-types		Public Identifier type objects can further be of various sub-types
	like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or		like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or
	a TN Range and cannot be cleanly identified with the attributes in		TN Range and cannot be cleanly identified with the attributes in the
	the generic ObjKeyType. The definition of PubIdKeyType is as below:		generic ObjKeyType. The definition of PubIdKeyType is as below:
	<complexType name="PubIdKeyType">		<complexType name="PubIdKeyType">
	<complexContent>		<complexContent>
	<extension base="sppfb:PubIdKeyType">		<extension base="sppfb:PubIdKeyType">
	<sequence>		<sequence>
	<element name="rant" type="sppfb:OrgIdType"/>		<element name="rant" type="sppfb:OrgIdType"/>
	<choice>		<choice>
	<element name="number"		<element name="number"
	type="sppfb:NumberType"/>		type="sppfb:NumberType"/>
	<element name="range"		<element name="range"
	skipping to change at page 10, line 5 ¶		skipping to change at page 9, line 45 ¶
	<element name="uri"		<element name="uri"
	type="anyURI"/>		type="anyURI"/>
	</choice>		</choice>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	The PubIdKeyType has data elements, as described below:		The PubIdKeyType has data elements, as described below:
	o rant: The identifier of the registrant organization that owns the		o rant: The identifier of the Registrant organization that owns the
	object.		object.
	o number: An element of type NumberType (refer Section 12 of		o number: An element of type NumberType (refer to Section 12 of
	[I-D.draft-ietf-drinks-spp-framework]) that contains the value and		[RFC7877]) that contains the value and type of a number.
	type of a number .
	o range: An element of type NumberRangeType (refer Section 12 of		o range: An element of type NumberRangeType (refer to Section 12 of
	[I-D.draft-ietf-drinks-spp-framework]) that contains a range of		[RFC7877]) that contains a range of numbers.
	numbers.
	o uri: A value that represents a Public Identifier.		o uri: A value that represents a Public Identifier.
	Any instance of PubIdKeyType MUST contain exactly one element from		Any instance of PubIdKeyType MUST contain exactly one element from
	the following set of elements: "number", "range", "uri".		the following set of elements: "number", "range", "uri".
	7.1.3. SED Group Offer Key		7.1.3. SED Group Offer Key
	In addition to the attributes in the generic ObjKeyType, a SED Group		In addition to the attributes in the generic ObjKeyType, a SED Group
	Offer object is uniquely identified by the organization ID of the		Offer object is uniquely identified by the organization ID of the
	organization to whom an SED Group has been offered. The definition		organization to whom a SED Group has been offered. The definition of
	of SedGrpOfferKeyType is as below:		SedGrpOfferKeyType is as below:
	<complexType name="SedGrpOfferKeyType">		<complexType name="SedGrpOfferKeyType">
	<complexContent>		<complexContent>
	<extension base="sppfb:SedGrpOfferKeyType">		<extension base="sppfb:SedGrpOfferKeyType">
	<sequence>		<sequence>
	<element name="sedGrpKey" type="sppfs:ObjKeyType"/>		<element name="sedGrpKey" type="sppfs:ObjKeyType"/>
	<element name="offeredTo" type="sppfb:OrgIdType"/>		<element name="offeredTo" type="sppfb:OrgIdType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	skipping to change at page 11, line 8 ¶		skipping to change at page 10, line 38 ¶
	The SedGrpOfferKeyType has the data elements as described below:		The SedGrpOfferKeyType has the data elements as described below:
	o sedGrpKey: Identifies the SED Group that was offered.		o sedGrpKey: Identifies the SED Group that was offered.
	o offeredTo: The organization ID of the organization that was		o offeredTo: The organization ID of the organization that was
	offered the SED Group object identified by the sedGrpKey.		offered the SED Group object identified by the sedGrpKey.
	7.2. Operation Request and Response Structures		7.2. Operation Request and Response Structures
	An SPPF client interacts with an SPPF server by sending one or more		An SPPF client interacts with an SPPF server by sending one or more
	requests to the server, and by receiving corresponding responses from		requests to the server and by receiving corresponding responses from
	the server. The basic set of operations that an SPPF client can		the server. The basic set of operations that an SPPF client can
	submit to an SPPF server and the semantics of those operations are		submit to an SPPF server and the semantics of those operations are
	defined in Section 7 ("Framework Operations") of		defined in "Framework Operations", Section 7 of [RFC7877]. The
	[I-D.draft-ietf-drinks-spp-framework]. The following sub-sections		following subsections describe the XML data structures that are used
	describe the XML data structures that are used for each of those		for each of those types of operations for an SPPP over SOAP
	types of operations for a SPP Protocol over SOAP implementation.		implementation.
	7.2.1. Add Operation Structure		7.2.1. Add Operation Structure
	In order to add (or modify) an object in the registry, an authorized		In order to add (or modify) an object in the Registry, an authorized
	entity can send the spppAddRequest to the registry.		entity can send the spppAddRequest to the Registry.
	An SPP Protocol over SOAP Add request is wrapped within the		An SPPP over SOAP Add request is wrapped within the <spppAddRequest>
	<spppAddRequest> element while an SPP Protocol over SOAP Add response		element while an SPPP over SOAP Add response is wrapped within an
	is wrapped within an <spppAddResponse> element. The following sub-		<spppAddResponse> element. The following sub-sections describe the
	sections describe the spppAddRequest and spppAddResponse elements.		<spppAddRequest> and <spppAddResponse> elements. Refer to Section 10
	Refer to Section 10 for an example of Add operation on each type of		for an example of an Add operation on each type of SPPF object.
	SPPF object.
	7.2.1.1. Add Request		7.2.1.1. Add Request
	An SPP Protocol over SOAP Add request definition is contained within		An SPPP over SOAP Add request definition is contained within the
	the generic <spppAddRequest> element.		generic <spppAddRequest> element.
	<element name="spppAddRequest">		<element name="spppAddRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId"		<element name="clientTransId"
	type="sppfb:TransIdType" minOccurs="0"/>		type="sppfb:TransIdType" minOccurs="0"/>
	<element name="minorVer"		<element name="minorVer"
	type="sppfb:MinorVerType" minOccurs="0"/>		type="sppfb:MinorVerType" minOccurs="0"/>
	<element name="obj" type="sppfb:BasicObjType"		<element name="obj" type="sppfb:BasicObjType"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <spppAddRequest> element are described		The data elements within the <spppAddRequest> element are described
	as follows:		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 SPPF client, identifies this request.		within the context of the SPPF client, identifies this request.
	This value can be used at the discretion of the SPPF client to		This value can be used at the discretion of the SPPF client to
	track, log or correlate requests and their responses. SPPF server		track, log, or correlate requests and their responses. The SPPF
	MUST echo back this value to the client in the corresponding		server MUST echo back this value to the client in the
	response to the incoming request. SPPF server will not check this		corresponding response to the incoming request. The SPPF server
	value for uniqueness.		will not check this value for uniqueness.
	o minorVer: Zero or one minor version identifier, as defined in		o minorVer: Zero or one minor version identifier, as defined in
	Section 7.4.		Section 7.4.
	o obj: One or more elements of abstract type BasicObjType (defined		o obj: One or more elements of abstract type BasicObjType (defined
	in [I-D.draft-ietf-drinks-spp-framework]). Each element contains		in [RFC7877]). Each element contains all the attributes of an
	all the attributes of an SPPF object that that the client is		SPPF object that the client is requesting the SPPF server to add.
	requesting the SPPF server to add. Refer to section 3.1 of		Refer to Section 3.1 of [RFC7877] for the XML structure of all
	[I-D.draft-ietf-drinks-spp-framework] for the XML structure of all
	concrete types, for various SPPF objects, that extend from		concrete types, for various SPPF objects, that extend from
	abstract BasicObjType and hence are eligible to be passed into		abstract BasicObjType and hence are eligible to be passed into
	this element. The elements are processed by the SPPF server in		this element. The elements are processed by the SPPF server in
	the order in which they are included in the request. With respect		the order in which they are included in the request. With respect
	to handling of error conditions, conforming SPPP SOAP servers MUST		to the handling of error conditions, conforming SPPP SOAP servers
	stop processing BasicObjType elements in the request at the first		MUST stop processing BasicObjType elements in the request at the
	error, and roll back any BasicObjType elements that had already		first error and roll back any BasicObjType elements that had
	been processed for that add request ("stop and rollback").		already been processed for that add request ("stop and roll
			back").
	7.2.1.2. Add Response		7.2.1.2. Add Response
	An SPP Protocol over SOAP add response object is contained within the		An SPPP over SOAP add response object is contained within the generic
	generic <spppAddResponse> element. This response structure is used		<spppAddResponse> element. This response structure is used for all
	for all types of SPPF objects that are provisioned by the SPPF		types of SPPF objects that are provisioned by the SPPF client.
	client.
	<element name="spppAddResponse">		<element name="spppAddResponse">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId" type="sppfb:TransIdType"		<element name="clientTransId" type="sppfb:TransIdType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="serverTransId" type="sppfb:TransIdType"/>		<element name="serverTransId" type="sppfb:TransIdType"/>
	<element name="overallResult" type="sppfs:ResultCodeType"/>		<element name="overallResult" type="sppfs:ResultCodeType"/>
	<element name="detailResult" type="sppfs:ObjResultCodeType"		<element name="detailResult" type="sppfs:ObjResultCodeType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	skipping to change at page 13, line 37 ¶		skipping to change at page 12, line 46 ¶
	<extension base="sppfs:ResultCodeType">		<extension base="sppfs:ResultCodeType">
	<sequence>		<sequence>
	<element name="obj" type="sppfb:BasicObjType"/>		<element name="obj" type="sppfb:BasicObjType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	An <spppAddResponse> contains the elements necessary for the SPPF		An <spppAddResponse> contains the elements necessary for the SPPF
	client to precisely determine the overall 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 occurs, it provides information about the specific
	object(s) that caused the error.		object(s) that caused the error.
	The data elements within the SPP Protocol over SOAP Add response are		The data elements within the SPPP over SOAP Add response are
	described as follows:		described as 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 SPPF client		simply an echo of the client transaction ID that the SPPF client
	passed into the SPPF update request. When included in the		passed into the SPPF update request. When included in the
	request, the SPPF server MUST return it in the corresponding		request, the SPPF server MUST return it in the corresponding
	response message.		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 MUST be unique for		this request for tracking purposes. This value MUST be unique for
	a given SPPF server.		a given SPPF 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 Section 7.3		explicitly identifies the result of the request. See Section 7.3
	for further details.		for further details.
	o detailResult: An optional response code, response message, and		o detailResult: An optional response code, response message, and
	BasicObjType (as defined in [I-D.draft-ietf-drinks-spp-framework])		BasicObjType (as defined in [RFC7877]) triplet. This element will
	triplet. This element will be present only if an object level		be present only if an object-level error has occurred. It
	error has occurred. It indicates the error condition and the		indicates the error condition and the exact request object that
	exact request object that contributed to the error. The response		contributed to the error. The response code will reflect the
	code will reflect the exact error. See Section 7.3 for further		exact error. See Section 7.3 for further details.
	details.
	7.2.2. Delete Operation Structure		7.2.2. Delete Operation Structure
	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 spppDelRequest into the registry. An SPP Protocol over		can send the spppDelRequest into the Registry. An SPPP over SOAP
	SOAP Delete request is wrapped within the <spppDelRequest> element		Delete request is wrapped within the <spppDelRequest> element while
	while a SPP Protocol over SOAP Delete response is wrapped within the		an SPPP over SOAP Delete response is wrapped within the generic
	generic <spppDelResponse> element. The following sub-sections		<spppDelResponse> element. The following subsections describe the
	describe the spppDelRequest and spppDelResponse elements. Refer to		<spppDelRequest> and <spppDelResponse> elements. Refer to Section 10
	Section 10 for an example of Delete operation on each type of SPPF		for an example of the Delete operation on each type of SPPF object.
	object.
	7.2.2.1. Delete Request		7.2.2.1. Delete Request
	An SPP Protocol over SOAP Delete request definition is contained		An SPPP over SOAP Delete request definition is contained within the
	within the generic <spppDelRequest> element.		generic <spppDelRequest> element.
	<element name="spppDelRequest">		<element name="spppDelRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId"		<element name="clientTransId"
	type="sppfb:TransIdType" minOccurs="0"/>		type="sppfb:TransIdType" minOccurs="0"/>
	<element name="minorVer"		<element name="minorVer"
	type="sppfb:MinorVerType" minOccurs="0"/>		type="sppfb:MinorVerType" minOccurs="0"/>
	<element name="objKey" type="sppfb:ObjKeyType"		<element name="objKey" type="sppfb:ObjKeyType"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <spppDelRequest> element are described		The data elements within the <spppDelRequest> element are described
	as follows:		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 SPPF client, identifies this request.		within the context of the SPPF client, identifies this request.
	This value can be used at the discretion of the SPPF client to		This value can be used at the discretion of the SPPF client to
	track, log or correlate requests and their responses. SPPF server		track, log, or correlate requests and their responses. The SPPF
	MUST echo back this value to the client in the corresponding		server MUST echo back this value to the client in the
	response to the incoming request. SPPF server will not check this		corresponding response to the incoming request. SPPF server will
	value for uniqueness.		not check this value for uniqueness.
	o minorVer: Zero or one minor version identifier, as defined in		o minorVer: Zero or one minor version identifier, as defined in
	Section 7.4.		Section 7.4.
	o objKey: One or more elements of abstract type ObjKeyType (as		o objKey: One or more elements of abstract type ObjKeyType (as
	defined in [I-D.draft-ietf-drinks-spp-framework]). Each element		defined in [RFC7877]). Each element contains attributes that
	contains attributes that uniquely identify the object that the		uniquely identify the object that the client is requesting the
	client is requesting the server to delete. Refer to Section 7.1		server to delete. Refer to Section 7.1 for a description of all
	for a description of all concrete object key types, for various		concrete object key types, for various SPPF objects, which are
	SPPF objects, which are eligible to be passed into this element.		eligible to be passed into this element. The elements are
	The elements are processed by the SPPF server in the order in		processed by the SPPF server in the order in which they are
	which they are included in the request. With respect to handling		included in the request. With respect to the handling of error
	of error conditions, conforming SPPP SOAP servers MUST stop		conditions, conforming SPPP SOAP servers MUST stop processing
	processing ObjKeyType elements in the request at the first error,		ObjKeyType elements in the request at the first error and roll
	and roll back any ObjKeyType elements that had already been		back any ObjKeyType elements that had already been processed for
	processed for that delete request ("stop and rollback").		that Delete request ("stop and roll back").
	7.2.2.2. Delete Response		7.2.2.2. Delete Response
	An SPP Protocol over SOAP delete response object is contained within		An SPPP over SOAP delete response object is contained within the
	the generic <sppDeleteResponse> element. This response structure is		generic <sppDeleteResponse> element. This response structure is used
	used for a delete request on all types of SPPF objects that are		for a Delete request on all types of SPPF objects that are
	provisioned by the SPPF client.		provisioned by the SPPF client.
	<element name="spppDelResponse">		<element name="spppDelResponse">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId" type="sppfb:TransIdType"		<element name="clientTransId" type="sppfb:TransIdType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="serverTransId" type="sppfb:TransIdType"/>		<element name="serverTransId" type="sppfb:TransIdType"/>
	<element name="overallResult" type="sppfs:ResultCodeType"/>		<element name="overallResult" type="sppfs:ResultCodeType"/>
	<element name="detailResult" type="sppfs:ObjKeyResultCodeType"		<element name="detailResult" type="sppfs:ObjKeyResultCodeType"
	skipping to change at page 16, line 37 ¶		skipping to change at page 15, line 44 ¶
	<extension base="sppfs:ResultCodeType">		<extension base="sppfs:ResultCodeType">
	<sequence>		<sequence>
	<element name="objKey" type="sppfb:ObjKeyType"/>		<element name="objKey" type="sppfb:ObjKeyType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	An <spppDelResponse> contains the elements necessary for the SPPF		An <spppDelResponse> contains the elements necessary for the SPPF
	client to precisely determine the overall 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 occurs, it provides information about the specific object
	object key(s) that caused the error.		key(s) that caused the error.
	The data elements within the SPP Protocol over SOAP Delete response		The data elements within the SPPP over SOAP Delete response are
	are described as follows:		described as 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 SPPF client		simply an echo of the client transaction ID that the SPPF client
	passed into the SPPF update request. When included in the		passed into the SPPF update request. When included in the
	request, the SPPF server MUST return it in the corresponding		request, the SPPF server MUST return it in the corresponding
	response message.		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 MUST be unique for		this request for tracking purposes. This value MUST be unique for
	a given SPPF server.		a given SPPF 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 Section 7.3		explicitly identifies the result of the request. See Section 7.3
	for further details.		for further details.
	o detailResult: An optional response code, response message, and		o detailResult: An optional response code, response message, and
	ObjKeyType (as defined in [I-D.draft-ietf-drinks-spp-framework])		ObjKeyType (as defined in [RFC7877]) triplet. This element will
	triplet. This element will be present only if an specific object		be present only if a specific object key level error has occurred.
	key level error has occurred. It indicates the error condition		It indicates the error condition and the exact request object key
	and the exact request object key that contributed to the error.		that contributed to the error. The response code will reflect the
	The response code will reflect the exact error. See Section 7.3		exact error. See Section 7.3 for further details.
	for further details.
	7.2.3. Accept Operation Structure		7.2.3. Accept Operation Structure
	In SPPF, a SED Group Offer can be accepted or rejected by, or on		In SPPF, a SED Group Offer can be accepted or rejected by, or on
	behalf of, the registrant to whom the SED Group has been offered		behalf of, the Registrant to whom the SED Group has been offered
	(refer Section 3.1 of [I-D.draft-ietf-drinks-spp-framework] for a		(refer to Section 3.1 of [RFC7877] for a description of the SED Group
	description of the SED Group Offer object). The Accept operation is		Offer object). The Accept operation is used to accept such SED Group
	used to accept such SED Group Offers by, or on behalf of, the		Offers by, or on behalf of, the Registrant. The request structure
	Registrant. The request structure for an SPP Protocol over SOAP		for an SPPP over SOAP Accept operation is wrapped within the
	Accept operation is wrapped within the <spppAcceptRequest> element		<spppAcceptRequest> element while an SPPP over SOAP Accept response
	while an SPP Protocol over SOAP Accept response is wrapped within the		is wrapped within the generic <spppAcceptResponse> element. The
	generic <spppAcceptResponse> element. The following sub-sections		following subsections describe the <spppAcceptRequest> and
	describe the spppAcceptRequest and spppAcceptResponse elements.		<spppAcceptResponse> elements. Refer to Section 10 for an example of
	Refer to Section 10 for an example of Accept operation on a SED Group		the Accept operation on a SED Group Offer.
	Offer.
	7.2.3.1. Accept Request Structure		7.2.3.1. Accept Request Structure
	An SPP Protocol over SOAP Accept request definition is contained		An SPPP over SOAP Accept request definition is contained within the
	within the generic <sppAcceptRequest> element.		generic <sppAcceptRequest> element.
	<element name="spppAcceptRequest">		<element name="spppAcceptRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId"		<element name="clientTransId"
	type="sppfb:TransIdType" minOccurs="0"/>		type="sppfb:TransIdType" minOccurs="0"/>
	<element name="minorVer"		<element name="minorVer"
	type="sppfb:MinorVerType" minOccurs="0"/>		type="sppfb:MinorVerType" minOccurs="0"/>
	<element name="sedGrpOfferKey"		<element name="sedGrpOfferKey"
	type="sppfs:SedGrpOfferKeyType"		type="sppfs:SedGrpOfferKeyType"
	skipping to change at page 18, line 25 ¶		skipping to change at page 17, line 30 ¶
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <spppAcceptRequest> element are		The data elements within the <spppAcceptRequest> 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 SPPF client, identifies this request.		within the context of the SPPF client, identifies this request.
	This value can be used at the discretion of the SPPF client to		This value can be used at the discretion of the SPPF client to
	track, log or correlate requests and their responses. SPPF server		track, log, or correlate requests and their responses. The SPPF
	MUST echo back this value to the client in the corresponding		server MUST echo back this value to the client in the
	response to the incoming request. SPPF server will not check this		corresponding response to the incoming request. The SPPF server
	value for uniqueness.		will not check this value for uniqueness.
	o minorVer: Zero or one minor version identifier, as defined in		o minorVer: Zero or one minor version identifier, as defined in
	Section 7.4.		Section 7.4.
	o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType		o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType
	(as defined in this document). Each element contains attributes		(as defined in this document). Each element contains attributes
	that uniquely identify a SED Group Offer that the client is		that uniquely identify a SED Group Offer that the client is
	requesting the server to accept. The elements are processed by		requesting the server to accept. The elements are processed by
	the SPPF server in the order in which they are included in the		the SPPF server in the order in which they are included in the
	request. With respect to handling of error conditions, conforming		request. With respect to the handling of error conditions,
	SPPP SOAP servers MUST stop processing SedGrpOfferKeyType elements		conforming SPPP SOAP servers MUST stop processing
	in the request at the first error, and roll back any		SedGrpOfferKeyType elements in the request at the first error and
	SedGrpOfferKeyType elements that had already been processed for		roll back any SedGrpOfferKeyType elements that had already been
	that accept request ("stop and rollback").		processed for that Accept request ("stop and roll back").
	7.2.3.2. Accept Response		7.2.3.2. Accept Response
	An SPP Protocol over SOAP accept response structure is contained		An SPPP over SOAP accept response structure is contained within the
	within the generic <sppAcceptResponse> element. This response		generic <sppAcceptResponse> element. This response structure is used
	structure is used for an Accept request on a SED Group Offer.		for an Accept request on a SED Group Offer.
	<element name="spppAcceptResponse">		<element name="spppAcceptResponse">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId" type="sppfb:TransIdType"		<element name="clientTransId" type="sppfb:TransIdType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="serverTransId" type="sppfb:TransIdType"/>		<element name="serverTransId" type="sppfb:TransIdType"/>
	<element name="overallResult" type="sppfs:ResultCodeType"/>		<element name="overallResult" type="sppfs:ResultCodeType"/>
	<element name="detailResult"		<element name="detailResult"
	type="sppfs:SedGrpOfferKeyResultCodeType"		type="sppfs:SedGrpOfferKeyResultCodeType"
	skipping to change at page 19, line 38 ¶		skipping to change at page 18, line 44 ¶
	<extension base="sppfs:ResultCodeType">		<extension base="sppfs:ResultCodeType">
	<sequence>		<sequence>
	<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>		<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	An <spppAcceptResponse> contains the elements necessary for the SPPF		An <spppAcceptResponse> contains the elements necessary for the SPPF
	client to precisely determine the overall 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 SED		if an error occurs, it provides information about the specific SED
	Group Offer key(s) that caused the error.		Group Offer key(s) that caused the error.
	The data elements within the SPP Protocol over SOAP Accept response		The data elements within the SPPP over SOAP Accept response are
	are described as follows:		described as 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 SPPF client		simply an echo of the client transaction ID that the SPPF client
	passed into the SPPF update request. When included in the		passed into the SPPF update request. When included in the
	request, the SPPF server MUST return it in the corresponding		request, the SPPF server MUST return it in the corresponding
	response message.		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 MUST be unique for		this request for tracking purposes. This value MUST be unique for
	a given SPPF server.		a given SPPF 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 Section 7.3		explicitly identifies the result of the request. See Section 7.3
	skipping to change at page 20, line 23 ¶		skipping to change at page 19, line 32 ¶
	o detailResult: An optional response code, response message, and		o detailResult: An optional response code, response message, and
	SedGrpOfferKeyType (as defined in this document) triplet. This		SedGrpOfferKeyType (as defined in this document) triplet. This
	element will be present only if any specific SED Group Offer key		element will be present only if any specific SED Group Offer key
	level error has occurred. It indicates the error condition and		level error has occurred. It indicates the error condition and
	the exact request SED Group Offer key that contributed to the		the exact request SED Group Offer key that contributed to the
	error. The response code will reflect the exact error. See		error. The response code will reflect the exact error. See
	Section 7.3 for further details.		Section 7.3 for further details.
	7.2.4. Reject Operation Structure		7.2.4. Reject Operation Structure
	In SPPF, SED Group Offer can be accepted or rejected by, or on behalf		In SPPF, a SED Group Offer can be accepted or rejected by, or on
	of, the registrant to whom the SED Group has been offered (refer		behalf of, the Registrant to whom the SED Group has been offered
	"Framework Data Model Objects" section of		(refer to "Framework Data Model Objects", Section 6 of [RFC7877] for
	[I-D.draft-ietf-drinks-spp-framework] for a description of the SED		a description of the SED Group Offer object). The Reject operation
	Group Offer object). The Reject operation is used to reject such SED		is used to reject such SED Group Offers by, or on behalf of, the
	Group Offers by, or on behalf of, the Registrant. The request		Registrant. The request structure for an SPPP over SOAP Reject
	structure for an SPP Protocol over SOAP Reject operation is wrapped		operation is wrapped within the <spppRejectRequest> element while an
	within the <spppRejectRequest> element while an SPP Protocol over		SPPP over SOAP Reject response is wrapped within the generic
	SOAP Reject response is wrapped within the generic		<spppRejecResponse> element. The following subsections describe the
	<spppRejecResponse> element. The following sub-sections describe the		<spppRejectRequest> and <spppRejecResponse> elements. Refer to
	spppRejectRequest and spppRejecResponse elements. Refer to		Section 10 for an example of the Reject operation on a SED Group
	Section 10 for an example of Reject operation on a SED Group Offer.		Offer.
	7.2.4.1. Reject Request		7.2.4.1. Reject Request
	An SPP Protocol over SOAP Reject request definition is contained		An SPPP over SOAP Reject request definition is contained within the
	within the generic <spppRejectRequest> element.		generic <spppRejectRequest> element.
	<element name="spppRejectRequest">		<element name="spppRejectRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId"		<element name="clientTransId"
	type="sppfb:TransIdType" minOccurs="0"/>		type="sppfb:TransIdType" minOccurs="0"/>
	<element name="minorVer"		<element name="minorVer"
	type="sppfb:MinorVerType" minOccurs="0"/>		type="sppfb:MinorVerType" minOccurs="0"/>
	<element name="sedGrpOfferKey"		<element name="sedGrpOfferKey"
	type="sppfs:SedGrpOfferKeyType"		type="sppfs:SedGrpOfferKeyType"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
			</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <spppRejectRequest> element are		The data elements within the <spppRejectRequest> 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 SPPF client, identifies this request.		within the context of the SPPF client, identifies this request.
	This value can be used at the discretion of the SPPF client to		This value can be used at the discretion of the SPPF client to
	track, log or correlate requests and their responses. SPPF server		track, log, or correlate requests and their responses. The SPPF
	MUST echo back this value to the client in the corresponding		server MUST echo back this value to the client in the
	response to the incoming request. SPPF server will not check this		corresponding response to the incoming request. The SPPF server
	value for uniqueness.		will not check this value for uniqueness.
	o minorVer: Zero or one minor version identifier, as defined in		o minorVer: Zero or one minor version identifier, as defined in
	Section 7.4.		Section 7.4.
	o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType		o sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType
	(as defined in this document). Each element contains attributes		(as defined in this document). Each element contains attributes
	that uniquely identify a SED Group Offer that the client is		that uniquely identify a SED Group Offer that the client is
	requesting the server to reject. The elements are processed by		requesting the server to reject. The elements are processed by
	the SPPF server in the order in which they are included in the		the SPPF server in the order in which they are included in the
	request. With respect to handling of error conditions, conforming		request. With respect to the handling of error conditions,
	SPPF servers MUST stop processing SedGrpOfferKeyType elements in		conforming SPPF servers MUST stop processing SedGrpOfferKeyType
	the request at the first error, and roll back any		elements in the request at the first error and roll back any
	SedGrpOfferKeyType elements that had already been processed for		SedGrpOfferKeyType elements that had already been processed for
	that reject request ("stop and rollback").		that Reject request ("stop and roll back").
	7.2.4.2. Reject Response		7.2.4.2. Reject Response
	An SPP Protocol over SOAP reject response structure is contained		An SPPP over SOAP reject response structure is contained within the
	within the generic <sppRejectResponse> element. This response		generic <sppRejectResponse> element. This response structure is used
	structure is used for an Reject request on a SED Group Offer.		for a Reject request on a SED Group Offer.
	<element name="spppRejectResponse">		<element name="spppRejectResponse">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId" type="sppfb:TransIdType"		<element name="clientTransId" type="sppfb:TransIdType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="serverTransId" type="sppfb:TransIdType"/>		<element name="serverTransId" type="sppfb:TransIdType"/>
	<element name="overallResult" type="sppfs:ResultCodeType"/>		<element name="overallResult" type="sppfs:ResultCodeType"/>
	<element name="detailResult"		<element name="detailResult"
	type="sppfs:SedGrpOfferKeyResultCodeType"		type="sppfs:SedGrpOfferKeyResultCodeType"
	skipping to change at page 22, line 38 ¶		skipping to change at page 21, line 44 ¶
	<extension base="sppfs:ResultCodeType">		<extension base="sppfs:ResultCodeType">
	<sequence>		<sequence>
	<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>		<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/>
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	An <spppRejectResponse> contains the elements necessary for the SPPF		An <spppRejectResponse> contains the elements necessary for the SPPF
	client to precisely determine the overall 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 SED		if an error occurs, it provides information about the specific SED
	Group Offer key(s) that caused the error.		Group Offer key(s) that caused the error.
	The data elements within the SPP Protocol over SOAP Reject response		The data elements within the SPPP over SOAP Reject response are
	are described as follows:		described as 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 SPPF client		simply an echo of the client transaction ID that the SPPF client
	passed into the SPPF update request. When included in the		passed into the SPPF update request. When included in the
	request, the SPPF server MUST return it in the corresponding		request, the SPPF server MUST return it in the corresponding
	response message.		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 MUST be unique for		this request for tracking purposes. This value MUST be unique for
	a given SPPF server.		a given SPPF 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 Section 7.3		explicitly identifies the result of the request. See Section 7.3
	skipping to change at page 23, line 23 ¶		skipping to change at page 22, line 32 ¶
	o detailResult: An optional response code, response message, and		o detailResult: An optional response code, response message, and
	SedGrpOfferKeyType (as defined in this document) triplet. This		SedGrpOfferKeyType (as defined in this document) triplet. This
	element will be present only if any specific SED Group Offer key		element will be present only if any specific SED Group Offer key
	level error has occurred. It indicates the error condition and		level error has occurred. It indicates the error condition and
	the exact request SED Group Offer key that contributed to the		the exact request SED Group Offer key that contributed to the
	error. The response code will reflect the exact error. See		error. The response code will reflect the exact error. See
	Section 7.3 for further details.		Section 7.3 for further details.
	7.2.5. Batch Operation Structure		7.2.5. Batch Operation Structure
	An SPP Protocol over SOAP Batch request XML structure allows the SPPF		An SPPP over SOAP Batch request XML structure allows the SPPF client
	client to send any of of Add, Del, Accept or Reject operations		to send any of the Add, Del, Accept, or Reject operations together in
	together in one single request. This gives an SPPF Client the		one single request. This gives an SPPF client the flexibility to use
	flexibility to use one single request structure to perform more than		one single request structure to perform more than operations (verbs).
	operations (verbs). The batch request structure is wrapped within		The batch request structure is wrapped within the <spppBatchRequest>
	the <spppBatchRequest> element while a SPPF Batch response is wrapped		element while an SPPF Batch response is wrapped within the
	within the <spppBatchResponse> element. This following sub-sections		<spppBatchResponse> element. The following subsections describe the
	describe the spppBatchRequest and spppBatchResponse elements. Refer		<spppBatchRequest> and <spppBatchResponse> elements. Refer to
	to Section 10 for an example of a batch operation.		Section 10 for an example of a Batch operation.
	7.2.5.1. Batch Request Structure		7.2.5.1. Batch Request Structure
	An SPP Protocol over SOAP Batch request definition is contained		An SPPP over SOAP Batch request definition is contained within the
	within the generic <spppBatchRequest> element.		generic <spppBatchRequest> element.
	<element name="spppBatchRequest">		<element name="spppBatchRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId"		<element name="clientTransId"
	type="sppfb:TransIdType" minOccurs="0"/>		type="sppfb:TransIdType" minOccurs="0"/>
	<element name="minorVer"		<element name="minorVer"
	type="sppfb:MinorVerType" minOccurs="0"/>		type="sppfb:MinorVerType" minOccurs="0"/>
	<choice minOccurs="1" maxOccurs="unbounded">		<choice minOccurs="1" maxOccurs="unbounded">
	<element name="addObj" type="sppfb:BasicObjType"/>		<element name="addObj" type="sppfb:BasicObjType"/>
	skipping to change at page 24, line 28 ¶		skipping to change at page 23, line 33 ¶
	type="sppfs:SedGrpOfferKeyType"/>		type="sppfs:SedGrpOfferKeyType"/>
	</choice>		</choice>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <sppBatchRequest> element are described		The data elements within the <sppBatchRequest> element are described
	as follows:		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 SPPF Client, identifies this request.		within the context of the SPPF client, identifies this request.
	This value can be used at the discretion of the SPPF client to		This value can be used at the discretion of the SPPF client to
	track, log or correlate requests and their responses. SPPF Server		track, log, or correlate requests and their responses. The SPPF
	MUST echo back this value to the Client in the corresponding		server MUST echo back this value to the client in the
	response to the incoming request. SPPF Server will not check this		corresponding response to the incoming request. The SPPF server
	value for uniqueness.		will not check this value for uniqueness.
	o minorVer: Zero or one minor version identifier, as defined in		o minorVer: Zero or one minor version identifier, as defined in
	Section 7.4.		Section 7.4.
	o addObj: One or more elements of abstract type BasicObjType where		o addObj: One or more elements of abstract type BasicObjType where
	each element identifies an object that needs to be added.		each element identifies an object that needs to be added.
	o delObj: One or more elements of abstract type ObjKeyType where		o delObj: One or more elements of abstract type ObjKeyType where
	each element identifies a key for the object that needs to be		each element identifies a key for the object that needs to be
	deleted .		deleted .
	o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType		o acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType
	where each element identifies a SED Group Offer that needs to be		where each element identifies a SED Group Offer that needs to be
	accepted.		accepted.
	o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType		o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType
	where each element identifies a SED Group Offer that needs to be		where each element identifies a SED Group Offer that needs to be
	rejected.		rejected.
	With respect to handling of error conditions, conforming SPPP SOAP		With respect to the handling of error conditions, conforming SPPP
	servers MUST stop processing elements in the request at the first		SOAP servers MUST stop processing elements in the request at the
	error, and roll back any elements that had already been processed for		first error and roll back any elements that had already been
	that batch request ("stop and rollback").		processed for that Batch request ("stop and roll back").
	7.2.5.2. Batch Response		7.2.5.2. Batch Response
	An SPP Protocol over SOAP batch response structure is contained		An SPPP over SOAP batch response structure is contained within the
	within the generic <sppBatchResponse> element. This response		generic <sppBatchResponse> element. This response structure is used
	structure is used for an Batch request that contains many different		for a Batch request that contains many different types of SPPF
	types of SPPF operations.		operations.
	<element name="spppBatchResponse">		<element name="spppBatchResponse">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="clientTransId" type="sppfb:TransIdType"		<element name="clientTransId" type="sppfb:TransIdType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="serverTransId" type="sppfb:TransIdType"/>		<element name="serverTransId" type="sppfb:TransIdType"/>
	<element name="overallResult" type="sppfs:ResultCodeType"/>		<element name="overallResult" type="sppfs:ResultCodeType"/>
	<choice minOccurs="0" maxOccurs="unbounded">		<choice minOccurs="0" maxOccurs="unbounded">
	<element name="addResult"		<element name="addResult"
	skipping to change at page 25, line 40 ¶		skipping to change at page 24, line 44 ¶
	type="sppfs:SedGrpOfferKeyResultCodeType"/>		type="sppfs:SedGrpOfferKeyResultCodeType"/>
	<element name="rejectResult"		<element name="rejectResult"
	type="sppfs:SedGrpOfferKeyResultCodeType"/>		type="sppfs:SedGrpOfferKeyResultCodeType"/>
	</choice>		</choice>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	An <spppBatchResponse> contains the elements necessary for an SPPF		An <spppBatchResponse> contains the elements necessary for an SPPF
	client to precisely determine the overall result of various		client to precisely determine the overall result of various
	operations in the request, and if an error occurred, it provides		operations in the request, and if an error occurs, it provides
	information about the specific objects or keys in the request that		information about the specific objects or keys in the request that
	caused the error.		caused the error.
	The data elements within the SPP Protocol over SOAP Batch response		The data elements within the SPPP over SOAP Batch response are
	are described as follows:		described as 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 SPPF client		simply an echo of the client transaction ID that the SPPF client
	passed into the SPPF update request. When included in the		passed into the SPPF update request. When included in the
	request, the SPPF server MUST return it in the corresponding		request, the SPPF server MUST return it in the corresponding
	response message.		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 MUST be unique for		this request for tracking purposes. This value MUST be unique for
	a given SPPF server.		a given SPPF 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 Section 7.3		explicitly identifies the result of the request. See Section 7.3
	for further details.		for further details.
	o addResult: One or more elements of type ObjResultCodeType where		o addResult: One or more elements of type ObjResultCodeType where
	each element identifies the result code, result message and the		each element identifies the result code, result message, and the
	specific object that the result relates to.		specific object to which the result relates.
	o delResult: One or more elements of type ObjKeyResultCodeType where		o delResult: One or more elements of type ObjKeyResultCodeType where
	each element identifies the result code, result message and the		each element identifies the result code, result message, and the
	specific object key that the result relates to.		specific object key to which the result relates.
	o acceptResult: One or more elements of type		o acceptResult: One or more elements of type
	SedGrpOfferKeyResultCodeType where each element identifies the		SedGrpOfferKeyResultCodeType where each element identifies the
	result code, result message and the specific SED Group Offer key		result code, result message, and the specific SED Group Offer key
	that the result relates to.		to which the result relates.
	o rejectResult: One or more elements of type		o rejectResult: One or more elements of type
	SedGrpOfferKeyResultCodeType where each element identifies the		SedGrpOfferKeyResultCodeType where each element identifies the
	result code, result message and the specific SED Group Offer key		result code, result message, and the specific SED Group Offer key
	that the result relates to.		to which the result relates.
	7.2.6. Get Operation Structure		7.2.6. Get Operation Structure
	In order to query the details of an object from the Registry, an		In order to query the details of an object from the Registry, an
	authorized entity can send the spppGetRequest to the registry with a		authorized entity can send the spppGetRequest to the Registry with a
	GetRqstType XML data structure containing one or more object keys		GetRqstType XML data structure containing one or more object keys
	that uniquely identify the object whose details are being queried.		that uniquely identify the object whose details are being queried.
	The request structure for an SPP Protocol over SOAP Get operation is		The following subsections describe the <spppGetRequest> and
	contained within the generic <spppGetRequest> element while an SPP		<spppGetResponse> elements. Refer to Section 10 for an example of
	Protocol over SOAP Get response is wrapped within the generic		the SPPP over SOAP Get operation on each type of SPPF object.
	<spppGetResponse> element. The following sub-sections describe the
	spppGetRequest and spppGetResponse element. Refer to Section 10 for
	an example of SPP Protocol over SOAP Get operation on each type of
	SPPF object
	7.2.6.1. Get Request		7.2.6.1. Get Request
			The request structure for an SPPP over SOAP Get operation is
			contained within the generic <spppGetRequest> element:
	<element name="spppGetRequest">		<element name="spppGetRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="minorVer"		<element name="minorVer"
	type="sppfb:MinorVerType" minOccurs="0"/>		type="sppfb:MinorVerType" minOccurs="0"/>
	<element name="objKey"		<element name="objKey"
	type="sppfb:ObjKeyType"		type="sppfb:ObjKeyType"
	maxOccurs="unbounded"/>		maxOccurs="unbounded"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <spppGetRequest> element are described		The data elements within the <spppGetRequest> element are described
	as follows:		as follows:
	o minorVer: Zero or one minor version identifier, as defined in		o minorVer: Zero or one minor version identifier, as defined in
	Section 7.4.		Section 7.4.
	o objKey: One or more elements of abstract type ObjKeyType (as		o objKey: One or more elements of abstract type ObjKeyType (as
	defined in [I-D.draft-ietf-drinks-spp-framework]). Each element		defined in [RFC7877]). Each element contains attributes that
	contains attributes that uniquely identify the object that the		uniquely identify the object that the client is requesting the
	client is requesting the server to query. Refer to Section 7.1 of		server to query. Refer to Section 7.1 of this document for a
	this document for a description of all concrete object key types,		description of all concrete object key types, for various SPPF
	for various SPPF objects, which are eligible to be passed into		objects, which are eligible to be passed into this element.
	this element.
	7.2.6.2. Get Response		7.2.6.2. Get Response
	The spppGetResponse element is described in Section 7.2.8.		The SPPP over SOAP Get response is wrapped within the generic
			<spppGetResponse> element, as described in Section 7.2.8.
	7.2.7. Get SED Group Offers Operation Structure		7.2.7. Get SED Group Offers Operation Structure
	In addition to the ability to query the details of one or more SED		In addition to the ability to query the details of one or more SED
	Group offers using an a SED Group Offer key in the spppGetRequest,		Group Offers using a SED Group Offer key in the spppGetRequest, this
	this operation also provides an additional, more flexible, structure		operation also provides an additional, more flexible, structure to
	to query for SED Group Offer objects. This additional structure is		query for SED Group Offer objects. This additional structure is
	contained within the <getSedGrpOffersRequest> element while the		contained within the <getSedGrpOffersRequest> element while the
	response is wrapped within the generic <spppGetResponse> element.		response is wrapped within the generic <spppGetResponse> element.
	The following sub-sections describe the getSedGrpOffersRequest and		The following subsections describe the <getSedGrpOffersRequest> and
	spppGetResponse elements.		<spppGetResponse> elements.
	7.2.7.1. Get SED Group Offers Request		7.2.7.1. Get SED Group Offers Request
	Using the details passed into this structure, the server will attempt		Using the details passed into this structure, the server will attempt
	to find SED Group Offer objects that satisfy all the criteria passed		to find SED Group Offer objects that satisfy all the criteria passed
	into the request. If no criteria is passed in then the SPPF Server		into the request. If no criteria are passed in, then the SPPF server
	will return the list of SED Group Offer objects that belongs to the		will return the list of SED Group Offer objects that belong to the
	registrant. If there are no matching SED Group Offers found then an		Registrant. If there are no matching SED Group Offers found, then an
	empty result set will be returned.		empty result set will be returned.
	<element name="getSedGrpOffersRequest">		<element name="getSedGrpOffersRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="minorVer" type="sppfb:MinorVerType"		<element name="minorVer" type="sppfb:MinorVerType"
	minOccurs="0"/>		minOccurs="0"/>
	<element name="offeredBy" type="sppfb:OrgIdType"		<element name="offeredBy" type="sppfb:OrgIdType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	<element name="offeredTo" type="sppfb:OrgIdType"		<element name="offeredTo" type="sppfb:OrgIdType"
	skipping to change at page 28, line 42 ¶		skipping to change at page 27, line 49 ¶
	the result set. The result set is also subject to other query		the result set. The result set is also subject to other query
	criteria in the request.		criteria in the request.
	o offeredTo: Zero or more organization IDs. Only offers that are		o offeredTo: Zero or more organization IDs. Only offers that are
	offered by the organization IDs in this list should be included in		offered by the organization IDs in this list should be included in
	the result set. The result set is also subject to other query		the result set. The result set is also subject to other query
	criteria in the request.		criteria in the request.
	o status: The status of the offer, offered or accepted. Only offers		o status: The status of the offer, offered or accepted. Only offers
	in the specified status should be included in the result set. If		in the specified status should be included in the result set. If
	this element is not present then the status of the offer should		this element is not present, then the status of the offer should
	not be considered in the query. The result set is also subject to		not be considered in the query. The result set is also subject to
	other query criteria in the request.		other query criteria in the request.
	o sedGrpOfferKey: Zero or more SED Group Offer Keys. Only offers		o sedGrpOfferKey: Zero or more SED Group Offer keys. Only offers
	having one of these keys should be included in the result set.		having one of these keys should be included in the result set.
	The result set is also subject to other query criteria in the		The result set is also subject to other query criteria in the
	request.		request.
	7.2.7.2. Get SED Group Offers Response		7.2.7.2. Get SED Group Offers Response
	The spppGetResponse element is described in Section 7.2.8.		The spppGetResponse element is described in Section 7.2.8.
	7.2.8. Generic Query Response		7.2.8. Generic Query Response
	An SPP Protocol over SOAP query response object is contained within		An SPPP over SOAP query response object is contained within the
	the generic <spppGetResponse> element.		generic <spppGetResponse> element.
	<element name="spppGetResponse">		<element name="spppGetResponse">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="overallResult"		<element name="overallResult"
	type="sppfs:ResultCodeType"/>		type="sppfs:ResultCodeType"/>
	<element name="resultObj"		<element name="resultObj"
	type="sppfb:BasicObjType"		type="sppfb:BasicObjType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	An <spppGetResponse> contains the elements necessary for the SPPF		An <spppGetResponse> contains the elements necessary for the SPPF
	client to precisely determine the overall result of the query, and		client to precisely determine the overall result of the query and
	details of any SPPF objects that matched the criteria in the request.		details of any SPPF objects that matched the criteria in the request.
	The data elements within the SPP Protocol over SOAP query response		The data elements within the SPPP over SOAP query response are
	are described as follows:		described as 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 Section 7.3		explicitly identifies the result of the request. See Section 7.3
	for further details.		for further details.
	o resultObj: The set of zero or more objects that matched the query		o resultObj: The set of zero or more objects that matched the query
	criteria. If no objects matched the query criteria then the		criteria. If no objects matched the query criteria, then the
	result object(s) MUST be empty and the overallResult value MUST		result object(s) MUST be empty and the overallResult value MUST
	indicate success (if no matches are found for the query criteria,		indicate success (if no matches are found for the query criteria,
	the response is considered a success).		the response is considered a success).
	7.2.9. Get Server Details Operation Structure		7.2.9. Get Server Details Operation Structure
	In order to query certain details of the SPPF server, such as the		In order to query certain details of the SPPF server, such as the
	SPPF server's status and the major/minor version supported by the		SPPF server's status and the major/minor version supported by the
	server, the Server Details operation structure SHOULD be used. This		server, the Server Details operation structure SHOULD be used. This
	structure is contained within the <spppServerStatusRequest> element		structure is contained within the <spppServerStatusRequest> element
	whereas a SPPF server status response is wrapped within the		whereas an SPPF server status response is wrapped within the
	<spppServerStatusResponse> element. The following sub-sections		<spppServerStatusResponse> element. The following subsections
	describe the spppServerStatusRequest and spppServerStatusResponse		describe the <spppServerStatusRequest> and <spppServerStatusResponse>
	elements.		elements.
	7.2.9.1. Get Server Details Request		7.2.9.1. Get Server Details Request
			An SPPP over SOAP server details request structure is represented in
			the <spppServerStatusRequest> element as follows:
	<element name="spppServerStatusRequest">		<element name="spppServerStatusRequest">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="minorVer"		<element name="minorVer"
	type="sppfb:MinorVerType" minOccurs="0"/>		type="sppfb:MinorVerType" minOccurs="0"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <spppServerStatusRequest> element are		The data elements within the <spppServerStatusRequest> element are
	described as follows:		described as follows:
	o minorVer: Zero or one minor version identifier, as defined in		o minorVer: Zero or one minor version identifier, as defined in
	Section 7.4.		Section 7.4.
	7.2.9.2. Get Server Details Response		7.2.9.2. Get Server Details Response
	An SPP Protocol over SOAP server details response structure is		An SPPP over SOAP server details response structure is contained
	contained within the generic <spppServerStatusResponse> element.		within the generic <spppServerStatusResponse> element.
	<element name="spppServerStatusResponse">		<element name="spppServerStatusResponse">
	<complexType>		<complexType>
	<sequence>		<sequence>
	<element name="overallResult" type="sppfs:ResultCodeType"/>		<element name="overallResult" type="sppfs:ResultCodeType"/>
	<element name="svcMenu" type="sppfb:SvcMenuType"/>		<element name="svcMenu" type="sppfb:SvcMenuType"/>
	</sequence>		</sequence>
	</complexType>		</complexType>
	</element>		</element>
	The data elements within the <spppServerStatusResponse> element are		The data elements within the <spppServerStatusResponse> element are
	described as follows:		described as 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 Section 7.3		explicitly identifies the result of the request. See Section 7.3
	for further details.		for further details.
	o svcMenu: Exactly one element of type SvcMenuType which in turn		o svcMenu: Exactly one element of type SvcMenuType that, in turn,
	contains the elements to return the server status, the major and		contains the elements to return the server status, the major and
	minor versions of the SPP Protocol over SOAP supported by the SPPF		minor versions of SPPP over SOAP supported by the SPPF server
	server (refer Section 12 of [I-D.draft-ietf-drinks-spp-framework]		(refer to Section 12 of [RFC7877] for the definition of
	for definition of SvcMenuType).		SvcMenuType).
	7.3. Response Codes and Messages		7.3. Response Codes and Messages
	This section contains the listing of response codes and their		This section contains the listing of response codes and their
	corresponding human-readable text. These response codes are in		corresponding human-readable text. These response codes are in
	conformance with the response types defined in Section 5.3 of		conformance with the response types defined in Section 5.3 of
	[I-D.draft-ietf-drinks-spp-framework].		[RFC7877].
	The response code numbering scheme generally adheres to the theory		The response code numbering scheme generally adheres to the theory
	formalized in section 4.2.1 of [RFC5321]:		formalized in Section 4.2.1 of [RFC5321]:
	o The first digit of the response code can only be 1 or 2: 1 = a		o The first digit of the response code can only be 1 or 2: 1 = a
	positive result, 2 = a negative result.		positive result, and 2 = a negative result.
	o The second digit of the response code indicates the category: 0 =		o The second digit of the response code indicates the category: 0 =
	Protocol Syntax, 1 = Implementation Specific Business Rule, 2 =		Protocol Syntax, 1 = Implementation Specific Business Rule, 2 =
	Security, 3 = Server System.		Security, and 3 = Server System.
	o The third and fourth digits of the response code indicate the		o The third and fourth digits of the response code indicate the
	individual message event within the category defines by the first		individual message event within the category defined by the first
	two digits.		two digits.
	The response codes are also categorized as to whether they are		The response codes are also categorized as to whether they are
	overall response codes that may only be returned in the		overall response codes that may only be returned in the overallResult
	"overallResult" data element in SPPF responses, or object level		data element in SPPF responses or object-level response codes that
	response codes that may only be returned in the "detailResult"		may only be returned in the detailResult element of the SPPF
	element of the SPPF responses.		responses.
	+--------+--------------------------+-------------------------------+		+--------+--------------------------+-------------------------------+
	| Result | Result Message | Overall or Object Level |		| Result | Result Message | Overall or Object Level |
	| Code | | |		| Code | | |
	+--------+--------------------------+-------------------------------+		+--------+--------------------------+-------------------------------+
	| 1000 | Request Succeeded. | Overall Response Code |		| 1000 | Request succeeded | Overall Response Code |
	| | | |		| 2000 | Request syntax invalid | Overall Response Code |
	| 2000 | Request syntax invalid. | Overall Response Code |		| 2001 | Request too large | Overall Response Code |
	| | | |
	| 2001 | Request too large. | Overall Response Code |
	| | MaxSupported:[Maximum | |		| | MaxSupported:[Maximum | |
	| | requests supported] | |		| | requests supported] | |
	| | | |		| 2002 | Version not supported | Overall Response Code |
	| 2002 | Version not supported. | Overall Response Code |		| 2100 | Command invalid | Overall Response Code |
	| | | |
	| 2100 | Command invalid. | Overall Response Code |
	| | | |
	| 2300 | System temporarily | Overall Response Code |		| 2300 | System temporarily | Overall Response Code |
	| | unavailable. | |		| | unavailable | |
	| | | |
	| 2301 | Unexpected internal | Overall Response Code |		| 2301 | Unexpected internal | Overall Response Code |
	| | system or server error. | |		| | system or server error | |
	| | | |		| 2101 | Attribute value invalid | Object-Level Response Code |
	| 2101 | Attribute value invalid. | Object Level Response Code |
	| | AttrName:[AttributeName] | |		| | AttrName:[AttributeName] | |
	| | AttrVal:[AttributeValue] | |		| | AttrVal:[AttributeValue] | |
	| | | |		| 2102 | Object does not exist | Object-Level Response Code |
	| 2102 | Object does not exist. | Object Level Response Code |
	| | AttrName:[AttributeName] | |		| | AttrName:[AttributeName] | |
	| | AttrVal:[AttributeValue] | |		| | AttrVal:[AttributeValue] | |
	| | | |		| 2103 | Object status or | Object-Level Response Code |
	| 2103 | Object status or | Object Level Response Code |
	| | ownership does not allow | |		| | ownership does not allow | |
	| | for operation. | |		| | for operation | |
	| | AttrName:[AttributeName] | |		| | AttrName:[AttributeName] | |
	| | AttrVal:[AttributeValue] | |		| | AttrVal:[AttributeValue] | |
	+--------+--------------------------+-------------------------------+		+--------+--------------------------+-------------------------------+
	Table 1: Response Codes Numbering Scheme and Messages		Table 1: Response Code Numbering Scheme and Messages
	Response message for response code 2001 is "parameterized" with the		The response message for response code 2001 is "parameterized" with
	following parameter: "[Maximum requests supported]". When the		the following parameter: "[Maximum requests supported]". When the
	request is too large, this parameter MUST be used to indicate the		request is too large, this parameter MUST be used to indicate the
	maximum number of requests supported by the server in a single		maximum number of requests supported by the server in a single
	protocol operation.		protocol operation.
	Response code 2000 SHOULD be used when the XML Schema validation of		Response code 2000 SHOULD be used when the XML Schema validation of
	requests fails.		requests fails.
	Each of the object level response messages are "parameterized" with		Each of the object-level response messages are "parameterized" with
	the following parameters: "AttributeName" and "AttributeValue".		the following parameters: "AttributeName" and "AttributeValue".
	For example, if an SPPF client sends a request to delete a		For example, if an SPPF client sends a request to delete a
	Destination Group with a name "TestDG", and it does not already		Destination Group with a name "TestDG", and it does not already
	exist, then the error message returned should be: "Attribute value		exist, then the error message returned should be: "Attribute value
	invalid. AttrName:dgName AttrVal:TestDG".		invalid. AttrName:dgName AttrVal:TestDG".
	The use of these parameters MUST adhere to the rules defined in		The use of these parameters MUST adhere to the rules defined in
	Section 5.3 of [I-D.draft-ietf-drinks-spp-framework].		Section 5.3 of [RFC7877].
	7.4. Minor Version Identifier		7.4. Minor Version Identifier
	The minor version identifier element is defined as follows:		The minor version identifier element is defined as follows:
	o minorVer: Zero or one minor version identifier, indicating the		o minorVer: Zero or one minor version identifier, indicating the
	minor version of the SPP Protocol over SOAP API that the client is		minor version of the SPPP over SOAP API that the client is
	attempting to use. This is used in conjunction with the major		attempting to use. This is used in conjunction with the major
	version identifier in the XML namespace to identify the version of		version identifier in the XML Namespace to identify the version of
	SPP Protocol over SOAP that the client is using. If the element		SPPP over SOAP that the client is using. If the element is not
	is not present, the server assumes that the client is using the		present, the server assumes that the client is using the latest
	latest minor version of SPP Protocol over SOAP supported by the		minor version of SPPP over SOAP supported by the SPPF server for
	SPPF server for the given major version. The versions of SPP		the given major version. The versions of SPPP over SOAP supported
	Protocol over SOAP supported by a given SPPF server can be		by a given SPPF server can be retrieved by the client using this
	retrieved by the client using this same spppServerStatusRequest		same spppServerStatusRequest without passing in the minorVer
	without passing in the minorVer element.		element.
	8. Protocol Operations		8. Protocol Operations
	Refer to Section 7 of [I-D.draft-ietf-drinks-spp-framework] for a		Refer to Section 7 of [RFC7877] for a description of all SPPF
	description of all SPPF operations, and any necessary semantics that		operations and any necessary semantics that MUST be adhered to in
	MUST be adhered to in order to conform with SPPF.		order to conform with SPPF.
	9. SPP Protocol over SOAP WSDL Definition		9. SPPP over SOAP WSDL Definition
	The SPP Protocol over SOAP WSDL and data types are defined below.		The SPPP over SOAP WSDL and data types are defined below. The WSDL
	The WSDL design approach is commonly referred to as "Generic WSDL".		design approach is commonly referred to as "Generic WSDL". It is
	It is generic in the sense that there is not a specific WSDL		generic in the sense that there is not a specific WSDL operation
	operation defined for each object type that is supported by the SPPF		defined for each object type that is supported by the SPPF protocol.
	protocol. There is a single WSDL structure for each type of SPPF		There is a single WSDL structure for each type of SPPF operation.
	operation. Each such WSDL structure contains exactly one input		Each such WSDL structure contains exactly one input structure and one
	structure and one output structure that wraps any data elements that		output structure that wraps any data elements that are part of the
	are part of the incoming request and the outgoing response		incoming request and the outgoing response, respectively. The
	respectively. The spppSOAPBinding in the WSDL defines the binding		spppSOAPBinding in the WSDL defines the binding style as "document"
	style as "document" and the encoding as "literal". It is this		and the encoding as "literal". It is this combination of "wrapped"
	combination of "wrapped" input and output data structures, "document"		input and output data structures, "document" binding style, and
	binding style, and "literal" encoding that characterize the Document		"literal" encoding that characterize the Document Literal Wrapped
	Literal Wrapped style of WSDL specifications.		style of WSDL specifications.
	Notes: The following WSDL has been formatted (e.g. tabs, spaces) to		Notes: The following WSDL has been formatted (e.g., tabs, spaces) to
	meet IETF document requirements. Deployments MUST replace		meet IETF requirements. Deployments MUST replace
	"REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF		"REPLACE_WITH_ACTUAL_URL" in the WSDL below with the URI of the SPPF
	Server instance.		server instance.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"		<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
	xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"		xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema"		xmlns:xsd="http://www.w3.org/2001/XMLSchema"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1"
	targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">		targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1">
	<wsdl:types>		<wsdl:types>
	skipping to change at page 45, line 5 ¶		skipping to change at page 44, line 5 ¶
	</wsdl:binding>		</wsdl:binding>
	<wsdl:service name="spppService">		<wsdl:service name="spppService">
	<wsdl:port name="spppPort" binding="sppfs:spppSoapBinding">		<wsdl:port name="spppPort" binding="sppfs:spppSoapBinding">
	<soap:address location="REPLACE_WITH_ACTUAL_URL"/>		<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
	</wsdl:port>		</wsdl:port>
	</wsdl:service>		</wsdl:service>
	</wsdl:definitions>		</wsdl:definitions>
	Figure 2: WSDL		Figure 2: WSDL
	10. SPP Protocol over SOAP Examples		10. SPPP over SOAP Examples
	This section shows XML message exchange between two SIP Service		This section shows an XML message exchange between two SIP Service
	Providers (SSP) and a registry. The messages in this section are		Providers (SSPs) and a Registry. The messages in this section are
	valid XML instances that conform to the SPP Protocol over SOAP schema		valid XML instances that conform to the SPPP over SOAP schema version
	version within this document. This section also relies on the XML		within this document. This section also relies on the XML data
	data structures defined in the SPPF specification		structures defined in the SPPF specification [RFC7877], which should
	[I-D.draft-ietf-drinks-spp-framework]. Which should also be		also be referenced to understand XML object types embedded in these
	referenced to understand XML object types embedded in these example		example messages.
	messages.
	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 SPPF constructs to selectively share the		data in the Registry and use SPPF constructs to selectively share the
	SED groups. In the figure below, SSP2 has two ingress SBE instances		SED Groups. In the figure below, SSP2 has two ingress Signaling Path
	that are associated with the public identities that SSP2 has the		Border Element (SBE) instances that are associated with the Public
	retail relationship with. Also, the two Session Border Element		Identities with which SSP2 has the retail relationship. Also, the
	instances for SSP1 are used to show how to use SPPF to associate		two SBE instances for SSP1 are used to show how to use SPPF to
	route preferences for the destination ingress routes and exercise		associate route preferences for the destination Ingress Routes and
	greater control on outbound traffic to the peer's ingress SBEs.		exercise greater control on 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
	---------------+ +------------------		---------------+ +------------------
	| |		| |
	| |		| |
	| SPPF +------------------+ SPPF |		| SPPF +------------------+ SPPF |
	+------->| Registry |<--------+		+------->| Registry |<--------+
	+------------------+		+------------------+
			Example Use-Case Infrastructure
	10.1. Add Destination Group		10.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 later use. The
	SSP2 SPPF client sets a unique transaction identifier 'txn_1479' for		SSP2 SPPF client sets a unique transaction identifier "txn_1479" 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"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAddRequest>		<urn:spppAddRequest>
	<!--Optional:-->		<!--Optional:-->
	skipping to change at page 46, line 25 ¶		skipping to change at page 45, line 26 ¶
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<obj xsi:type="urn1:DestGrpType">		<obj xsi:type="urn1:DestGrpType">
	<urn1:rant>iana-en:222</urn1:rant>		<urn1:rant>iana-en:222</urn1:rant>
	<urn1:rar>iana-en:223</urn1:rar>		<urn1:rar>iana-en:223</urn1:rar>
	<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>		<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	The registry processes the request and return a favorable response		The Registry processes the request and returns a favorable response
	confirming successful creation of the named destination group. Also,		confirming successful creation of the named Destination Group. In
	besides returning a unique server transaction identifier, Registry		addition to returning a unique server transaction identifier, the
	also returns the matching client transaction identifier from the		Registry returns the matching client transaction identifier from the
	request message back to the SPPF client.		request message back to the SPPF client.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	skipping to change at page 47, line 7 ¶		skipping to change at page 46, line 7 ¶
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.2. Add SED Records		10.2. Add SED Records
	SSP2 adds SED records in the form of ingress routes to the registry.		SSP2 adds SED Records in the form of Ingress Routes to the Registry.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAddRequest>		<urn:spppAddRequest>
	skipping to change at page 47, line 37 ¶		skipping to change at page 47, line 4 ¶
	<urn1:flags>u</urn1:flags>		<urn1:flags>u</urn1:flags>
	<urn1:svcs>E2U+sip</urn1:svcs>		<urn1:svcs>E2U+sip</urn1:svcs>
	<urn1:regx>		<urn1:regx>
	<urn1:ere>^(.*)$</urn1:ere>		<urn1:ere>^(.*)$</urn1:ere>
	<urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>		<urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>
	</urn1:regx>		</urn1:regx>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			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"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12345</serverTransId>		<serverTransId>tx_12345</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.3. Add SED Records -- URIType		10.3. Add SED Records -- URIType
	SSP2 adds another SED record to the registry and makes use of URIType		SSP2 adds another SED Record to the Registry and makes use of
			URIType.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAddRequest>		<urn:spppAddRequest>
	skipping to change at page 48, line 48 ¶		skipping to change at page 48, line 4 ¶
	<urn1:rant>iana-en:222</urn1:rant>		<urn1:rant>iana-en:222</urn1:rant>
	<urn1:rar>iana-en:223</urn1:rar>		<urn1:rar>iana-en:223</urn1:rar>
	<urn1:sedName>SED_SSP2_SBE4</urn1:sedName>		<urn1:sedName>SED_SSP2_SBE4</urn1:sedName>
	<urn1:isInSvc>true</urn1:isInSvc>		<urn1:isInSvc>true</urn1:isInSvc>
	<urn1:ere>^(.*)$</urn1:ere>		<urn1:ere>^(.*)$</urn1:ere>
	<urn1:uri>sip:\1;npdi@sbe4.ssp2.example.com</urn1:uri>		<urn1:uri>sip:\1;npdi@sbe4.ssp2.example.com</urn1:uri>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			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"?>
	<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12345</serverTransId>		<serverTransId>tx_12345</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.4. Add SED Group		10.4. Add SED Group
	SSP2 creates the grouping of SED records (e.g. ingress routes) and		SSP2 creates the grouping of SED Records (e.g., Ingress Routes) and
	chooses higher precedence for SED_SSP2_SBE2 by setting a lower number		chooses a higher precedence for SED_SSP2_SBE2 by setting a lower
	for the "priority" attribute, a protocol agnostic precedence		number for the "priority" attribute, a protocol agnostic precedence
	indicator.		indicator.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	skipping to change at page 50, line 35 ¶		skipping to change at page 50, line 4 ¶
	</urn1:sedKey>		</urn1:sedKey>
	<urn1:priority>100</urn1:priority>		<urn1:priority>100</urn1:priority>
	</urn1:sedRecRef>		</urn1:sedRecRef>
	<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>		<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
	<urn1:isInSvc>true</urn1:isInSvc>		<urn1:isInSvc>true</urn1:isInSvc>
	<urn1:priority>10</urn1:priority>		<urn1:priority>10</urn1:priority>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			To confirm successful processing of this request, the Registry
	To confirm successful processing of this request, registry returns a		returns a well-known result code "1000" to the SSP2 client.
	well-known result code '1000' to the SSP2 client.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12345</serverTransId>		<serverTransId>tx_12345</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.5. Add Public Identifier -- Successful COR claim		10.5. Add Public Identifier -- Successful COR Claim
	SSP2 activates a TN public identifier by associating it with a valid		SSP2 activates a TN Public Identifier by associating it with a valid
	destination group. Further, SSP2 puts forth a claim that it is the		Destination Group. Further, SSP2 puts forth a claim that it is the
	carrier-of-record for the TN.		carrier-of-record (COR) for the TN.
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAddRequest>		<urn:spppAddRequest>
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	skipping to change at page 52, line 4 ¶		skipping to change at page 51, line 4 ¶
	<urn1:rar>iana-en:223</urn1:rar>		<urn1:rar>iana-en:223</urn1:rar>
	<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>		<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
	<urn1:tn>+12025556666</urn1:tn>		<urn1:tn>+12025556666</urn1:tn>
	<urn1:corInfo>		<urn1:corInfo>
	<urn1:corClaim>true</urn1:corClaim>		<urn1:corClaim>true</urn1:corClaim>
	</urn1:corInfo>		</urn1:corInfo>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	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 SP of
	service provider of record for the given TN, the request is processed		record for the given TN, the request is processed successfully. In
	successfully. In the response message, the registry sets the value		the response message, the Registry sets the value of <cor> to "true"
	of <cor> to "true" in order to confirm SSP2 claim as the carrier of		in order to confirm the SSP2 claim as the carrier-of-record, and the
	record and the <corDate> reflects the time when the carrier of record		<corDate> reflects the time when the carrier-of-record claim is
	claim is processed.		processed.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	skipping to change at page 53, line 7 ¶		skipping to change at page 52, line 7 ¶
	<ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate>		<ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate>
	</ns2:corInfo>		</ns2:corInfo>
	</obj>		</obj>
	</detailResult>		</detailResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.6. Add LRN		10.6. Add LRN
	If another entity that SSP2 shares session establishment information		If another entity that SSP2 shares SED (e.g., routes) with has access
	(e.g. routes) with has access to Number Portability data, it may		to Number Portability data, it may choose to perform route lookups by
	choose to perform route lookups by routing number. Therefore, SSP2		RN. Therefore, SSP2 associates an RN to a Destination Group in order
	associates a routing number to a destination group in order to		to facilitate Ingress Route discovery.
	facilitate ingress route discovery.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAddRequest>		<urn:spppAddRequest>
	skipping to change at page 53, line 33 ¶		skipping to change at page 53, line 4 ¶
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<obj xsi:type="urn1:RNType">		<obj xsi:type="urn1:RNType">
	<urn1:rant>iana-en:222</urn1:rant>		<urn1:rant>iana-en:222</urn1:rant>
	<urn1:rar>iana-en:223</urn1:rar>		<urn1:rar>iana-en:223</urn1:rar>
	<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>		<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
	<urn1:rn>2025550000</urn1:rn>		<urn1:rn>2025550000</urn1:rn>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The Registry completes the request successfully and returns a
	Registry completes the request successfully and returns a favorable		favorable response to the SPPF client.
	response to the SPPF client.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12345</serverTransId>		<serverTransId>tx_12345</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.7. Add TN Range		10.7. Add TN Range
	Next, SSP2 activates a block of ten thousand TNs and associate it to		Next, SSP2 activates a block of ten thousand TNs and associates it to
	a destination group.		a Destination Group.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAddRequest>		<urn:spppAddRequest>
	skipping to change at page 55, line 4 ¶		skipping to change at page 54, line 4 ¶
	<urn1:rar>iana-en:223</urn1:rar>		<urn1:rar>iana-en:223</urn1:rar>
	<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>		<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
	<urn1:range>		<urn1:range>
	<urn1:startTn>+12026660000</urn1:startTn>		<urn1:startTn>+12026660000</urn1:startTn>
	<urn1:endTn>+12026669999</urn1:endTn>		<urn1:endTn>+12026669999</urn1:endTn>
	</urn1:range>		</urn1:range>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry completes the request successfully and returns a favorable		The Registry completes the request successfully and returns a
	response.		favorable response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12345</serverTransId>		<serverTransId>tx_12345</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.8. Add TN Prefix		10.8. Add TN Prefix
	Next, SSP2 activates a block of ten thousand TNs using the TNPType		Next, SSP2 activates a block of ten thousand TNs by using the TNPType
	structure and identifying a TN prefix.		structure and identifying a TN prefix.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	skipping to change at page 56, line 25 ¶		skipping to change at page 55, line 4 ¶
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<obj xsi:type="urn1:TNPType">		<obj xsi:type="urn1:TNPType">
	<urn1:rant>iana-en:222</urn1:rant>		<urn1:rant>iana-en:222</urn1:rant>
	<urn1:rar>iana-en:223</urn1:rar>		<urn1:rar>iana-en:223</urn1:rar>
	<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>		<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
	<urn1:tnPrefix>+1202777</urn1:tnPrefix>		<urn1:tnPrefix>+1202777</urn1:tnPrefix>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The Registry completes the request successfully and returns a
	Registry completes the request successfully and returns a favorable		favorable response.
	response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12345</serverTransId>		<serverTransId>tx_12345</serverTransId>
	skipping to change at page 57, line 9 ¶		skipping to change at page 56, line 9 ¶
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.9. Enable Peering -- SED Group Offer		10.9. Enable Peering -- SED Group Offer
	In order for SSP1 to complete session establishment for a destination		In order for SSP1 to complete session establishment for a destination
	TN where the target subscriber has a retail relationship with SSP2,		TN where the target subscriber has a retail relationship with SSP2,
	it first requires an asynchronous bi-directional handshake to show		it first requires an asynchronous bidirectional handshake to show
	mutual consent. To start the process, SSP2 initiates the peering		mutual consent. To start the process, SSP2 initiates the peering
	handshake by offering SSP1 access to its SED group.		handshake by offering SSP1 access to its SED Group.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAddRequest>		<urn:spppAddRequest>
	skipping to change at page 57, line 43 ¶		skipping to change at page 57, line 4 ¶
	<offeredTo>iana-en:111</offeredTo>		<offeredTo>iana-en:111</offeredTo>
	</urn1:sedGrpOfferKey>		</urn1:sedGrpOfferKey>
	<urn1:status>offered</urn1:status>		<urn1:status>offered</urn1:status>
	<urn1:offerDateTime>		<urn1:offerDateTime>
	2006-05-04T18:13:51.0Z		2006-05-04T18:13:51.0Z
	</urn1:offerDateTime>		</urn1:offerDateTime>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The 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"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	skipping to change at page 58, line 25 ¶		skipping to change at page 58, line 8 ¶
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.10. Enable Peering -- SED Group Offer Accept		10.10. Enable Peering -- SED Group Offer Accept
	SSP1 responds to the offer from SSP2 and agrees to have visibility to		SSP1 responds to the offer from SSP2 and agrees to have visibility to
	SSP2 session establishment information (e.g. ingress routes).		SSP2 SED (e.g., Ingress Routes).
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppAcceptRequest>		<urn:spppAcceptRequest>
	<!--Optional:-->		<!--Optional:-->
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	skipping to change at page 59, line 4 ¶		skipping to change at page 59, line 4 ¶
	<sedGrpKey>		<sedGrpKey>
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>SED_GRP_SSP2_1</name>		<name>SED_GRP_SSP2_1</name>
	<type>SedGrp</type>		<type>SedGrp</type>
	</sedGrpKey>		</sedGrpKey>
	<offeredTo>iana-en:111</offeredTo>		<offeredTo>iana-en:111</offeredTo>
	</sedGrpOfferKey>		</sedGrpOfferKey>
	</urn:spppAcceptRequest>		</urn:spppAcceptRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry confirms that the request has been processed successfully.		The Registry confirms that the request has been processed
	From this point forward, if SSP1 looks up a public identifier through		successfully. From this point forward, if SSP1 looks up a Public
	the query resolution server, where the public identifier is part of		Identifier through the query resolution server, where the Public
	the destination group by way of "SED_GRP_SSP2_1" session		Identifier is part of the Destination Group by way of
	establishment data association, SSP2 ingress SBE information will be		"SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will
	shared with SSP1.		be shared with SSP1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAcceptResponse		<ns3:spppAcceptResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12350</serverTransId>		<serverTransId>tx_12350</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAcceptResponse>		</ns3:spppAcceptResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.11. Add Egress Route		10.11. Add Egress Route
	SSP1 wants to prioritize all outbound traffic to the ingress route		SSP1 wants to prioritize all outbound traffic to the Ingress Route
	associated with the "SED_GRP_SSP2_1" SED Group record, through		associated with the "SED_GRP_SSP2_1" SED Group record, through
	"sbe1.ssp1.example.com".		"sbe1.ssp1.example.com".
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	skipping to change at page 60, line 34 ¶		skipping to change at page 61, line 4 ¶
	</urn1:regxRewriteRule>		</urn1:regxRewriteRule>
	<urn1:ingrSedGrp xsi:type="urn:ObjKeyType">		<urn1:ingrSedGrp xsi:type="urn:ObjKeyType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>SED_GRP_SSP2_1</name>		<name>SED_GRP_SSP2_1</name>
	<type>SedGrp</type>		<type>SedGrp</type>
	</urn1:ingrSedGrp>		</urn1:ingrSedGrp>
	</obj>		</obj>
	</urn:spppAddRequest>		</urn:spppAddRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Since peering has already been established, the request to add the		Since peering has already been established, the request to add the
	egress route has been successfully completed.		Egress Route has been successfully completed.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppAddResponse		<ns3:spppAddResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12345</serverTransId>		<serverTransId>tx_12345</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppAddResponse>		</ns3:spppAddResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.12. Remove Peering -- SED Group Offer Reject		10.12. Remove Peering -- SED Group Offer Reject
	SSP1 had earlier accepted to have visibility to SSP2 session		Earlier, SSP1 had accepted having visibility to SSP2 SED. SSP1 now
	establishment data. SSP1 now decides to no longer maintain this		decides to no longer maintain this visibility; hence, it rejects the
	visibility and hence rejects the SED Group Offer.		SED Group Offer.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppRejectRequest>		<urn:spppRejectRequest>
	<!--Optional:-->		<!--Optional:-->
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	skipping to change at page 62, line 4 ¶		skipping to change at page 62, line 4 ¶
	<sedGrpKey>		<sedGrpKey>
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>SED_GRP_SSP2_1</name>		<name>SED_GRP_SSP2_1</name>
	<type>SedGrp</type>		<type>SedGrp</type>
	</sedGrpKey>		</sedGrpKey>
	<offeredTo>iana-en:111</offeredTo>		<offeredTo>iana-en:111</offeredTo>
	</sedGrpOfferKey>		</sedGrpOfferKey>
	</urn:spppRejectRequest>		</urn:spppRejectRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry confirms that the request has been processed successfully.		The Registry confirms that the request has been processed
	From this point forward, if SSP1 looks up a public identifier through		successfully. From this point forward, if SSP1 looks up a Public
	the query resolution server, where the public identifier is part of		Identifier through the query resolution server, where the Public
	the destination group by way of "SED_GRP_SSP2_1" session		Identifier is part of the Destination Group by way of
	establishment data association, SSP2 ingress SBE information will not		"SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will
	be shared with SSP1 and hence SSP2 ingress SBE will not be returned		not be shared with SSP1; hence, an SSP2 ingress SBE will not be
	in the query response.		returned in the query response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppRejectResponse		<ns3:spppRejectResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<clientTransId>txn_1479</clientTransId>		<clientTransId>txn_1479</clientTransId>
	<serverTransId>tx_12350</serverTransId>		<serverTransId>tx_12350</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppRejectResponse>		</ns3:spppRejectResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.13. Get Destination Group		10.13. Get Destination Group
	SSP2 uses the 'spppGetRequest' operation to tally the last		SSP2 uses the spppGetRequest operation to tally the last provisioned
	provisioned record for destination group DEST_GRP_SSP2_1.		record for Destination Group DEST_GRP_SSP2_1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppGetRequest>		<urn:spppGetRequest>
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<objKey xsi:type="urn:ObjKeyType">		<objKey xsi:type="urn:ObjKeyType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>DEST_GRP_SSP2_1</name>		<name>DEST_GRP_SSP2_1</name>
	<type>DestGrp</type>		<type>DestGrp</type>
	</objKey>		</objKey>
	</urn:spppGetRequest>		</urn:spppGetRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The Registry completes the request successfully and returns a
	Registry completes the request successfully and returns a favorable		favorable response.
	response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<S:Body>		<S:Body>
	<ns3:spppGetResponse		<ns3:spppGetResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<overallResult>		<overallResult>
	skipping to change at page 64, line 29 ¶		skipping to change at page 65, line 4 ¶
	<objKey xsi:type="urn:PubIdKeyType">		<objKey xsi:type="urn:PubIdKeyType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<number>		<number>
	<urn1:value>+12025556666</urn1:value>		<urn1:value>+12025556666</urn1:value>
	<urn1:type>TN</urn1:type>		<urn1:type>TN</urn1:type>
	</number>		</number>
	</objKey>		</objKey>
	</urn:spppGetRequest>		</urn:spppGetRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The Registry completes the request successfully and returns a
	Registry completes the request successfully and returns a favorable		favorable response.
	response.
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<S:Body>		<S:Body>
	<ns3:spppGetResponse		<ns3:spppGetResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	skipping to change at page 65, line 34 ¶		skipping to change at page 66, line 7 ¶
	<ns2:cor>true</ns2:cor>		<ns2:cor>true</ns2:cor>
	<ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate>		<ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate>
	</ns2:corInfo>		</ns2:corInfo>
	</resultObj>		</resultObj>
	</ns3:spppGetResponse>		</ns3:spppGetResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.15. Get SED Group Request		10.15. Get SED Group Request
	SSP2 obtains the last provisioned record for the SED group		SSP2 obtains the last provisioned record for the SED Group
	SED_GRP_SSP2_1.		SED_GRP_SSP2_1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppGetRequest>		<urn:spppGetRequest>
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<objKey xsi:type="urn:ObjKeyType">		<objKey xsi:type="urn:ObjKeyType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>SED_GRP_SSP2_1</name>		<name>SED_GRP_SSP2_1</name>
	<type>SedGrp</type>		<type>SedGrp</type>
	</objKey>		</objKey>
	</urn:spppGetRequest>		</urn:spppGetRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The Registry completes the request successfully and returns a
	Registry completes the request successfully and returns a favorable		favorable response.
	response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<S:Body>		<S:Body>
	<ns3:spppGetResponse		<ns3:spppGetResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<overallResult>		<overallResult>
	skipping to change at page 67, line 48 ¶		skipping to change at page 68, line 7 ¶
	<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>		<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
	<ns2:isInSvc>true</ns2:isInSvc>		<ns2:isInSvc>true</ns2:isInSvc>
	<ns2:priority>10</ns2:priority>		<ns2:priority>10</ns2:priority>
	</resultObj>		</resultObj>
	</ns3:spppGetResponse>		</ns3:spppGetResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.16. Get SED Group Offers Request		10.16. Get SED Group Offers Request
	SSP2 fetches the last provisioned SED group offer to the <peeringOrg>		SSP2 fetches the last provisioned SED Group Offer to the <peeringOrg>
	SSP1.		SSP1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:getSedGrpOffersRequest>		<urn:getSedGrpOffersRequest>
	<offeredTo>iana-en:111</offeredTo>		<offeredTo>iana-en:111</offeredTo>
	</urn:getSedGrpOffersRequest>		</urn:getSedGrpOffersRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The Registry processes the request successfully and returns a
	Registry processes the request successfully and returns a favorable		favorable response.
	response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<S:Body>		<S:Body>
	<ns3:spppGetResponse		<ns3:spppGetResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<overallResult>		<overallResult>
	skipping to change at page 69, line 41 ¶		skipping to change at page 70, line 7 ¶
	<ns2:offerDateTime>		<ns2:offerDateTime>
	2006-05-04T18:13:51.0Z		2006-05-04T18:13:51.0Z
	</ns2:offerDateTime>		</ns2:offerDateTime>
	</resultObj>		</resultObj>
	</ns3:spppGetResponse>		</ns3:spppGetResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.17. Get Egress Route		10.17. Get Egress Route
	SSP1 wants to verify the last provisioned record for the egress route		SSP1 wants to verify the last provisioned record for the Egress Route
	called EGR_RTE_01.		called EGR_RTE_01.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppGetRequest>		<urn:spppGetRequest>
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<objKey xsi:type="urn:ObjKeyType">		<objKey xsi:type="urn:ObjKeyType">
	<rant>iana-en:111</rant>		<rant>iana-en:111</rant>
	<name>EGR_RTE_01</name>		<name>EGR_RTE_01</name>
	<type>EgrRte</type>		<type>EgrRte</type>
	</objKey>		</objKey>
	</urn:spppGetRequest>		</urn:spppGetRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
			The Registry completes the request successfully and returns a
	Registry completes the request successfully and returns a favorable		favorable response.
	response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<S:Body>		<S:Body>
	<ns3:spppGetResponse		<ns3:spppGetResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<overallResult>		<overallResult>
	skipping to change at page 71, line 39 ¶		skipping to change at page 72, line 7 ¶
	<name>SED_GRP_SSP2_1</name>		<name>SED_GRP_SSP2_1</name>
	<type>SedRec</type>		<type>SedRec</type>
	</ns2:ingrSedGrp>		</ns2:ingrSedGrp>
	</resultObj>		</resultObj>
	</ns3:spppGetResponse>		</ns3:spppGetResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.18. Delete Destination Group		10.18. Delete Destination Group
	SSP2 initiates a request to delete the destination group		SSP2 initiates a request to delete the Destination Group
	DEST_GRP_SSP2_1.		DEST_GRP_SSP2_1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppDelRequest>		<urn:spppDelRequest>
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<objKey xsi:type="urn:ObjKeyType">		<objKey xsi:type="urn:ObjKeyType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>DEST_GRP_SSP2_1</name>		<name>DEST_GRP_SSP2_1</name>
	<type>DestGrp</type>		<type>DestGrp</type>
	</objKey>		</objKey>
	</urn:spppDelRequest>		</urn:spppDelRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry completes the request successfully and returns a favorable		The Registry completes the request successfully and returns a
	response.		favorable response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppDelResponse		<ns3:spppDelResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<serverTransId>tx_12354</serverTransId>		<serverTransId>tx_12354</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppDelResponse>		</ns3:spppDelResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.19. Delete Public Identifier		10.19. Delete Public Identifier
	SSP2 chooses to de-activate the TN and remove it from the registry.		SSP2 chooses to deactivate the TN and remove it from the Registry.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppDelRequest>		<urn:spppDelRequest>
	skipping to change at page 73, line 26 ¶		skipping to change at page 73, line 30 ¶
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<number>		<number>
	<urn1:value>+12025556666</urn1:value>		<urn1:value>+12025556666</urn1:value>
	<urn1:type>TN</urn1:type>		<urn1:type>TN</urn1:type>
	</number>		</number>
	</objKey>		</objKey>
	</urn:spppDelRequest>		</urn:spppDelRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry completes the request successfully and returns a favorable		The Registry completes the request successfully and returns a
	response.		favorable response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppDelResponse		<ns3:spppDelResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<serverTransId>tx_12354</serverTransId>		<serverTransId>tx_12354</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppDelResponse>		</ns3:spppDelResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.20. Delete SED Group Request		10.20. Delete SED Group Request
	SSP2 removes the SED group called SED_GRP_SSP2_1.		SSP2 removes the SED Group called SED_GRP_SSP2_1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppDelRequest>		<urn:spppDelRequest>
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<objKey xsi:type="urn:ObjKeyType">		<objKey xsi:type="urn:ObjKeyType">
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>SED_GRP_SSP2_1</name>		<name>SED_GRP_SSP2_1</name>
	<type>SedGrp</type>		<type>SedGrp</type>
	</objKey>		</objKey>
	</urn:spppDelRequest>		</urn:spppDelRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry completes the request successfully and returns a favorable		The Registry completes the request successfully and returns a
	response.		favorable response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppDelResponse		<ns3:spppDelResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<serverTransId>tx_12354</serverTransId>		<serverTransId>tx_12354</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppDelResponse>		</ns3:spppDelResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.21. Delete SED Group Offers Request		10.21. Delete SED Group Offers Request
	SSP2 no longer wants to share SED group SED_GRP_SSP2_1 with SSP1.		SSP2 no longer wants to share SED Group SED_GRP_SSP2_1 with SSP1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppDelRequest>		<urn:spppDelRequest>
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	skipping to change at page 75, line 26 ¶		skipping to change at page 75, line 30 ¶
	<rant>iana-en:222</rant>		<rant>iana-en:222</rant>
	<name>SED_GRP_SSP2_1</name>		<name>SED_GRP_SSP2_1</name>
	<type>SedGrp</type>		<type>SedGrp</type>
	</sedGrpKey>		</sedGrpKey>
	<offeredTo>iana-en:111</offeredTo>		<offeredTo>iana-en:111</offeredTo>
	</objKey>		</objKey>
	</urn:spppDelRequest>		</urn:spppDelRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry completes the request successfully and returns a favorable		The Registry completes the request successfully and returns a
	response. Restoring this resource sharing will require a new SED		favorable response. Restoring this resource sharing will require a
	group offer from SSP2 to SSP1 followed by a successful SED group		new SED Group Offer from SSP2 to SSP1 followed by a successful SED
	accept request from SSP1.		Group Accept request from SSP1.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppDelResponse		<ns3:spppDelResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<serverTransId>tx_12354</serverTransId>		<serverTransId>tx_12354</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppDelResponse>		</ns3:spppDelResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.22. Delete Egress Route		10.22. Delete Egress Route
	SSP1 decides to remove the egress route with the label EGR_RTE_01.		SSP1 decides to remove the Egress Route with the label EGR_RTE_01.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppDelRequest>		<urn:spppDelRequest>
	<!--1 or more repetitions:-->		<!--1 or more repetitions:-->
	<objKey xsi:type="urn:ObjKeyType">		<objKey xsi:type="urn:ObjKeyType">
	<rant>iana-en:111</rant>		<rant>iana-en:111</rant>
	<name>EGR_RTE_01</name>		<name>EGR_RTE_01</name>
	<type>EgrRte</type>		<type>EgrRte</type>
	</objKey>		</objKey>
	</urn:spppDelRequest>		</urn:spppDelRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry completes the request successfully and returns a favorable		The Registry completes the request successfully and returns a
	response.		favorable response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppDelResponse		<ns3:spppDelResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<serverTransId>tx_12354</serverTransId>		<serverTransId>tx_12354</serverTransId>
	<overallResult>		<overallResult>
	skipping to change at page 77, line 9 ¶		skipping to change at page 77, line 9 ¶
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppDelResponse>		</ns3:spppDelResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.23. Batch Request		10.23. Batch Request
	Following is an example of how some of the operations mentioned in		Following is an example of how some of the operations mentioned in
	previous sections MAY be performed by an SPPF client as a batch in		previous sections MAY be performed by an SPPF client as a batch in
	one single SPP Protocol over SOAP request.		one single SPPP over SOAP request.
	In the sample request below SSP1 wants to accept a SED Group Offer		In the sample request below, SSP1 wants to accept a SED Group Offer
	from SSP3, add a Destination Group, add a NAPTR SED Record, add a SED		from SSP3, add a Destination Group, add a Naming Authority Pointer
	Group, add a SED Group Offer, delete a previously provisioned TN type		(NAPTR) SED Record, add a SED Group, add a SED Group Offer, delete a
	Public Identifier, delete a previously provisioned SED Group, and		previously provisioned TN type Public Identifier, delete a previously
	reject a SED Group Offer from SSP4.		provisioned SED Group, and reject a SED Group Offer from SSP4.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<soapenv:Envelope		<soapenv:Envelope
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"		xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"		xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
	xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:urn1="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<soapenv:Header/>		<soapenv:Header/>
	<soapenv:Body>		<soapenv:Body>
	<urn:spppBatchRequest>		<urn:spppBatchRequest>
	skipping to change at page 79, line 22 ¶		skipping to change at page 79, line 23 ¶
	<name>SED_SSP4_SBE1_Offered</name>		<name>SED_SSP4_SBE1_Offered</name>
	<type>SedGrp</type>		<type>SedGrp</type>
	</sedGrpKey>		</sedGrpKey>
	<offeredTo>iana-en:222</offeredTo>		<offeredTo>iana-en:222</offeredTo>
	</rejectSedGrpOffer>		</rejectSedGrpOffer>
	</urn:spppBatchRequest>		</urn:spppBatchRequest>
	</soapenv:Body>		</soapenv:Body>
	</soapenv:Envelope>		</soapenv:Envelope>
	Registry completes the request successfully and returns a favorable		The Registry completes the request successfully and returns a
	response.		favorable response.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<S:Envelope		<S:Envelope
	xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">		xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
	<S:Body>		<S:Body>
	<ns3:spppBatchResponse		<ns3:spppBatchResponse
	xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"		xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1"
	xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">		xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
	<serverTransId>tx_12354</serverTransId>		<serverTransId>tx_12354</serverTransId>
	<overallResult>		<overallResult>
	<code>1000</code>		<code>1000</code>
	<msg>Request Succeeded.</msg>		<msg>Request Succeeded.</msg>
	</overallResult>		</overallResult>
	</ns3:spppBatchResponse>		</ns3:spppBatchResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	11. Security Considerations		11. Security Considerations
	The base security considerations of SPPP outlined in Section 9 of		The base security considerations of SPPP outlined in Section 9 of
	[I-D.draft-ietf-drinks-spp-framework] also apply to SPP Protocol over		[RFC7877] also apply to SPPP over SOAP implementations.
	SOAP implementations. Additionally, the following must be		Additionally, the following must be considered:
	considered:
	SPP Protocol over SOAP is used to query and update session peering		SPPP over SOAP is used to query and update session peering data and
	data and addresses, so the ability to access this protocol should be		addresses, so the ability to access this protocol should be limited
	limited to users and systems that are authorized to query and update		to users and systems that are authorized to query and update this
	this data. Because this data is sent in both directions, it may not		data. Because this data is sent in both directions, it may not be
	be sufficient for just the client or user to be authenticated with		sufficient for just the client or user to be authenticated with the
	the server. The identity of the server should also be authenticated		server. The identity of the server should also be authenticated by
	by the client, which is often accomplished using the TLS certificate		the client, which is often accomplished using the TLS certificate
	exchange and validation described in [RFC2818].		exchange and validation described in [RFC2818].
	11.1. Vulnerabilities		11.1. Vulnerabilities
	Section 5 describes the use of HTTP and TLS as the underlying		Section 5 describes the use of HTTP and TLS as the underlying
	substrate protocols for SPP Protocol over SOAP. These underlying		substrate protocols for SPPP over SOAP. These underlying protocols
	protocols may have various vulnerabilities, and these may be		may have various vulnerabilities, and these may be inherited by SPPP
	inherited by SPP Protocol over SOAP. SPP Protocol over SOAP itself		over SOAP. SPPP over SOAP itself may have vulnerabilities because an
	may have vulnerabilities because an authorization model is not		authorization model is not explicitly specified in this document.
	explicitly specified in this document.
	During a TLS handshake, TLS servers can optionally request a		During a TLS handshake, TLS servers can optionally request a
	certificate from a TLS client; that option is not a requirement for		certificate from a TLS client; that option is not a requirement for
	this protocol. This presents a denial of service risk in which		this protocol. This presents a denial-of-service risk in which
	unauthenticated clients can consume server CPU resources by creating		unauthenticated clients can consume server CPU resources by creating
	TLS sessions. The risk is increased if the server supports client-		TLS sessions. The risk is increased if the server supports client-
	initiated renegotiation. This risk can be mitigated by disabling		initiated renegotiation. This risk can be mitigated by disabling
	client-initiated renegotiation on the server and by ensuring that		client-initiated renegotiation on the server and by ensuring that
	other means (such as firewall access control lists) are used to		other means (such as firewall access control lists) are used to
	restrict unauthenticated client access to servers.		restrict unauthenticated client access to servers.
	In conjunction with the above, it is important that SPP Protocol over		In conjunction with the above, it is important that SPPP over SOAP
	SOAP implementations implement an authorization model that considers		implementations implement an authorization model that considers the
	the source of each query or update request and determines whether it		source of each query or update request and determines whether it is
	is reasonable to authorize that source to perform that specific query		reasonable to authorize that source to perform that specific query or
	or update.		update.
	12. IANA Considerations		12. IANA Considerations
	This document uses URNs to describe XML Namespaces and XML Schemas.		This document uses URNs to describe XML Namespaces and XML Schemas.
	According to [RFC3688], IANA is requested to perform the following		According to [RFC3688], IANA has performed the following URN
	URN assignment:		assignment:
	URN: urn:ietf:params:xml:ns:sppf:soap:1		URN: urn:ietf:params:xml:ns:sppf:soap:1
	Registrant Contact: IESG		Registrant Contact: IESG
	XML: See Section 9 of [THISDOCUMENT]		XML: See Section 9 of [RFC7878]
	13. Acknowledgements
	This document is a result of various discussions held with the IETF
	DRINKS working group, specifically the protocol design team, with
	contributions from the following individuals, in alphabetical order:
	Alexander Mayrhofer, David Schwartz, Deborah A Guyton, Jean-Francois
	Mule Kenneth Cartwright, Lisa Dusseault, Manjul Maharishi, Mickael
	Marrache, Otmar Lendl, Peter Saint-Andre, Richard Shockey, Samuel
	Melloul, Scott Hollenbeck, Sumanth Channabasappa, Syed Ali, and Vikas
	Bhatia .
	14. References
	14.1. Normative References		13. References
	[I-D.draft-ietf-drinks-spp-framework]		13.1. Normative References
	Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
	"Session Peering Provisioning Framework", draft-ietf-
	drinks-spp-framework-08 (work in progress), July 2015.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",
	RFC 2617, DOI 10.17487/RFC2617, June 1999,
	<http://www.rfc-editor.org/info/rfc2617>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<http://www.rfc-editor.org/info/rfc3688>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<http://www.rfc-editor.org/info/rfc7231>.		<http://www.rfc-editor.org/info/rfc7231>.
			[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Authentication", RFC 7235,
			DOI 10.17487/RFC7235, June 2014,
			<http://www.rfc-editor.org/info/rfc7235>.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,		[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <http://www.rfc-editor.org/info/rfc7525>.		2015, <http://www.rfc-editor.org/info/rfc7525>.
			[RFC7877] Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
			"Session Peering Provisioning Framework (SPPF)", RFC 7877,
			DOI 10.17487/RFC7877, August 2016,
			<http://www.rfc-editor.org/info/rfc7877>.
	[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP		[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
	Version 1.2 Part 1: Messaging Framework", W3C		Version 1.2 Part 1: Messaging Framework (Second Edition)",
	Recommendation REC-SOAP12-part1-20030624, June 2002.		W3C Recommendation REC-SOAP12-part1-20070427, April 2007,
			<http://www.w3.org/TR/soap12-part1/>.
	14.2. Informative References		13.2. Informative References
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://www.rfc-editor.org/info/rfc2818>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<http://www.rfc-editor.org/info/rfc5321>.		<http://www.rfc-editor.org/info/rfc5321>.
	[W3C.REC-xml-20081126]		[W3C.REC-xml-20081126]
	Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,		Sperberg-McQueen, C., Yergeau, F., Bray, T., Maler, E.,
	and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth		and J. Paoli, "Extensible Markup Language (XML) 1.0 (Fifth
	Edition)", World Wide Web Consortium Recommendation REC-		Edition)", W3C Recommendation REC-xml-20081126, November
	xml-20081126, November 2008,		2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
	<http://www.w3.org/TR/2008/REC-xml-20081126>.
	[WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S.		[WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S.
	Weerawarana, "Web Services Description Language (WSDL)		Weerawarana, "Web Services Description Language (WSDL)
	1.1", W3C Note NOTE-wsdl-20010315, March 2001.		1.1", W3C Note NOTE-wsdl-20010315, March 2001,
			<http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.
			Acknowledgements
			This document is a result of various discussions held with the IETF
			DRINKS working group, specifically the protocol design team, with
			contributions from the following individuals, in alphabetical order:
			Syed Ali, Vikas Bhatia, Kenneth Cartwright, Sumanth Channabasappa,
			Lisa Dusseault, Deborah A. Guyton, Scott Hollenbeck, Otmar Lendl,
			Manjul Maharishi, Mickael Marrache, Alexander Mayrhofer, Samuel
			Melloul, Jean-Francois Mule, Peter Saint-Andre, David Schwartz, and
			Richard Shockey.
	Authors' Addresses		Authors' Addresses
	Kenneth Cartwright		Kenneth Cartwright
	TNS		TNS
	1939 Roland Clarke Place		10740 Parkridge Boulevard
	Reston, VA 20191		Reston, VA 20191
	USA		United States
	Email: kcartwright@tnsi.com		Email: kcartwright@tnsi.com
	Vikas Bhatia		Vikas Bhatia
	TNS		TNS
	1939 Roland Clarke Place		10740 Parkridge Boulevard
	Reston, VA 20191		Reston, VA 20191
	USA		United States
	Email: vbhatia@tnsi.com		Email: vbhatia@tnsi.com
	Jean-Francois Mule		Jean-Francois Mule
	CableLabs		Apple Inc.
	858 Coal Creek Circle		1 Infinite Loop
	Louisville, CO 80027		Cupertino, CA 95014
	USA		United States
	Email: jfm@cablelabs.com		Email: jfmule@apple.com
	Alexander Mayrhofer		Alexander Mayrhofer
	nic.at GmbH		nic.at GmbH
	Karlsplatz 1/2/9		Karlsplatz 1/2/9
	Wien A-1010		Wien A-1010
	Austria		Austria
	Email: alexander.mayrhofer@nic.at		Email: alexander.mayrhofer@nic.at
End of changes. 232 change blocks.
	661 lines changed or deleted		630 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/