draft-ietf-drinks-usecases-requirements-00.txt		draft-ietf-drinks-usecases-requirements-01.txt
	DRINKS S. Channabasappa, Ed.		DRINKS S. Channabasappa, Ed.
	Internet-Draft CableLabs		Internet-Draft CableLabs
	Intended status: Informational May 27, 2009		Intended status: Informational March 8, 2010
	Expires: November 28, 2009		Expires: September 9, 2010
	DRINKS Use cases and Protocol Requirements		DRINKS Use cases and Protocol Requirements
	draft-ietf-drinks-usecases-requirements-00		draft-ietf-drinks-usecases-requirements-01
			Abstract
			This document captures the use cases and associated requirements for
			interfaces to provision session establishment data into SIP Service
			Provider components that aid with session routing. Specifically, the
			current version of this document focuses on the provisioning of one
			such element, termed the registry.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32		skipping to change at page 1, line 40
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 28, 2009.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document captures the use cases and associated requirements for		described in the BSD License.
	interfaces to provision session establishment data into SIP Service
	Provider components that aid with session routing. Specifically, the
	current version of this document focuses on the provisioning of one
	such element, termed the registry.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10		3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10
	3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 10		3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 10
	3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10		3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10
	3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 14		3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 15
	3.2. Distribution of data into local data repositories . . . . 17		3.2. Distribution of data into local data repositories . . . . 18
	3.3. Miscellaneous Use Cases . . . . . . . . . . . . . . . . . 17		4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	3.3.1. Indirect Peering to Selected Destinations . . . . . . 17		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	3.3.2. TBD: RN Destinations . . . . . . . . . . . . . . . . . 17		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		7.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		7.2. Informative References . . . . . . . . . . . . . . . . . . 22
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	7.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Terminology		1. 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].
	This document reuses terms from [RFC3261] (e.g., SIP) and [RFC5486]		This document reuses terms from [RFC3261] (e.g., SIP) and [RFC5486]
	(e.g., LUF, LRF). In addition, this document specifies the following		(e.g., LUF, LRF). In addition, this document specifies the following
	additional terms.		additional terms.
	skipping to change at page 7, line 11		skipping to change at page 7, line 11
	o Local Data Repositories are the data store component of an		o Local Data Repositories are the data store component of an
	addressing server that provides resolution responses.		addressing server that provides resolution responses.
	o Registries are responsible for distributing SED and related		o Registries are responsible for distributing SED and related
	information to the local data repositories.		information to the local data repositories.
	In addition, this document proposes the following aggregation groups		In addition, this document proposes the following aggregation groups
	with regards to SED (certain use cases also illustrate these groups):		with regards to SED (certain use cases also illustrate these groups):
	o Aggregation of public Identifiers: The initial input "key" to a		o Aggregation of public Identifiers: The initial input 'key' to a
	SED lookup is a public identifier. Since many public identifiers		SED lookup is a public identifier. Since many public identifiers
	will share similar (or identical) destinations, and hence return		will share similar (or identical) destinations, and hence return
	similar (or identical) SED, provisioning the same set of SED for		similar (or identical) SED, provisioning the same set of SED for
	millions of public identifiers is inefficient, especially in cases		millions of public identifiers is inefficient, especially in cases
	where the SED needs to be modified. Therefore, an aggregation		where the SED needs to be modified. Therefore, an aggregation
	mechanism to "group" public identifiers is proposed. This		mechanism to 'group' public identifiers is proposed. This
	aggregation is called a "destination group".		aggregation is called a 'destination group'.
	o Aggregation of SSPs: It is expected that SSPs may want to expose		o Aggregation of SSPs: It is expected that SSPs may want to expose
	different sets of SED, depending on the receiving SSP. This		different sets of SED, depending on the receiving SSP. This
	exposure may not always be unique, in which case an aggregation		exposure may not always be unique, in which case an aggregation
	makes it efficient. Such an aggregation is proposed, and termed		makes it efficient. Such an aggregation is proposed, and termed
	"Data Receipient Group".		'Data Receipient Group'.
	o Aggregation of SED records: Finally, it is anticipated that a		o Aggregation of SED records: Finally, it is anticipated that a
	complete set of routing data will consist of more than just one		complete set of routing data will consist of more than just one
	SED record. To be able to create and use the same set of SED		SED record. To be able to create and use the same set of SED
	records multiple times (without creating duplicates) an		records multiple times (without creating duplicates) an
	aggregation mechanism at this level is proposed, and called		aggregation mechanism at this level is proposed, and called
	"routing group".		'Routing Group'.
	The above aggregations are illustrated in Figure 3.		The above aggregations are illustrated in Figure 3.
	+---------+ +--------------+		+---------+ +--------------+
	| Data | |DATA RECIPIENT|		| Data | 0..n 1 |DATA RECIPIENT|
	|Recipient|----------->| GROUP |		|Recipient|------------| GROUP |
	+---------+ +------.-------+		+---------+ +------.-------+
	^		0..n |
	|		|
	|		|
			1 |
	+--------------+ +---------+		+--------------+ +---------+
	| ROUTING | ------------->| SED |		| ROUTING | ------------->| SED |
	| GROUP | | Record |		| GROUP | 1 0..n | Record |
	+--------------+ +---------+		+--------------+ +---------+
	^ ^		|0..n |0..n
	| |		| |
	| |		| |
	+--------------+ |		| |
	----->| DESTINATION |<----- |		| 1 |
	| | GROUP | | |		1..n +--------------+ 0..n |
	| +--------------+ | |		---------| DESTINATION |--------- |
	| ^ | |		| | GROUP | | |
	| | | |		| +--------------+ | |
	| | | |		| | | |
	| | | |		| 1..n| | |
	+---------+ +---------+ +---------+ |		| | | |
	| RN | | TN | | Public |-------		| | | |
	| | | Range | |Identity |		1 | 1 | | 1 |
	+---------+ +---------+ +---------+		+---------+ +---------+ +---------+ |
			| RN | | TN | | Public |-----
			| | | Range | |Identity | 1
			+---------+ +---------+ +---------+
	Figure 3: Data Model Diagram		Figure 3: Data Model Diagram
	A description of the relationships follows:		Additional clarifications follow:
	- An RN is associated with one or more Destination Groups
	- A TN Range object is associated with one or more Destination Group
	- A Public Identity is associated with zero or more Destination
	Group
	- A Public Identity is associated with zero or more SED Records
	- A Destination Group is associated with zero or more Routing
	Groups.
	- A Routing Group is associated with zero or more SED Records;		- A routing group is associated with zero or more SED Records;
	NAPTRs and other SED Record Types associated with Routes are not		NAPTRs and other SED record types associated with routes are not
	User or TN specific. For example the user portion of a NAPTR		user or TN-specific. For example the user portion of a NAPTR
	regex will be "\1".		regular expression will be "\1".
	- An Routing Group is associated with zero or more peering		- A routing group is associated with zero or more peering
	organizations to control visibility/access privs to that Routing		organizations to control visibility or access privileges to that
	Group and the Destination Groups they expose.		routing group and the destination groups they expose.
	- A Data Recipient Group is associated with (contains) zero or more		- A data recipient group contains zero or more data recipients to
	Data Recipients to facilitate the allocation of access privileges		facilitate the allocation of access privileges to routing groups.
	to Routing Groups.
	3. Use Cases and Requirements		3. Use Cases and Requirements
	This section presents the use cases and associated requirements.		This section presents the use cases and associated requirements.
	3.1. Registry Provisioning		3.1. Registry Provisioning
	Registry is the authoritative source for session establishment data		Registry is the authoritative source for session establishment data
	(SED). The registry needs to be provisioned with this data to		(SED). The registry needs to be provisioned with this data to
	perform its function. This data includes: destination groups,		perform its function. This data includes: destination groups,
	routing groups and data recipient groups. It can also include RNs		routing groups and data recipient groups. It can also include RNs
	and TN Ranges. The following sub-sections illustrate the use cases		and TN Ranges. The following sub-sections illustrate the use cases
	and the requirements, respectively.		and the requirements, respectively.
	3.1.1. Use Cases		3.1.1. Use Cases
	USE CASE #1 Near-real-time provisioning: The registry is		The use cases are divided into the following categories - process,
	provisioned with data that is not accompanied by an		routing, identity, administration, and number portability.
	effective date or time. In such cases, the registry
	will validate the data and make it effective in near
	real-time.
	USE CASE #2 Non-real-time provisioning: The registry is provisioned		3.1.1.1. Category: Process
	via an asynchronous provisioning process. For
	instance, an SSP has commissioned a new registry and
	wishes to download a very large number of telephone
	numbers. Rather than stream individual entities, one
	at a time, the SSP's back-office system prefers to
	perform the operation as a set of one or more batches
	(e.g., via an external data file), instead of the near-
	real-time provisioning interface.
	USE CASE #3 Deferred provisioning: The registry is provisioned with		UC PROCESS #1 Near-real-time provisioning: The registry is
	data that is accompanied by an effective date and time.		provisioned with data that is not accompanied by an
	In scenarios such as this, the registry will validate		effective date or time. In such cases, the registry
	the data and wait until the effective date and time to		will validate the data and make it effective in near
	make it effective. TBD: What happens if near-real time		real-time.
	data overrides data parked for later incorporation?
	USE CASE #4 Intra-network SED: SSP wishes to provision their intra-		UC PROCESS #2 Deferred provisioning with effective date/time: The
	network Session Establishment Data (SED) such that it		registry is provisioned with data that is accompanied
	enables current and future network services to identify		by an effective date and time. In scenarios such as
	and route real-time sessions. For example, in the case		this, the registry will validate the data and wait
	of VoIP calls it allows one SoftSwitch (calling) to		until the effective date and time to make it
	discover another (called). The SSP provisions IP		effective. TBD: What happens if near-real time data
	addressing information pertaining to each SoftSwitch,		overrides data parked for later incorporation?
	which is provisioned to the registry but only
	distributed to a specific local data repository. This
	SED may differ from the SED that is distributed to
	other local data repositories.
	USE CASE #5 Destination Groups: An SSP may wish to control the flow		UC PROCESS #3 Batch provisioning: The registry is provisioned via an
	of traffic into their network (ingress) based on		asynchronous provisioning process. For instance, an
	groupings of Public Identities. Associating each group		SSP has commissioned a new registry and wishes to
	of Public Identities with a specific set of ingress		download a very large number of telephone numbers.
	SBEs or points-of-interconnect. The SSP, for example,		Rather than stream individual entities, one at a time,
	sub-divides the country into four regions: North-East,		the SSP's back-office system prefers to perform the
	South-East, Mid-West, and West-Coast. For each region		operation as a set of one or more batches (e.g., via
	they establish points-of-interconnect with peers and		an external data file), instead of the near-real-time
	provision the associated SED hostnames or IP addresses		provisioning interface.
	of the SBEs used for ingress traffic. Against each
	region they provision the served Public Identities into
	groups- termed Destination Groups - and associate those
	destination groups with the appropriate points of
	ingres.
	USE CASE #6 Public Identity is taken out of service: A public		3.1.1.2. Category: Routing
	identity (or a TN range) is taken out of service
	because it is no longer valid. The Registry receives a
	delete operation and removes the public identity from
	its database. This can also trigger delete operations
	to keep the local data repositories up-to-date.
	USE CASE #7 Assigning a set of public identities to a different		UC ROUTING #1 Intra-network SED: SSP wishes to provision their
	Destination Group: A set of public identities are		intra-network Session Establishment Data (SED) such
	assigned a different Destination Group which		that it enables current and future network services to
	effectively changes their routing information. This		identify and route real-time sessions. For example,
	may be due to a network re-arrangement, a Signaling		in the case of VoIP calls it allows one SoftSwitch
	path Border Element being split into two, or a need to		(calling) to discover another (called). The SSP
	do maintenance, two carriers merging, or other		provisions IP addressing information pertaining to
	considerations. This scenario can also include an		each SoftSwitch, which is provisioned to the registry
	effective date and time.		but only distributed to a specific local data
			repository. This SED may differ from the SED that is
			distributed to other local data repositories.
	USE CASE #8 Moving an SSP from one Data Recipient Group to another:		UC ROUTING #2 Support for destination groups: An SSP may wish to
	An SSP would like to re-assign the Destination Groups		control the flow of traffic into their network
	it shares with a peer and move the peer SSP from one		(ingress) based on groupings of Public Identities.
	Data Recipient Group to another. This results in the		Associating each group of Public Identities with a
	moved peer seeing a new and different set of routing		specific set of ingress SBEs or points-of-
	data.		interconnect. The SSP, for example, sub-divides the
			country into four regions: North-East, South-East,
			Mid-West, and West-Coast. For each region they
			establish points-of-interconnect with peers and
			provision the associated SED hostnames or IP addresses
			of the SBEs used for ingress traffic. Against each
			region they provision the served Public Identities
			into groups- termed Destination Groups - and associate
			those destination groups with the appropriate points
			of ingres.
	USE CASE #9 Inter-network SED (Direct and Selective Peering): In		UC ROUTING #3 Modifying destination groups: A set of public
	this case the SSP is the actual carrier-of-record; the		identities are assigned a different Destination Group
	entity serving the end-user. The SSP wishes to		which effectively changes their routing information.
	communicate different SED data to some of its peers		This may be due to a network re-arrangement, a
	that wish to route to its destinations. So the SSP has		Signaling path Border Element being split into two, or
	implemented direct points-of-interconnect with each		a need to do maintenance, two carriers merging, or
	peer and therefore would like address-resolution to		other considerations. This scenario can also include
	result in different answers depending on which peer is		an effective date and time.
	asking.
	USE CASE #10 Separation of Responsibility: An SSP's operational		UC ROUTING #4 Indirect Peering to Selected Destinations: The SSP
	practices can seperate the responsibility of		transit provider wishes to provide transit peering
	provisioning the routing information, and the		points for a set of destinations. But that set of
	associated identities, to different entities. For		destinations does not align with the destination
	example, a network engineer can establish a physical		groups that already exist. The SSP wishes to
	interconnect with a peering SSP's network and provision		establish its own destination groups for the
	the associated domain name, host, and IP addressing		destinations that it provides transit to. (Editor's
	information. Separately, for each new service		note: This use case needs more work.)
	subscription, the SSP's back office system provisions
	the associated public identities.
	USE CASE #11 Global TN Destinations: The SSP wishes to add or remove		UC ROUTING #5 Inter-network SED (direct and selective peering): In
	one or multiple fully qualified TN destinations in a		this case the SSP is the actual carrier-of-record; the
	single provisioning request.		entity serving the end-user. The SSP wishes to
			communicate different SED data to some of its peers
			that wish to route to its destinations. So the SSP
			has implemented direct points-of-interconnect with
			each peer and therefore would like address-resolution
			to result in different answers depending on which peer
			is asking.
	USE CASE #12 TN Range Destinations: The SSP wishes to add or remove		UC ROUTING #6 Selecting egress points: An SSP has a peering
	one or multiple TN Range destinations in a single		relationship with a peer, and when sending messages to
	provisioning request. TN Ranges support number ranges		that peer's point of interconnection, the originating
	that need not be 'blocks'. In other words the TN range		SSP wishes to use one or more points of egress. These
	start can be any number and the TN range end can be any		points of egress may vary for an given peer. This
	number that is greater than the TN range start.		capability is supported by allowing an originating SSP
			to provision SED for identities terminating to other
			SSPs where the originating SSP is itself the data
			recipient. The provisioning SSP may make use of
			multiple data recipient identities if it requires
			different sets of egress points be used for calls
			originating from different parts of its network.
			Routing from egress points to ingress points of the
			terminating SSP may be accomplished by static routing
			from the egress points or by the egress points using
			data provisioned to the Registry by the terminating
			SSP.
	USE CASE #13 Non-TN Destinations: An SSP chooses to peer their		UC ROUTING #7 SSP prefers to provision LUF and LRF data in the
	messaging service with another SSPs picture/video mail		registry: SSP prefers the registry to have access to
	service. Allowing a user to send and receive pictures		LUF and LRF information. In this case the originating
	and/or video messages to a mobile user's handset, for		SSP does not have to rely on mechanisms such as DNS
	example. The important aspect of this use case is that		(e.g., [RFC3263]) for routing information since a
	it goes beyond simply mapping TNs to IP addresses/		registry query will return the terminating SBE.
	hostnames that describe points-of-interconnect between
	peering network SSP's. Rather, for each user the SSP
	provisions the subscriber's email address (i.e.
	jane.doe@example.com). This mapping allows the mobile
	multimedia messaging service center (MMSC) to use the
	subscriber email address as the lookup key and route
	messages accordingly.
	USE CASE #14 Tier 2 Name Server: An SSP maintains a Tier 2 name		UC ROUTING #8 Provision an authoritative name server (not actual
	server that contains the NAPTR records that constitute		route): An SSP maintains a Tier 2 name server that
	the terminal step in the LUF. The SSP needs to		contains the NAPTR records that constitute the
	provision an registry to direct queries for the SSPs		terminal step in the LUF. The SSP needs to provision
	numbers to the Tier 2. Usually queries to the registry		an registry to direct queries for the SSPs numbers to
	should return NS records, but, in cases where the Tier		the Tier 2. Usually queries to the registry should
	2 uses a different domain suffix from that used in the		return NS records, but, in cases where the Tier 2 uses
	registry, CNAME and NS records may be employed instead.		a different domain suffix from that used in the
			registry, CNAME and NS records may be employed
			instead.
	USE CASE #15 Peering Offer/Acceptance: An SSP offers to allow		3.1.1.3. Category: Identity
	terminations from another SSP by adding that SSP to a
	Data Recipient Group it controls. This causes
	notification of the offered SSP. An SSP receiving a
	peering offer should be able to accept or decline the
	offer. If the offer is rejected the Registry should
	not provision corresponding SED to the rejecting SSP.
	It is expected that this capability will apply mainly
	in the transit case where non-authoritative parties (in
	the sense of not being the terminating SSP for an
	identity) wish to offer the ability to reach the
	identity and originating SSPs may wish to restrict the
	routes that are provisioned to their local data
	repositories.
	USE CASE #16 Points of Egress: An SSP has a peering relationship		UC ID #1 Deletion of public identity: A public identity (or a TN
	with a peer, and when sending messages to that peer's		range) is taken out of service because it is no longer
	point of interconnection, the originating SSP wishes to		valid. The Registry receives a delete operation and
	use one or more points of egress. These points of		removes the public identity from its database. This can
	egress may vary for an given peer. This capability is		also trigger delete operations to keep the local data
	supported by allowing an originating SSP to provision		repositories up-to-date.
	SED for identities terminating to other SSPs where the
	originating SSP is itself the data recipient. The		UC ID #2 Global TN destinations: The SSP wishes to add or remove one
	provisioning SSP may make use of multiple data		or multiple fully qualified TN destinations in a single
	recipient identities if it requires different sets of		provisioning request.
	egress points be used for calls originating from
	different parts of its network. Routing from egress		UC ID #3 TN range destinations: The SSP wishes to add or remove one
	points to ingress points of the terminating SSP may be		or multiple TN range destinations in a single provisioning
	accomplished by static routing from the egress points		request. TN ranges support number ranges that need not be
	or by the egress points using data provisioned to the		'blocks'. In other words the TN range 'start' can be any
	Registry by the terminating SSP.		number and the TN range 'end' can be any number that is
			greater than the TN range 'start'.
			UC ID #4 Non-TN destinations: An SSP chooses to peer their messaging
			service with another SSPs picture/video mail service.
			Allowing a user to send and receive pictures and/or video
			messages to a mobile user's handset, for example. The
			important aspect of this use case is that it goes beyond
			simply mapping TNs to IP addresses/hostnames that describe
			points-of-interconnect between peering network SSP's.
			Rather, for each user the SSP provisions the subscriber's
			email address (i.e. jane.doe@example.com). This mapping
			allows the mobile multimedia messaging service center
			(MMSC) to use the subscriber email address as the lookup
			key and route messages accordingly.
			UC ID #5 LUF-only provisioning: SSP wants to provision the registry
			for LUF lookup only and prefers LRF to be accomplished via
			non-registry mechanisms. In this case the registry lookup
			will return a domain name and the originating SSP will rely
			on mechanisms such as ([RFC3263]) to obtain routing
			information. This routing information is managed by the
			(terminating) SSP, via DNS mechanisms.
			3.1.1.4. Category: Administration
			UC ADMIN #1 Moving an SSP from one data recipient group to another:
			An SSP would like to re-assign the destination groups it
			shares with a peer and move the peer SSP from one Data
			Recipient Group to another. This results in the moved
			peer seeing a new and different set of routing data.
			UC ADMIN #2 Separation of responsibility: An SSP's operational
			practices can seperate the responsibility of
			provisioning the routing information, and the associated
			identities, to different entities. For example, a
			network engineer can establish a physical interconnect
			with a peering SSP's network and provision the
			associated domain name, host, and IP addressing
			information. Separately, for each new service
			subscription, the SSP's back office system provisions
			the associated public identities.
			UC ADMIN #3 Peering offer/acceptance: An SSP offers to allow
			terminations from another SSP by adding that SSP to a
			Data Recipient Group it controls. This causes
			notification of the offered SSP. An SSP receiving a
			peering offer should be able to accept or decline the
			offer. If the offer is rejected the registry should not
			provision corresponding SED to the rejecting SSP. It is
			expected that this capability will apply mainly in the
			transit case where non-authoritative parties (in the
			sense of not being the terminating SSP for an identity)
			wish to offer the ability to reach the identity and
			originating SSPs may wish to restrict the routes that
			are provisioned to their local data repositories.
			3.1.1.5. Category: Number Portability
			UC NP #1 The SSP does not wish to provision individual TNs, but
			instead, for ease of management, wishes to provision
			Routing Numbers (e.g., as in some number portability
			implementations). Each RN effectively represents a set of
			individual TNs, and that set of TNs is assumed to change
			'automatically' as TNs are ported in and ported out. Note
			that this approach requires a query to resolve a TN to an
			RN prior to using the provisioned data to route.
	3.1.2. Requirements		3.1.2. Requirements
	The following data requirements apply:		The following data requirements apply:
	DREQ1: The registry provisioning data model MUST support the		DREQ1: The registry provisioning data model MUST support the
	following entities: public identities, destination groups,		following entities: public identities, destination groups,
	routing groups and data recipient groups.		routing groups and data recipient groups.
	DREQ2: The registry provisioning data model MUST support the		DREQ2: The registry provisioning data model MUST support the
	skipping to change at page 15, line 20		skipping to change at page 16, line 24
	- reassignment of one or more public identities from one		- reassignment of one or more public identities from one
	destination group to another;		destination group to another;
	- reassignment of one data recipient from one destination		- reassignment of one data recipient from one destination
	group to another;		group to another;
	- association and disassociation of a "Default Routing		- association and disassociation of a "Default Routing
	Group" with a Data Recipient; and,		Group" with a Data Recipient; and,
	- identification of a destination group as a "Primary		- identification of a destination group as a "Carrier of
	Provider" destination group or a "Transit" destination		Record" (COR) destination group or a "Transit" destination
	group.		group.
	FREQ4: When an entity with a different client identifier than that		FREQ4: When an entity with a different client identifier than that
	of the carrier of record for a public identity in a		of the carrier of record for a public identity in a
	destination group adds a new SSP to a destination recipient		destination group adds a new SSP to a destination recipient
	group associated with that destination group, the registry		group associated with that destination group, the registry
	provisioning interface MUST: a) notify the new SSP of the		provisioning interface MUST: a) notify the new SSP of the
	updated routing information (which constitutes a peering		updated routing information (which constitutes a peering
	offer) b) not provision the SED to the new SSP's LDR unless		offer) b) not provision the SED to the new SSP's LDR unless
	the new SSP signals acceptance.		the new SSP signals acceptance.
	skipping to change at page 17, line 14		skipping to change at page 18, line 18
	Exactly one client identifier MUST be allowed to provision		Exactly one client identifier MUST be allowed to provision
	objects under a given data recipient identifier. But a		objects under a given data recipient identifier. But a
	client identifier MUST be allowed to provision objects under		client identifier MUST be allowed to provision objects under
	multiple data recipient identifiers.		multiple data recipient identifiers.
	Objects provisioned under one "Protocol Client Identifier"		Objects provisioned under one "Protocol Client Identifier"
	MUST NOT be alterable by a provisioning session established		MUST NOT be alterable by a provisioning session established
	by another "Protocol Client Identifier".		by another "Protocol Client Identifier".
			FREQ12: The registry provisioning protocol MUST allow an SSP to
			provision LUF-only or LUF+LRF data in the registry via a
			single provisioning interface and data model.
	3.2. Distribution of data into local data repositories		3.2. Distribution of data into local data repositories
	This section targets use cases concerned with the distribution of SED		This section targets use cases concerned with the distribution of SED
	to local data repositories. This is considered out-of-scope for this		to local data repositories. This is considered out-of-scope for this
	version of the document.		version of the document.
	3.3. Miscellaneous Use Cases
	This section contains additional use cases for consideration.
	3.3.1. Indirect Peering to Selected Destinations
	The SSP transit provider wishes to provide transit peering points for
	a set of destinations. But that set of destinations does not align
	with the destination groups that already exist. The SSP wishes to
	establish its own destination groups for the destinations that it
	provides transit to.
	3.3.2. TBD: RN Destinations
	The SSP does not wish to provision individual TNs, but instead, for
	ease of management, wishes to provision Routing Numbers ((e.g., as in
	some number portability implementations). Each RN effectively
	represents a set of individual TNs, and that set of TNs is assumed to
	change 'automatically' as TNs are ported in and ported out. Note
	that this approach requires a query to resolve a TN to an RN prior to
	using the provisioned data to route.
	4. Security Considerations		4. Security Considerations
	Session establishment data allows for the routing of SIP sesions		Session establishment data allows for the routing of SIP sesions
	within, and between, SIP Service Providers. Access to this data can		within, and between, SIP Service Providers. Access to this data can
	compromise the routing of sessions and expose a SIP Service Provider		compromise the routing of sessions and expose a SIP Service Provider
	to attacks such as service hijacking and denial of service. The data		to attacks such as service hijacking and denial of service. The data
	can be compromised by vulnerable functional components and interfaces		can be compromised by vulnerable functional components and interfaces
	identified within the use cases.		identified within the use cases.
	5. IANA Considerations		5. IANA Considerations
	This document does not register any values in IANA registries.		This document does not register any values in IANA registries.
	6. Acknowledgments		6. Acknowledgments
	This document is a result of various discussions held by the DRINKS		This document is a result of various discussions held by the DRINKS
	requirements design team, which is comprised of the following		requirements design team, which is comprised of the following
	individuals, in alphabetical order: Deborah A Guyton (Telcordia),		individuals, in alphabetical order: Deborah A Guyton (Telcordia),
	Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth		Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth
	Cartwright (Verisign), Manjul Maharishi (Verisign), Penn Pfautz (AT&T		Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Penn Pfautz
	Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey, Nuestar;		(AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey,
	and Alexander Mayrhofer, enum.at GmbH), and the editors of this		Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of
	document.		this document.
			This specific version is primarily the result of feedback from David
			Schwartz (Xconnect) and Jean-Francois Mule (CableLabs), with input
			from other participants listed above.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informative References		7.2. Informative References
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
			[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
			Protocol (SIP): Locating SIP Servers", RFC 3263,
			June 2002.
	[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia		[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
	Interconnect (SPEERMINT) Terminology", RFC 5486,		Interconnect (SPEERMINT) Terminology", RFC 5486,
	March 2009.		March 2009.
	Author's Address		Author's Address
	Sumanth Channabasappa		Sumanth Channabasappa
	CableLabs		CableLabs
	858 Coal Creek Circle		858 Coal Creek Circle
	Louisville, CO 80027		Louisville, CO 80027
End of changes. 41 change blocks.
	246 lines changed or deleted		276 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/