< draft-ietf-drinks-spp-protocol-over-soap-08.txt		draft-ietf-drinks-spp-protocol-over-soap-09.txt >
	DRINKS K. Cartwright		DRINKS K. Cartwright
	Internet-Draft V. Bhatia		Internet-Draft V. Bhatia
	Intended status: Standards Track TNS		Intended status: Standards Track TNS
	Expires: January 23, 2016 J-F. Mule		Expires: September 25, 2016 J-F. Mule
	CableLabs		CableLabs
	A. Mayrhofer		A. Mayrhofer
	enum.at GmbH		enum.at GmbH
	July 22, 2015		March 24, 2016
	Session Peering Provisioning (SPP) Protocol over SOAP		Session Peering Provisioning (SPP) Protocol over SOAP
	draft-ietf-drinks-spp-protocol-over-soap-08		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 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 Simple Object Access Protocol (SOAP) is currently widely
	used for messaging between elements of such provisioning systems,		used for messaging between elements of such provisioning systems,
	this document specifies the usage of SOAP (via HTTPS) as the		this document specifies the usage of SOAP (via HTTPS) as the
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 23, 2016.		This Internet-Draft will expire on September 25, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	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 SPP Protocol 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. SPP Protocol 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 Identity 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 . . . . . . . . 10		7.2. Operation Request and Response Structures . . . . . . . . 11
	7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11		7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11
	7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14		7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14
	7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17		7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17
	7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20		7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20
	7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23		7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23
	7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26		7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26
	7.2.7. Get SED Group Offers Operation Structure . . . . . . 27		7.2.7. Get SED Group Offers Operation Structure . . . . . . 27
	7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29		7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29
	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 . . . . . . . . . . . . . . . 31
	7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33		7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33
	8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33		8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33
	9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33		9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33
	10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 44		10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 45
	10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45		10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45
	10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47		10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47
	10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48		10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48
	10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49		10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49
	10.5. Add Public Identity -- Successful COR claim . . . . . . 51		10.5. Add Public Identifier -- Successful COR claim . . . . . 51
	10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53		10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53
	10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54		10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54
	10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55		10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55
	10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57		10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57
	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 . . . . . . . . . . . . . . . . . . . . 59
	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 Identity . . . . . . . . . . . . . . . . . . 64		10.14. Get Public Identifier . . . . . . . . . . . . . . . . . 64
	10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65		10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65
	10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67		10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67
	10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69		10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69
	10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71		10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71
	10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 72		10.19. Delete Public Identifier . . . . . . . . . . . . . . . . 72
	10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73		10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73
	10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74		10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74
	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 . . . . . . . . . . . . . . . . . . . 79
	11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80		11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
	14.1. Normative References . . . . . . . . . . . . . . . . . . 81		14.1. Normative References . . . . . . . . . . . . . . . . . . 81
	14.2. Informative References . . . . . . . . . . . . . . . . . 81		14.2. Informative References . . . . . . . . . . . . . . . . . 82
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
	1. Introduction		1. Introduction
	SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best		SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], is best
	supported by a transport and messaging infrastructure that is		supported by a transport and messaging infrastructure that is
	connection oriented, request-response oriented, easily secured,		connection oriented, request-response oriented, easily secured,
	supports propagation through firewalls in a standard fashion, and		supports propagation through firewalls in a standard fashion, and
	that is easily integrated into back-office systems. This is due to		that is easily integrated into back-office systems. This is due to
	the fact that the client side of SPPF is likely to be integrated with		the fact that the client side of SPPF is likely to be integrated with
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	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 SPP Protocol over SOAP. All success
	and error responses are specified in Section 7.3 of this document.		and 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.
	This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1		Implementations MUST use SOAP 1.2 [SOAPREF] or higher, and MUST
	[WSDLREF] or higher.		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
			may introduce interopability problems with implementations that use
			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 ("Substrate Protocol Requirements") of
	[I-D.draft-ietf-drinks-spp-framework].		[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
	skipping to change at page 7, line 14 ¶		skipping to change at page 7, line 16 ¶
	4. HTTP(s) Features and SPP Protocol over SOAP		4. HTTP(s) Features and SPP Protocol 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		connections is an HTTPS connection where the relatively time
	consuming SSL handshake has occurred.		consuming TLS handshake has occurred.
	Implementations compliant with this document MUST use HTTP 1.1		Implementations compliant with this document MUST use HTTP 1.1
	[RFC2616] 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 SPP Protocol over SOAP
	Clients and Servers MUST use HTTP Digest Authentication as defined in		Clients and Servers MUST use HTTP Digest Authentication as defined in
	[RFC2617].		[RFC2617].
	To achieve integrity and privacy, conforming SPP Protocol over SOAP		To achieve integrity and privacy, conforming SPP Protocol over SOAP
	Clients and Servers MUST support Transport Layer Security (TLS) as		Clients and Servers MUST support Transport Layer Security (TLS) as
	defined in [RFC5246] as the secure transport mechanism.		defined in [RFC5246] as the secure transport mechanism. Use of TLS
			MUST follow the recommendations contained in [RFC7525]
	6. Language Identification		6. Language Identification
	Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols		Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols
	to provide a mechanism to transmit language tags together with human-		to provide a mechanism to transmit language tags together with human-
	readable messages. When conforming SPP Protocol SOAP servers use		readable messages. When conforming SPP Protocol SOAP servers use
	such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126],		such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126],
	Section 2.12) MUST be used. Clients MAY use the HTTP "Accept-		Section 2.12) MUST be used. Clients MAY use the HTTP "Accept-
	Language" header field (see Section 14.4 of [RFC2616]) in order to		Language" header field (see Section 5.3.5 of [RFC7231]) in order to
	indicate their language preference.		indicate their language preference.
	7. SPP Protocol SOAP Data Structures		7. SPP Protocol SOAP Data Structures
	SPP Protocol over SOAP uses a set of XML based data structures for		SPP Protocol over SOAP uses a set of XML based data structures for
	all the supported operations and any parameters that those operations		all the supported operations and any parameters that those operations
	are applied to. As also mentioned earlier in this document, these		are applied to. As also mentioned earlier in this document, these
	XML structures are envelope-independent and substrate-independent.		XML structures are envelope-independent and substrate-independent.
	Refer the "Protocol Operations" (Section 8) of this document for a		Refer the "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.
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 20 ¶
	<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 Identity Object Key		7.1.2. Public Identifier Object Key
	Public Identity type objects can further be of various sub-types like		Public Identifier type objects can further be of various sub-types
	a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or a TN		like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or
	Range and cannot be cleanly identified with the attributes in the		a TN Range and cannot be cleanly identified with the attributes in
	generic ObjKeyType. The definition of PubIdKeyType is as below:		the 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 32, line 50 ¶		skipping to change at page 32, line 50 ¶
	+--------+--------------------------+-------------------------------+		+--------+--------------------------+-------------------------------+
	Table 1: Response Codes Numbering Scheme and Messages		Table 1: Response Codes Numbering Scheme and Messages
	Response message for response code 2001 is "parameterized" with the		Response message for response code 2001 is "parameterized" with the
	following parameter: "[Maximum requests supported]". When 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 could 2000 SHOULD be used when the XML Schema validation of
			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 [I-D.draft-ietf-drinks-spp-framework].
	skipping to change at page 51, line 21 ¶		skipping to change at page 51, line 21 ¶
	<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 Identity -- Successful COR claim		10.5. Add Public Identifier -- Successful COR claim
	SSP2 activates a TN public identity 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 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>
	skipping to change at page 59, line 5 ¶		skipping to change at page 59, line 5 ¶
	<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.		Registry confirms that the request has been processed successfully.
	From this point forward, if SSP1 looks up a public identity through		From this point forward, if SSP1 looks up a public identifier through
	the query resolution server, where the public identity is part of the		the query resolution server, where the public identifier is part of
	destination group by way of "SED_GRP_SSP2_1" session establishment		the destination group by way of "SED_GRP_SSP2_1" session
	data association, SSP2 ingress SBE information will be shared with		establishment data association, SSP2 ingress SBE information will be
	SSP1.		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>
	skipping to change at page 62, line 5 ¶		skipping to change at page 62, line 5 ¶
	<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.		Registry confirms that the request has been processed successfully.
	From this point forward, if SSP1 looks up a public identity through		From this point forward, if SSP1 looks up a public identifier through
	the query resolution server, where the public identity is part of the		the query resolution server, where the public identifier is part of
	destination group by way of "SED_GRP_SSP2_1" session establishment		the destination group by way of "SED_GRP_SSP2_1" session
	data association, SSP2 ingress SBE information will not be shared		establishment data association, SSP2 ingress SBE information will not
	with SSP1 and hence SSP2 ingress SBE will not be returned in the		be shared with SSP1 and hence SSP2 ingress SBE will not be returned
	query response.		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>
	skipping to change at page 64, line 5 ¶		skipping to change at page 64, line 5 ¶
	<resultObj xsi:type="ns2:DestGrpType">		<resultObj xsi:type="ns2:DestGrpType">
	<ns2:rant>iana-en:222</ns2:rant>		<ns2:rant>iana-en:222</ns2:rant>
	<ns2:rar>iana-en:223</ns2:rar>		<ns2:rar>iana-en:223</ns2:rar>
	<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>		<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate>
	<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>		<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
	</resultObj>		</resultObj>
	</ns3:spppGetResponse>		</ns3:spppGetResponse>
	</S:Body>		</S:Body>
	</S:Envelope>		</S:Envelope>
	10.14. Get Public Identity		10.14. Get Public Identifier
	SSP2 obtains the last provisioned record associated with a given TN.		SSP2 obtains the last provisioned record associated with a given TN.
	<?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 72, line 42 ¶		skipping to change at page 72, line 42 ¶
	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 Identity		10.19. Delete Public Identifier
	SSP2 chooses to de-activate the TN and remove it from the registry.		SSP2 chooses to de-activate the TN and remove it from the registry.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<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 79, line 43 ¶		skipping to change at page 79, line 43 ¶
	<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
			[I-D.draft-ietf-drinks-spp-framework] also apply to SPP Protocol over
			SOAP implementations. Additionally, the following must be
			considered:
	SPP Protocol over SOAP is used to query and update session peering		SPP Protocol over SOAP is used to query and update session peering
	data and addresses, so the ability to access this protocol should be		data and addresses, so the ability to access this protocol should be
	limited to users and systems that are authorized to query and update		limited to users and systems that are authorized to query and update
	this data. Because this data is sent in both directions, it may not		this data. Because this data is sent in both directions, it may not
	be sufficient for just the client or user to be authenticated with		be sufficient for just the client or user to be authenticated with
	the server. The identity of the server should also be authenticated		the server. The identity of the server should also be authenticated
	by the client, which is often accomplished using the TLS certificate		by 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
	skipping to change at page 81, line 17 ¶		skipping to change at page 81, line 26 ¶
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.draft-ietf-drinks-spp-framework]		[I-D.draft-ietf-drinks-spp-framework]
	Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,		Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz,
	"Session Peering Provisioning Framework", draft-ietf-		"Session Peering Provisioning Framework", draft-ietf-
	drinks-spp-framework-08 (work in progress), July 2015.		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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		<http://www.rfc-editor.org/info/rfc2119>.
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, DOI 10.17487/RFC2617, June 1999,		RFC 2617, DOI 10.17487/RFC2617, June 1999,
	<http://www.rfc-editor.org/info/rfc2617>.		<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
			Protocol (HTTP/1.1): Message Syntax and Routing",
			RFC 7230, DOI 10.17487/RFC7230, June 2014,
			<http://www.rfc-editor.org/info/rfc7230>.
			[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
			Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
			DOI 10.17487/RFC7231, June 2014,
			<http://www.rfc-editor.org/info/rfc7231>.
			[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
			2015, <http://www.rfc-editor.org/info/rfc7525>.
	[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", W3C
	Recommendation REC-SOAP12-part1-20030624, June 2002.		Recommendation REC-SOAP12-part1-20030624, June 2002.
	14.2. Informative References		14.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>.
End of changes. 30 change blocks.
	44 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/