< draft-ietf-drinks-spp-framework-11.txt		draft-ietf-drinks-spp-framework-12.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 S. Ali		Expires: February 13, 2016 S. Ali
	NeuStar		NeuStar
	D. Schwartz		D. Schwartz
	XConnect		XConnect
	July 22, 2015		August 12, 2015
	Session Peering Provisioning Framework (SPPF)		Session Peering Provisioning Framework (SPPF)
	draft-ietf-drinks-spp-framework-11		draft-ietf-drinks-spp-framework-12
	Abstract		Abstract
	This document specifies the data model and the overall structure for		This document specifies the data model and the overall structure for
	a framework to provision session establishment data into Session Data		a framework to provision session establishment data into Session Data
	Registries and SIP Service Provider data stores. The framework is		Registries and SIP Service Provider data stores. The framework is
	called the Session Peering Provisioning Framework (SPPF). The		called the Session Peering Provisioning Framework (SPPF). The
	provisioned data is typically used by network elements for session		provisioned data is typically used by network elements for session
	establishment.		establishment.
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 February 13, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 3, line 14		skipping to change at page 3, line 14
	8.2. Versioning and Character Encoding . . . . . . . . . . . . 39		8.2. Versioning and Character Encoding . . . . . . . . . . . . 39
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 40		9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	9.1. Confidentiality and Authentication . . . . . . . . . . . 40		9.1. Confidentiality and Authentication . . . . . . . . . . . 40
	9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40		9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40
	9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40		9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
	9.3.1. DoS Issues Inherited from Substrate Mechanism . . . . 41		9.3.1. DoS Issues Inherited from Substrate Mechanism . . . . 41
	9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41		9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41
	9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42		9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42
	9.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 42		9.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 42
	9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42		9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42
	9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43		9.7. Compromised or Malicious Intermediary . . . . . . . . . . 43
	10. Internationalization Considerations . . . . . . . . . . . . . 43		10. Internationalization Considerations . . . . . . . . . . . . . 43
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43		11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43
	11.2. Organization Identifier Namespace Registry . . . . . . . 44		11.2. Organization Identifier Namespace Registry . . . . . . . 44
	12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44		12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
	14.1. Normative References . . . . . . . . . . . . . . . . . . 53		14.1. Normative References . . . . . . . . . . . . . . . . . . 53
	14.2. Informative References . . . . . . . . . . . . . . . . . 54		14.2. Informative References . . . . . . . . . . . . . . . . . 54
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
	skipping to change at page 10, line 44		skipping to change at page 10, line 44
	Some request and response messages in SPPF include time value(s)		Some request and response messages in SPPF include time value(s)
	defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use		defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use
	of unqualified local time value is disallowed as it can lead to		of unqualified local time value is disallowed as it can lead to
	interoperability issues. The value of a time attribute MUST be		interoperability issues. The value of a time attribute MUST be
	expressed in Coordinated Universal Time (UTC) format without the		expressed in Coordinated Universal Time (UTC) format without the
	timezone digits.		timezone digits.
	"2010-05-30T09:30:10Z" is an example of an acceptable time value for		"2010-05-30T09:30:10Z" is an example of an acceptable time value for
	use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC		use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC
	time, but MUST NOT be used in SPPF messages.		time, but not acceptable for use in SPPF messages.
	3.3. Extensibility		3.3. Extensibility
	The framework contains various points of extensibility in form of the		The framework contains various points of extensibility in form of the
	"ext" elements. Extensions used beyond the scope of private SPPF		"ext" elements. Extensions used beyond the scope of private SPPF
	installations need to be documented in an RFC, and the first such		installations need to be documented in an RFC, and the first such
	extension is expected to define an IANA registry, holding a list of		extension is expected to define an IANA registry, holding a list of
	documented extensions.		documented extensions.
	4. Transport Substrate Protocol Requirements		4. Transport Substrate Protocol Requirements
	This section provides requirements for substrate protocols suitable		This section provides requirements for substrate protocols suitable
	as "transports" for SPPF. More specifically, this section specifies		to carry SPPF. More specifically, this section specifies the
	the services, features, and assumptions that SPPF framework delegates		services, features, and assumptions that SPPF framework delegates to
	to the chosen substrate and envelope technologies.		the chosen substrate and envelope technologies.
	4.1. Mandatory Substrate		4.1. Mandatory Substrate
	None of the existing transport protocols carried directly over IP,		None of the existing transport protocols carried directly over IP,
	appearing as "Protocol" in the IPv4 headers, of "Next Header" in the		appearing as "Protocol" in the IPv4 headers, or "Next Header" in the
	IPv6 headers, meet the requirements for a "transport" listed in this		IPv6 headers, meet the requirements listed in this section to carry
	section.		SPPF.
	Therefore, one choice of "transport" has been provided in the SPP		Therefore, one choice to carry SPPF has been provided in the SPP
	Protocol over SOAP document [I-D.ietf-drinks-spp-protocol-over-soap],		Protocol over SOAP document [I-D.ietf-drinks-spp-protocol-over-soap],
	using SOAP as the substrate. To encourage interoperability, the SPPF		using SOAP as the substrate. To encourage interoperability, the SPPF
	server MUST provide support for this protocol. With time, it is		server MUST provide support for this protocol. With time, it is
	possible that other choices may surface that agree with the		possible that other choices may surface that comply with with the
	requirements discussed above.		requirements discussed above.
	4.2. Connection Oriented		4.2. Connection Oriented
	The SPPF follows a model where a client establishes a connection to a		The SPPF follows a model where a client establishes a connection to a
	server in order to further exchange SPPF messages over such a point-		server in order to further exchange SPPF messages over such a point-
	to-point connection. A substrate protocol for SPPF will therefore be		to-point connection. A substrate protocol for SPPF will therefore be
	connection oriented.		connection oriented.
	4.3. Request and Response Model		4.3. Request and Response Model
	Provisioning operations in SPPF follow the request-response model,		Provisioning operations in SPPF follow the request-response model,
	where a client sends a request message to initiate a transaction and		where a client sends a request message to initiate a transaction and
	the server responds with a response. Multiple subsequent request-		the server responds with a response. Multiple subsequent request-
	response exchanges MAY be performed over a single persistent		response exchanges MAY be performed over a single persistent
	connection.		connection.
	Therefore, a substrate protocol for SPPF will follow the request-		Therefore, a substrate protocol for SPPF will follow the request-
	response model by ensuring a response to be sent to the request		response model by ensuring a response is sent to the request
	initiator.		initiator.
	4.4. Connection Lifetime		4.4. Connection Lifetime
	Some use cases involve provisioning a single request to a network		Some use cases involve provisioning a single request to a network
	element. Connections supporting such provisioning requests might be		element. Connections supporting such provisioning requests might be
	short-lived, and may be established only on demand, for the duration		short-lived, and may be established only on demand, for the duration
	of a few seconds. Other use cases involve either provisioning a		of a few seconds. Other use cases involve either provisioning a
	large dataset, or a constant stream of small updates, either of which		large dataset, or a constant stream of small updates, either of which
	would likely require long-lived connections, spanning multiple hours		would likely require long-lived connections, spanning multiple hours
	skipping to change at page 16, line 46		skipping to change at page 16, line 46
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	A Public Identity object MUST use attributes of PubIdKeyType for its		A Public Identity object MUST use attributes of PubIdKeyType for its
	unique identification . Refer to Section 6 for a description of		unique identification . Refer to Section 6 for a description of
	Public Identity object.		Public Identity object.
	5.3. Response Message Types		5.3. Response Message Types
	The following table contains the list of response types a "transport"		The following table contains the list of response types which MUST by
	definition for a substrate protocol MUST define. An SPPF server MUST		defined for a substrate protocol used to carry SPPF. An SPPF server
	implement all of the following at minimum.		MUST implement all of the following at minimum.
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| Response Type | Description |		| Response Type | Description |
	+---------------------+---------------------------------------------+		+---------------------+---------------------------------------------+
	| Request Succeeded | A given request succeeded. |		| Request Succeeded | A given request succeeded. |
	| | |		| | |
	| Request syntax | The syntax of a given request was found |		| Request syntax | The syntax of a given request was found |
	| invalid | invalid. |		| invalid | invalid. |
	| | |		| | |
	| Request too large | The count of entities in the request is |		| Request too large | The count of entities in the request is |
	skipping to change at page 39, line 28		skipping to change at page 39, line 28
	from amongst the response messages defined in the "Response Message		from amongst the response messages defined in the "Response Message
	Types" section of the document.		Types" section of the document.
	8. XML Considerations		8. XML Considerations
	XML serves as the encoding format for SPPF, allowing complex		XML serves as the encoding format for SPPF, allowing complex
	hierarchical data to be expressed in a text format that can be read,		hierarchical data to be expressed in a text format that can be read,
	saved, and manipulated with both traditional text tools and tools		saved, and manipulated with both traditional text tools and tools
	specific to XML.		specific to XML.
	XML is case sensitive. Unless stated otherwise, XML specifications		XML is case sensitive. Unless stated otherwise, the character casing
	and examples provided in this document MUST be interpreted in the		of XML specifications in this document MUST be preserved to develop a
	character case presented to develop a conforming implementation.		conforming specification.
	This section discusses a small number of XML-related considerations		This section discusses a small number of XML-related considerations
	pertaining to SPPF.		pertaining to SPPF.
	8.1. Namespaces		8.1. Namespaces
	All SPPF elements are defined in the namespaces in the IANA		All SPPF elements are defined in the namespaces in the IANA
	Considerations section and in the Formal Framework Specification		Considerations section and in the Formal Framework Specification
	section of this document.		section of this document.
	skipping to change at page 43, line 7		skipping to change at page 43, line 7
	Anti-replay protection ensures that a given SPPF object replayed at a		Anti-replay protection ensures that a given SPPF object replayed at a
	later time doesn't affect the integrity of the system. SPPF provides		later time doesn't affect the integrity of the system. SPPF provides
	at least one mechanism to fight against replay attacks. Use of the		at least one mechanism to fight against replay attacks. Use of the
	optional client transaction identifier allows the SPPF client to		optional client transaction identifier allows the SPPF client to
	correlate the request message with the response and to be sure that		correlate the request message with the response and to be sure that
	it is not a replay of a server response from earlier exchanges. Use		it is not a replay of a server response from earlier exchanges. Use
	of unique values for the client transaction identifier is highly		of unique values for the client transaction identifier is highly
	encouraged to avoid chance matches to a potential replay message.		encouraged to avoid chance matches to a potential replay message.
	9.7. Man in the Middle		9.7. Compromised or Malicious Intermediary
	The SPPF client or Registrar can be a separate entity acting on		The SPPF client or Registrar can be a separate entity acting on
	behalf of the Registrant in facilitating provisioning transactions to		behalf of the Registrant in facilitating provisioning transactions to
	the Registry. Therefore, even though the substrate layer provides		the Registry. Therefore, even though the substrate layer provides
	end-to-end protection for each specific SPPP connection between		end-to-end protection for each specific SPPP connection between
	client and server, data might be available in clear text before or		client and server, data might be available in clear text before or
	after it traverses a SPPP connection. Therefore, a man-in-the-middle		after it traverses a SPPP connection. Therefore, a man-in-the-middle
	attack by one of the actors is a possibility that could affect the		attack by one of the intermediaries is a possibility that could
	integrity of the data that belongs to the Registrant and/or expose		affect the integrity of the data that belongs to the Registrant and/
	peering data to unintended actors.		or expose peering data to unintended actors.
	10. Internationalization Considerations		10. Internationalization Considerations
	Character encodings to be used for SPPF elements are described in		Character encodings to be used for SPPF elements are described in
	Section 8.2. The use of time elements in the protocol is specified		Section 8.2. The use of time elements in the protocol is specified
	in Section 3.2. Where human-readable messages that are presented to		in Section 3.2. Where human-readable messages that are presented to
	an end user are used in the protocol, those messages SHOULD be tagged		an end user are used in the protocol, those messages SHOULD be tagged
	according to [RFC5646], and the substrate protocol MUST support a		according to [RFC5646], and the substrate protocol MUST support a
	respective mechanism to transmit such tags together with those human-		respective mechanism to transmit such tags together with those human-
	readable messages.		readable messages.
	skipping to change at page 53, line 12		skipping to change at page 53, line 12
	Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, Vikas		Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, Vikas
	Bhatia, and Jeremy Barkan.		Bhatia, and Jeremy Barkan.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.ietf-drinks-spp-protocol-over-soap]		[I-D.ietf-drinks-spp-protocol-over-soap]
	Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer,		Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer,
	"Session Peering Provisioning (SPP) Protocol over SOAP",		"Session Peering Provisioning (SPP) Protocol over SOAP",
	draft-ietf-drinks-spp-protocol-over-soap-07 (work in		draft-ietf-drinks-spp-protocol-over-soap-08 (work in
	progress), October 2014.		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,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and		[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
	Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,		Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
	January 1998, <http://www.rfc-editor.org/info/rfc2277>.		January 1998, <http://www.rfc-editor.org/info/rfc2277>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <http://www.rfc-editor.org/info/rfc3629>.		2003, <http://www.rfc-editor.org/info/rfc3629>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
End of changes. 17 change blocks.
	28 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

X-Generator: pyht 0.35