< draft-ietf-drinks-spp-framework-09.txt		draft-ietf-drinks-spp-framework-10.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: April 25, 2015 S. Ali		Expires: September 26, 2015 S. Ali
	NeuStar		NeuStar
	D. Schwartz		D. Schwartz
	XConnect		XConnect
	October 22, 2014		March 25, 2015
	Session Peering Provisioning Framework (SPPF)		Session Peering Provisioning Framework (SPPF)
	draft-ietf-drinks-spp-framework-09		draft-ietf-drinks-spp-framework-10
	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 April 25, 2015.		This Internet-Draft will expire on September 26, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	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 10, line 50 ¶		skipping to change at page 10, line 50 ¶
	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 it is not approved for use in SPPF messages.		time, but it is not approved 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 MUST be documented in an RFC level document, and the		installations MUST be documented in an RFC, and the first such
	first such extension SHOULD define an IANA registry, holding a list		extension SHOULD define an IANA registry, holding a list of
	of documented extensions.		documented extensions.
	4. Transport Protocol Requirements		4. Transport Protocol Requirements
	This section provides requirements for transport protocols suitable		This section provides requirements for transport protocols suitable
	for SPPF. More specifically, this section specifies the services,		for SPPF. More specifically, this section specifies the services,
	features, and assumptions that SPPF framework delegates to the chosen		features, and assumptions that SPPF framework delegates to the chosen
	transport and envelope technologies.		transport and envelope technologies.
	4.1. Connection Oriented		4.1. Connection Oriented
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 33 ¶
	has the object's name, object's type and its Registrant's		has the object's name, object's type and its Registrant's
	organization ID as its attributes. The abstract type called		organization ID as its attributes. The abstract type called
	ObjKeyType is where this unique identity is housed. Any concrete		ObjKeyType is where this unique identity is housed. Any concrete
	representation of the ObjKeyType MUST contain the following:		representation of the ObjKeyType MUST contain the following:
	Object Name: The name of the object.		Object Name: The name of the object.
	Registrant Id: The unique organization ID that identifies the		Registrant Id: The unique organization ID that identifies the
	Registrant.		Registrant.
	Type: The value that represents the type of SPPF object that.		Type: The value that represents the type of SPPF object. This is
	This is required as different types of objects in SPPF, that		required as different types of objects in SPPF, that belong to the
	belong to the same Registrant, can have the same name.		same Registrant, can have the same name.
	The structure of abstract ObjKeyType is as follows:		The structure of abstract ObjKeyType is as follows:
	<complexType name="ObjKeyType" abstract="true">		<complexType name="ObjKeyType" abstract="true">
	<annotation>		<annotation>
	<documentation>		<documentation>
	---- Generic type that represents the		---- Generic type that represents the
	key for various objects in SPPF. ----		key for various objects in SPPF. ----
	</documentation>		</documentation>
	</annotation>		</annotation>
	skipping to change at page 15, line 41 ¶		skipping to change at page 15, line 41 ¶
	<annotation>		<annotation>
	<documentation>		<documentation>
	---- Generic type that represents		---- Generic type that represents
	the key for a object offer. ----		the key for a object offer. ----
	</documentation>		</documentation>
	</annotation>		</annotation>
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	A SED Group Offer object MUST use SedGrpOfferKeyType. Refer the		A SED Group Offer object MUST use SedGrpOfferKeyType. Refer to
	"Framework Data Model Objects" section of this document for		the "Framework Data Model Objects" section of this document for
	description of SED Group Offer object.		description of SED Group Offer object.
	o PubIdKeyType: This uniquely identifies a Public Identity object.		o PubIdKeyType: This uniquely identifies a Public Identity object.
	This key type extends from abstract ObjKeyType. Any concrete		This key type extends from abstract ObjKeyType. Any concrete
	definition of PubIdKeyType MUST contain the elements that identify		definition of PubIdKeyType MUST contain the elements that identify
	the value and type of Public Identity and also contain the		the value and type of Public Identity and also contain the
	organization ID of the Registrant that is the owner of the Public		organization ID of the Registrant that is the owner of the Public
	Identity object. A Public Identity object in SPPF is uniquely		Identity object. A Public Identity object in SPPF is uniquely
	identified by the Registrant's organization ID, the value of the		identified by the Registrant's organization ID, the value of the
	public identity, and the type of the public identity object.		public identity, and the type of the public identity object.
	skipping to change at page 18, line 51 ¶		skipping to change at page 18, line 51 ¶
	supported data model object (the nouns) and identifies the commands		supported data model object (the nouns) and identifies the commands
	(the verbs) that MUST be supported for each data model object.		(the verbs) that MUST be supported for each data model object.
	However, the specification of the data structures necessary to		However, the specification of the data structures necessary to
	support each command is delegated to an SPPF conforming transport		support each command is delegated to an SPPF conforming transport
	protocol specification.		protocol specification.
	6.1. Destination Group		6.1. Destination Group
	Destination Group represents a logical grouping of Public Identifiers		Destination Group represents a logical grouping of Public Identifiers
	with common session establishment information. The transport		with common session establishment information. The transport
	protocol MUST support the ability to Create, Modify, Get, and Delete		protocol MUST support the ability to Add, Get, and Delete Destination
	Destination Groups (refer the "Framework Operations" section of this		Groups (refer to the "Framework Operations" section of this document
	document for a generic description of various operations).		for a generic description of various operations).
	A Destination Group object MUST be uniquely identified by attributes		A Destination Group object MUST be uniquely identified by attributes
	as defined in the description of "ObjKeyType" in the section "Generic		as defined in the description of "ObjKeyType" in the section "Generic
	Object Key Type" of this document.		Object Key Type" of this document.
	The DestGrpType object structure is defined as follows:		The DestGrpType object structure is defined as follows:
	<complexType name="DestGrpType">		<complexType name="DestGrpType">
	<complexContent>		<complexContent>
	<extension base="sppfb:BasicObjType">		<extension base="sppfb:BasicObjType">
	skipping to change at page 19, line 46 ¶		skipping to change at page 19, line 46 ¶
	establishment data (SED). In many cases, a Public Identifier is		establishment data (SED). In many cases, a Public Identifier is
	attributed to the end user who has a retail relationship with the		attributed to the end user who has a retail relationship with the
	service provider or Registrant organization. SPPF supports the		service provider or Registrant organization. SPPF supports the
	notion of the carrier-of-record as defined in [RFC5067]. Therefore,		notion of the carrier-of-record as defined in [RFC5067]. Therefore,
	the Registrant under whom the Public Identity is being created can		the Registrant under whom the Public Identity is being created can
	optionally claim to be a carrier-of-record.		optionally claim to be a carrier-of-record.
	SPPF identifies three types of Public Identifiers: telephone numbers		SPPF identifies three types of Public Identifiers: telephone numbers
	(TN), routing numbers (RN), and URI. SPPF provides structures to		(TN), routing numbers (RN), and URI. SPPF provides structures to
	manage a single TN, a contiguous range of TNs, and a TN prefix. The		manage a single TN, a contiguous range of TNs, and a TN prefix. The
	transport protocol MUST support the ability to Create, Modify, Get,		transport protocol MUST support the ability to Add, Get, and Delete
	and Delete Public Identifiers (refer the "Framework Operations"		Public Identifiers (refer to the "Framework Operations" section of
	section of this document for a generic description of various		this document for a generic description of various operations).
	operations).
	A Public Identity object MUST be uniquely identified by attributes as		A Public Identity object MUST be uniquely identified by attributes as
	defined in the description of "PubIdKeyType" in the section		defined in the description of "PubIdKeyType" in the section
	Section 5.2.2.		Section 5.2.2.
	The abstract XML schema type definition PubIdType is a generalization		The abstract XML schema type definition PubIdType is a generalization
	for the concrete Public Identifier schema types. PubIdType element		for the concrete Public Identifier schema types. PubIdType element
	'dgName' represents the name of a destination group that a given		'dgName' represents the name of a destination group that a given
	Public Identifier may be a member of. Note that this element may be		Public Identifier may be a member of. Note that this element may be
	present multiple times so that a given Public Identifier may be a		present multiple times so that a given Public Identifier may be a
	skipping to change at page 25, line 9 ¶		skipping to change at page 25, line 9 ¶
	SED Group is a grouping of one or more Destination Group, the common		SED Group is a grouping of one or more Destination Group, the common
	SED Records, and the list of peer organizations with access to the		SED Records, and the list of peer organizations with access to the
	SED Records associated with a given SED Group. It is this indirect		SED Records associated with a given SED Group. It is this indirect
	linking of public identifiers to their Session Establishment Data		linking of public identifiers to their Session Establishment Data
	that significantly improves the scalability and manageability of the		that significantly improves the scalability and manageability of the
	peering data. Additions and changes to SED information are reduced		peering data. Additions and changes to SED information are reduced
	to a single operation on a SED Group or SED Record , rather than		to a single operation on a SED Group or SED Record , rather than
	millions of data updates to individual public identifier records that		millions of data updates to individual public identifier records that
	individually contain their peering data. The transport protocol MUST		individually contain their peering data. The transport protocol MUST
	support the ability to Create, Modify, Get, and Delete SED Groups		support the ability to Add, Get, and Delete SED Groups (refer to the
	(refer the "Framework Operations" section of this document for a		"Framework Operations" section of this document for a generic
	generic description of various operations).		description of various operations).
	A SED Group object MUST be uniquely identified by attributes as		A SED Group object MUST be uniquely identified by attributes as
	defined in the description of "ObjKeyType" in the section "Generic		defined in the description of "ObjKeyType" in the section "Generic
	Object Key Type" of this document.		Object Key Type" of this document.
	The SedGrpType object structure is defined as follows:		The SedGrpType object structure is defined as follows:
	<complexType name="SedGrpType">		<complexType name="SedGrpType">
	<complexContent>		<complexContent>
	<extension base="sppfb:BasicObjType">		<extension base="sppfb:BasicObjType">
	skipping to change at page 28, line 25 ¶		skipping to change at page 28, line 25 ¶
	6.4. SED Record		6.4. SED Record
	SED Group represents a combined grouping of SED Records that define		SED Group represents a combined grouping of SED Records that define
	session establishment information. However, SED Records need not be		session establishment information. However, SED Records need not be
	created to just serve a single SED Group. SED Records can be created		created to just serve a single SED Group. SED Records can be created
	and managed to serve multiple SED Groups. As a result, a change for		and managed to serve multiple SED Groups. As a result, a change for
	example to the properties of a network node used for multiple routes,		example to the properties of a network node used for multiple routes,
	would necessitate just a single update operation to change the		would necessitate just a single update operation to change the
	properties of that node. The change would then be reflected in all		properties of that node. The change would then be reflected in all
	the SED Groups whose SED record set contains a reference to that		the SED Groups whose SED record set contains a reference to that
	node. The transport protocol MUST support the ability to Create,		node. The transport protocol MUST support the ability to Add, Get,
	Modify, Get, and Delete SED Records (refer the "Framework Operations"		and Delete SED Records (refer to the "Framework Operations" section
	section of this document for a generic description of various		of this document for a generic description of various operations).
	operations).
	A SED Record object MUST be uniquely identified by attributes as		A SED Record object MUST be uniquely identified by attributes as
	defined in the description of "ObjKeyType" in the section "Generic		defined in the description of "ObjKeyType" in the section "Generic
	Object Key Type" of this document.		Object Key Type" of this document.
	The SedRecType object structure is defined as follows:		The SedRecType object structure is defined as follows:
	<complexType name="SedRecType" abstract="true">		<complexType name="SedRecType" abstract="true">
	<complexContent>		<complexContent>
	<extension base="sppfb:BasicObjType">		<extension base="sppfb:BasicObjType">
	skipping to change at page 32, line 47 ¶		skipping to change at page 32, line 47 ¶
	is controlled by the organization to which a SED Group object belongs		is controlled by the organization to which a SED Group object belongs
	(its Registrant), and the peer organization that submits resolution		(its Registrant), and the peer organization that submits resolution
	requests (a data recipient, also know as a peering organization).		requests (a data recipient, also know as a peering organization).
	The Registrant offers access to a SED Group by submitting a SED Group		The Registrant offers access to a SED Group by submitting a SED Group
	Offer. The data recipient can then accept or reject that offer. Not		Offer. The data recipient can then accept or reject that offer. Not
	until access to a SED Group has been offered and accepted will the		until access to a SED Group has been offered and accepted will the
	data recipient's organization ID be included in the peeringOrg list		data recipient's organization ID be included in the peeringOrg list
	in a SED Group object, and that SED Group's peering information		in a SED Group object, and that SED Group's peering information
	become a candidate for inclusion in the responses to the resolution		become a candidate for inclusion in the responses to the resolution
	requests submitted by that data recipient. The transport protocol		requests submitted by that data recipient. The transport protocol
	MUST support the ability to Create, Modify, Get, Delete, Accept and		MUST support the ability to Add, Get, Delete, Accept and Reject SED
	Reject SED Group Offers (refer the "Framework Operations" section of		Group Offers (refer to the "Framework Operations" section of this
	this document for a generic description of various operations).		document for a generic description of various operations).
	A SED Group Offer object MUST be uniquely identified by attributes as		A SED Group Offer object MUST be uniquely identified by attributes as
	defined in the description of "SedGrpOfferKeyType" in the section		defined in the description of "SedGrpOfferKeyType" in the section
	"Derived Object Key Types" of this document.		"Derived Object Key Types" of this document.
	The SedGrpOfferType object structure is defined as follows:		The SedGrpOfferType object structure is defined as follows:
	<complexType name="SedGrpOfferType">		<complexType name="SedGrpOfferType">
	<complexContent>		<complexContent>
	<extension base="sppfb:BasicObjType">		<extension base="sppfb:BasicObjType">
	skipping to change at page 34, line 36 ¶		skipping to change at page 34, line 36 ¶
	establishment data, to share one or more ingress routes and that the		establishment data, to share one or more ingress routes and that the
	originating SSP has accepted the offer. In order to add the egress		originating SSP has accepted the offer. In order to add the egress
	route to the Registry, the originating SSP uses a valid regular		route to the Registry, the originating SSP uses a valid regular
	expression to rewrite ingress route in order to include the egress		expression to rewrite ingress route in order to include the egress
	SBE information. Also, more than one egress route can be associated		SBE information. Also, more than one egress route can be associated
	with a given ingress route in support of fault-tolerant		with a given ingress route in support of fault-tolerant
	configurations. The supporting SPPF structure provides a way to		configurations. The supporting SPPF structure provides a way to
	include route precedence information to help manage traffic to more		include route precedence information to help manage traffic to more
	than one outbound egress SBE.		than one outbound egress SBE.
	The transport protocol MUST support the ability to Add, Modify, Get,		The transport protocol MUST support the ability to Add, Get, and
	and Delete Egress Routes (refer the "Framework Operations" section of		Delete Egress Routes (refer to the "Framework Operations" section of
	this document for a generic description of various operations). The		this document for a generic description of various operations). The
	EgrRteType object structure is defined as follows:		EgrRteType object structure is defined as follows:
	<complexType name="EgrRteType">		<complexType name="EgrRteType">
	<complexContent>		<complexContent>
	<extension base="sppfb:BasicObjType">		<extension base="sppfb:BasicObjType">
	<sequence>		<sequence>
	<element name="egrRteName" type="sppfb:ObjNameType"/>		<element name="egrRteName" type="sppfb:ObjNameType"/>
	<element name="pref" type="unsignedShort"/>		<element name="pref" type="unsignedShort"/>
	<element name="regxRewriteRule" type="sppfb:RegexParamType"/>		<element name="regxRewriteRule" type="sppfb:RegexParamType"/>
	skipping to change at page 36, line 27 ¶		skipping to change at page 36, line 27 ¶
	7.1. Add Operation		7.1. Add Operation
	Any conforming transport protocol specification MUST provide a		Any conforming transport protocol specification MUST provide a
	definition for the operation that adds one or more SPPF objects into		definition for the operation that adds one or more SPPF objects into
	the Registry. If the object, as identified by the request attributes		the Registry. If the object, as identified by the request attributes
	that form part of the object's key, does not exist, then the Registry		that form part of the object's key, does not exist, then the Registry
	MUST create the object. If the object does exist, then the Registry		MUST create the object. If the object does exist, then the Registry
	MUST replace the current properties of the object with the properties		MUST replace the current properties of the object with the properties
	passed in as part of the Add operation.		passed in as part of the Add operation.
			Note that this effectively allows to modify a pre-existing object.
	If the entity that issued the command is not authorized to perform		If the entity that issued the command is not authorized to perform
	this operation an appropriate error message MUST be returned from		this operation an appropriate error message MUST be returned from
	amongst the response messages defined in "Response Message Types"		amongst the response messages defined in "Response Message Types"
	section of the document.		section of the document.
	7.2. Delete Operation		7.2. Delete Operation
	Any conforming transport protocol specification MUST provide a		Any conforming transport protocol specification MUST provide a
	definition for the operation that deletes one or more SPPF objects		definition for the operation that deletes one or more SPPF objects
	from the Registry using the object's key.		from the Registry using the object's key.
End of changes. 15 change blocks.
	32 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/