draft-ietf-drinks-usecases-requirements-01.txt		draft-ietf-drinks-usecases-requirements-02.txt
	DRINKS S. Channabasappa, Ed.		DRINKS S. Channabasappa, Ed.
	Internet-Draft CableLabs		Internet-Draft CableLabs
	Intended status: Informational March 8, 2010		Intended status: Informational May 3, 2010
	Expires: September 9, 2010		Expires: November 4, 2010
	DRINKS Use cases and Protocol Requirements		DRINKS Use cases and Protocol Requirements
	draft-ietf-drinks-usecases-requirements-01		draft-ietf-drinks-usecases-requirements-02
	Abstract		Abstract
	This document captures the use cases and associated requirements for		This document captures the use cases and associated requirements for
	interfaces to provision session establishment data into SIP Service		interfaces that provision session establishment data into SIP Service
	Provider components that aid with session routing. Specifically, the		Provider components, to assist with session routing. Specifically,
	current version of this document focuses on the provisioning of one		the current version of this document focuses on the provisioning of
	such element, termed the registry.		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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on November 4, 2010.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 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		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
	described in the BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 10		3. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 8
	3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 10		3.1. Registry Provisioning . . . . . . . . . . . . . . . . . . 8
	3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 10		3.1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 15		3.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 14
	3.2. Distribution of data into local data repositories . . . . 18		4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 19		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 22		7.2. Informative References . . . . . . . . . . . . . . . . . . 21
	7.2. Informative References . . . . . . . . . . . . . . . . . . 22		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
	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 3, line 29		skipping to change at page 3, line 29
	server that provides resolution responses.		server that provides resolution responses.
	Destination Group: A set of public identities that are grouped		Destination Group: A set of public identities that are grouped
	together to facilitate session setup and routing.		together to facilitate session setup and routing.
	Public Identity: A generic term that refers to a telephone number		Public Identity: A generic term that refers to a telephone number
	(TN), an email address, or other identity as deemed appropriate,		(TN), an email address, or other identity as deemed appropriate,
	such as a globally routable URI of a user address (e.g.,		such as a globally routable URI of a user address (e.g.,
	mailto:john.doe@example.net).		mailto:john.doe@example.net).
	Routing Group: a grouping of SED records.		Routing Group: A grouping of SED records.
	SED Record: A SED Record contains much of the session establishment
	data or a 'redirect' to another registry where the session
	establishment data can be discovered. SED Records types supported
	are NAPTRs, CNAME, DNAME, and NS Records.
	Data Recipient: SP or SSP that receives or consumes SED and related		Authoritative SSP or Entity This refers to the carrier-of-record,
	information.		for a public identity or TN Range.
	Data Recipient Group: A group of Data Recipients that receive the		Non-authoritative SSP or Entity This refers to the transit provider
	same set (or subset) of SED and related information.		for a public identity or TN Range.
	2. Overview		2. Overview
	The SPEERMINT WG specifies Session Establishment Data, or SED, as the		The SPEERMINT WG specifies Session Establishment Data, or SED, as the
	data used to route a call to the next hop associated with the called		data used to route a call to the next hop associated with the called
	domain's ingress point. More specifically, the SED is the set of		domain's ingress point. More specifically, the SED is the set of
	parameters that the outgoing signalling path border elements (SBEs)		parameters that the outgoing signalling path border elements (SBEs)
	need to complete the call. See [RFC5486] for more details.		need to establish a session. See [RFC5486] for more details.
	The specification of the format and protocols to configure SED is a		The specification of the format and protocols to provision SED is a
	task taken up by the DRINKS WG. The use cases and requirements that		task taken up by the DRINKS WG. The use cases and requirements that
	have been proposed in this regard are compiled in this document.		have been proposed in this regard are compiled in this document.
	SED is typically created by the terminating SSP and consumed by the		SED is typically created by the terminating SSP and consumed by the
	originating SSP. For scalability reasons SED is rarely exchanged		originating SSP. To avoid a multitude of bilateral exchanges, SED is
	directly between the intended parties. Instead, it is exchanged via		usually shared via intermediary systems - termed Registries within
	intermediate systems - termed Registries within this document. Such		this document. Such registries receive SED via provisioning
	registries receive SED via provisioning transactions from other SSPs,		transactions from other SSPs, and then distribute the received data
	and then distribute the received data into Local Data Repositories.		into Local Data Repositories. These local data repositories are used
	These local data repositories are used for call routing by outgoing		for call routing by outgoing SBEs. This is depicted in Figure 1.
	SBEs. This is depicted in Figure 1.
	*-------------*		*-------------*
	1. Provision SED | |		1. Provision SED | |
	-----------------------> | Registry |		-----------------------> | Registry |
	| |		| |
	*-------------*		*-------------*
	/ \		/ \
	/ \		/ \
	/ \		/ \
	/ \		/ \
	skipping to change at page 7, line 9		skipping to change at page 6, line 9
	o Registries are the authoritative source for provisioned session		o Registries are the authoritative source for provisioned session
	establishment data (SED) and related information.		establishment data (SED) and related information.
	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 (refer to the use cases in Section 3.1.1.3 for
			the rationale):
	o Aggregation of public Identifiers: The initial input 'key' to a
	SED lookup is a public identifier. Since many public identifiers
	will share similar (or identical) destinations, and hence return
	similar (or identical) SED, provisioning the same set of SED for
	millions of public identifiers is inefficient, especially in cases
	where the SED needs to be modified. Therefore, an aggregation
	mechanism to 'group' public identifiers is proposed. This
	aggregation is called a 'destination group'.
	o Aggregation of SSPs: It is expected that SSPs may want to expose		o Aggregation of public Identifiers into a destination group.
	different sets of SED, depending on the receiving SSP. This
	exposure may not always be unique, in which case an aggregation
	makes it efficient. Such an aggregation is proposed, and termed
	'Data Receipient Group'.
	o Aggregation of SED records: Finally, it is anticipated that a		o Aggregation of SED records into a Routing Group.
	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
	records multiple times (without creating duplicates) an
	aggregation mechanism at this level is proposed, and called
	'Routing Group'.
	The above aggregations are illustrated in Figure 3.		The above aggregations are illustrated in Figure 3.
	+---------+ +--------------+		+---------+ +--------------+ +---------+
	| Data | 0..n 1 |DATA RECIPIENT|		| Data |0..n 1| ROUTING | 1 0..n| SED |
	|Recipient|------------| GROUP |		|Recepient|------------| GROUP | --------------| Record |
	+---------+ +------.-------+		+---------+ +--------------+ +---------+
	0..n |
	|
	|
	1 |
	+--------------+ +---------+
	| ROUTING | ------------->| SED |
	| GROUP | 1 0..n | Record |
	+--------------+ +---------+
	|0..n |0..n		|0..n |0..n
	| |		| |
	| |		| |
	| |		| |
	| 1 |		| 1 |
	1..n +--------------+ 0..n |		1..n +--------------+ 0..n |
	---------| DESTINATION |--------- |		---------| DESTINATION |--------- |
	| | GROUP | | |		| | GROUP | | |
	| +--------------+ | |		| +--------------+ | |
	| | | |		| | | |
	skipping to change at page 10, line 11		skipping to change at page 8, line 11
	- A data recipient group contains zero or more data recipients to		- A data recipient group contains zero or more data recipients to
	facilitate the allocation of access privileges to routing groups.		facilitate the allocation of access privileges 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		This Section documents use cases related to the provisioning of the
	(SED). The registry needs to be provisioned with this data to		registry. Any request to provision, modify or delete data is subject
	perform its function. This data includes: destination groups,		to authorization. However, the act of authorization is considered
	routing groups and data recipient groups. It can also include RNs		out of scope within this document.
	and TN Ranges. The following sub-sections illustrate the use cases
	and the requirements, respectively.
	3.1.1. Use Cases		3.1.1. Use Cases
	The use cases are divided into the following categories - process,		The use cases are divided into the following categories - different
	routing, identity, administration, and number portability.		provisioning options, options for provisioning SED data,
			administration, and number portability.
	3.1.1.1. Category: Process		3.1.1.1. Category: Provisioning Options
	UC PROCESS #1 Near-real-time provisioning: The registry is		UC PROCESS #1 Real-time provisioning: once a registry is established
	provisioned with data that is not accompanied by an		events may occur that necessitate SSPs to add, modify
	effective date or time. In such cases, the registry		or delete data in the registry, in real-time, to
	will validate the data and make it effective in near		maintain accuracy of the data. Examples of such
	real-time.		events can be found in other use cases within this
			document (e.g., identity related use cases).
	UC PROCESS #2 Deferred provisioning with effective date/time: The		UC PROCESS #2 Non-real-time or bulk provisioning: There are cases
	registry is provisioned with data that is accompanied		when a registry needs to be provisioned with bulk data
	by an effective date and time. In scenarios such as		sets, via an offline mechanism, as opposed to real-
	this, the registry will validate the data and wait		time provisioning requests. Examples include: when a
	until the effective date and time to make it		new registry is established or when data is being
	effective. TBD: What happens if near-real time data		restored from a backup.
	overrides data parked for later incorporation?
	UC PROCESS #3 Batch provisioning: The registry is provisioned via an		3.1.1.2. Category: SED options
	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.
	3.1.1.2. Category: Routing		UC SED DATA #1 Inter-network SED: An SSP provisons SED records for a
			specific end-user, so that other SSPs can use this
			SED data to establish sessions intended with this
			end-user. The provisioning SSP can either be the
			carrier-of-record (direct peering), or a transit
			provider (indirect peering).
	UC ROUTING #1 Intra-network SED: SSP wishes to provision their		UC SED DATA #2 Intra-network SED: An SSP provisons SED records for a
	intra-network Session Establishment Data (SED) such		specific end-user, for use within the SSP's networks.
	that it enables current and future network services to		This will allow internal signaling elements to
	identify and route real-time sessions. For example,		establish sessions intended for this end-user. The
	in the case of VoIP calls it allows one SoftSwitch		provisioned SED is only distributed to specific local
	(calling) to discover another (called). The SSP		data repositories, and will probably differ from the
	provisions IP addressing information pertaining to		SED provisioned for use by signaling elements from
	each SoftSwitch, which is provisioned to the registry		other SSPs.
	but only distributed to a specific local data
	repository. This SED may differ from the SED that is
	distributed to other local data repositories.
	UC ROUTING #2 Support for destination groups: An SSP may wish to		UC SED DATA #3 Selective peering: While an SSP may provision the
	control the flow of traffic into their network		same SED records for all other SSPs, an SSP may also
	(ingress) based on groupings of Public Identities.		wish to provision different SED records for different
	Associating each group of Public Identities with a		SSPs (e.g., if they have different peering
	specific set of ingress SBEs or points-of-		agreements).
	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.
	UC ROUTING #3 Modifying destination groups: A set of public		UC SED DATA #4 LUF-only data: An SSP can choose to provison LUF-only
	identities are assigned a different Destination Group		data in the registry. A querying SSP that receives
	which effectively changes their routing information.		LUF-only data may need to rely on other mechanisms
	This may be due to a network re-arrangement, a		(e.g., [RFC3263] for domain-name based LUF) to obtain
	Signaling path Border Element being split into two, or		LRF information.
	a need to do maintenance, two carriers merging, or
	other considerations. This scenario can also include
	an effective date and time.
	UC ROUTING #4 Indirect Peering to Selected Destinations: The SSP		UC SED DATA #5 LUF and LRF data: An SSP can provison LUF- and LRF-
	transit provider wishes to provide transit peering		data in the registry. In such cases, the querying
	points for a set of destinations. But that set of		SSP does not have to rely on mechanisms such as DNS
	destinations does not align with the destination		(e.g., [RFC3263]) for routing information.
	groups that already exist. The SSP wishes to
	establish its own destination groups for the
	destinations that it provides transit to. (Editor's
	note: This use case needs more work.)
	UC ROUTING #5 Inter-network SED (direct and selective peering): In		UC SED DATA #6 Target Domain as a resolvable Domain Name,
	this case the SSP is the actual carrier-of-record; the		administrative domain name, or both: The target
	entity serving the end-user. The SSP wishes to		domain pertaining to a public identity or TN Range
	communicate different SED data to some of its peers		can either be a DNS-resolvable domain name (i.e., via
	that wish to route to its destinations. So the SSP		[RFC3263]) or an administrative domain. An SSP may
	has implemented direct points-of-interconnect with		also wish to provision both sets of data, and the
	each peer and therefore would like address-resolution		response is based on a default choice or the querying
	to result in different answers depending on which peer		entity.
	is asking.
	UC ROUTING #6 Selecting egress points: An SSP has a peering		UC SED DATA #7 Target Domain as an administrative domain: The target
	relationship with a peer, and when sending messages to		domain for a public identity or TN Range can be an
	that peer's point of interconnection, the originating		administrative domain. In such cases the resolution
	SSP wishes to use one or more points of egress. These		may be out of scope for this document.
	points of egress may vary for an given peer. This
	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.
	UC ROUTING #7 SSP prefers to provision LUF and LRF data in the		UC SED DATA #8
	registry: SSP prefers the registry to have access to
	LUF and LRF information. In this case the originating
	SSP does not have to rely on mechanisms such as DNS
	(e.g., [RFC3263]) for routing information since a
	registry query will return the terminating SBE.
	UC ROUTING #8 Provision an authoritative name server (not actual		UC SED DATA #9 EDITOR's NOTE: This use case seems to be a special
	route): An SSP maintains a Tier 2 name server that		case of LUF-only provisioning. Thoughts?
	contains the NAPTR records that constitute the
	terminal step in the LUF. The SSP needs to provision
	an registry to direct queries for the SSPs numbers to
	the Tier 2. Usually queries to the registry should
	return NS records, but, in cases where the Tier 2 uses
	a different domain suffix from that used in the
	registry, CNAME and NS records may be employed
	instead.
	3.1.1.3. Category: Identity		Provision an authoritative name server: An SSP
			maintains a Tier 2 name server that contains the
			NAPTR records that constitute the terminal step in
			the LUF. The SSP needs to provision an registry to
			direct queries for the SSPs numbers to the Tier 2.
			Usually queries to the registry should return NS
			records, but, in cases where the Tier 2 uses a
			different domain suffix from that used in the
			registry, CNAME and NS records may be employed
			instead.
	UC ID #1 Deletion of public identity: A public identity (or a TN		3.1.1.3. Category: Data Aggregations
	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.
	UC ID #2 Global TN destinations: The SSP wishes to add or remove one		UC DATA #1 Aggregation of public Identifiers: The input key to a SED
			lookup is a public identifier. Since several public
			identifiers will potentially share similar (or identical)
			destinations, and hence similar (or identical) SED
			records, provisioning the same set of SED for millions of
			public identifiers is inefficient. Therefore, an
			aggregation mechanism to 'group' public identifiers is
			proposed. This aggregation is termed as a 'destination
			group' in the proposed data model.
			UC DATA #2 Aggregation of SED records: A complete set of session
			establishment data may consist of more than just one SED
			record. To be able to create and use the same set of SED
			records multiple times (without creating duplicates) an
			aggregation mechanism is required. This is termed as a
			'Routing Group' in the data model.
			3.1.1.4. Category: Administration
			UC ADMIN #1 New authoritative additions: An SSP provisions a public
			identity or TN Range, as its authoritative entity (i.e.,
			carrier-of-record).
			UC ADMIN #2 New non-authoritative additions: An SSP provisions a
			public identity or TN Range, as a non-authoritative
			(i.e., transit) entity.
			UC ADMIN #3 Authoritative modifications to existing entries: An SSP
			indicates that it is the authoritative entity for an
			existing public identity or TN Range. If the public
			identity or TN Range was previously associated with a
			different authoritative entity then there are two
			possible outcomes: a) the previous authoritative entity
			is disassociated, or, b) the previous authoritative
			entity is relegated to non-authoritative status. The
			choice may be dependent on the deployment scenario, and
			is out of scope for this document.
			UC ADMIN #4 Non-authoritative modifications to existing entries: An
			SSP indicates that it is a transit provider for an
			existing public identity or TN Range. In such cases,
			this SSP is associated with the public identity or TN
			Range, in non-authoritative status.
			UC ADMIN #5 Authoritative disassociation from existing entries: An
			SSP disassociates itself from a public identity or TN
			Range that it is authoritative for. If there are no
			other (non-authoritative) SSPs associated with this
			public identity or TN Range, then the public identity
			may be deleted.
			UC ADMIN #6 Non-authoritative disassociation from existing entries:
			A SSP disassociates itself from a public identity or TN
			Range that it is linked with, as a non-authoritative
			entity. If there are no other authoritative or non-
			authoritative entities associated with this public
			identity or TN Range, the public identity may be
			deleted.
			UC ADMIN #7 Deletion of existing public identity or TN Range: A
			public 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.
			UC ADMIN #8 EDITOR's Note: We may need to normalize the language
			here to use specified terms.
			Time-To-Live (TTL): For performance reasons, in favor of
			localized lookups, a query entity may decide to cache
			the answers and selectively query the resolution server
			when either the TTL expires or as a result of another
			out of band trigger. Therefore, the publishing entity
			should be able to *optionally* specify the TTL for a
			given route record. If the provisioning server doesn't
			support TTL option, it will result in a failure and a
			well-known error should be returned in the response.
			3.1.1.5. Category: Number Portability
			UC NP #1 EDITOR's NOTE: We need to reconcile these two paragraphs.
			Routing Numbers: The SSP does not wish to provision
			individual TNs, but instead, for ease of management, wishes
			to provision Routing Numbers. Each RN represents a set of
			individual TNs, and that set of TNs is assumed to change
			'automatically' as TNs are ported-in or ported-out. Note
			that this approach requires a query to resolve a TN to an
			RN prior to using the provisioned data to route.
			The SSP wishes to provide in query response to public
			identities an associated routing number or RN. This is the
			case when a set of public identities is no longer
			associated with original SSP but have been ported to a
			recipient SSP who provides access to these identities via a
			switch on the SS7 network identified by the RN. In this
			case a destination group containing all numbers that should
			be routed to this RN needs to be created and the route
			group associated with this DG needs to contain the RN
			UC NP #2 Authoritative release: A release command associated with
			one or more public identities (or TN Ranges) is received
			from an authoritative entity indicating his relinquishing
			of authoritative "ownership" over the respective
			identities.
			EDITOR's NOTE: Can't this be achieved by an authoritative
			disassociation?
			UC NP #3 Authoritative lock error: An existing public identity (or a
			TN range) is added indicating authoritative ownership by
			the provisioning entity. However, there may be cases where
			an explicit release is required. If so, and a release has
			not been provided, this will result in an error response.
			3.1.1.6. Category: PLEASE REVIEW AND SEE IF THESE NEED TO BE ADDED
			UC ID #1 Global TN destinations: The SSP wishes to add or remove one
	or multiple fully qualified TN destinations in a single		or multiple fully qualified TN destinations in a single
	provisioning request.		provisioning request.
	UC ID #3 TN range destinations: The SSP wishes to add or remove one		UC ID #2 TN range destinations: The SSP wishes to add or remove one
	or multiple TN range destinations in a single provisioning		or multiple TN range destinations in a single provisioning
	request. TN ranges support number ranges that need not be		request. TN ranges support number ranges that need not be
	'blocks'. In other words the TN range 'start' can be any		'blocks'. In other words the TN range 'start' can be any
	number and the TN range 'end' can be any number that is		number and the TN range 'end' can be any number that is
	greater than the TN range 'start'.		greater than the TN range 'start'.
	UC ID #4 Non-TN destinations: An SSP chooses to peer their messaging		UC ID #3 Non-TN destinations: An SSP chooses to peer their messaging
	service with another SSPs picture/video mail service.		service with another SSPs picture/video mail service.
	Allowing a user to send and receive pictures and/or video		Allowing a user to send and receive pictures and/or video
	messages to a mobile user's handset, for example. The		messages to a mobile user's handset, for example. The
	important aspect of this use case is that it goes beyond		important aspect of this use case is that it goes beyond
	simply mapping TNs to IP addresses/hostnames that describe		simply mapping TNs to IP addresses/hostnames that describe
	points-of-interconnect between peering network SSP's.		points-of-interconnect between peering network SSP's.
	Rather, for each user the SSP provisions the subscriber's		Rather, for each user the SSP provisions the subscriber's
	email address (i.e. jane.doe@example.com). This mapping		email address (i.e. jane.doe@example.com). This mapping
	allows the mobile multimedia messaging service center		allows the mobile multimedia messaging service center
	(MMSC) to use the subscriber email address as the lookup		(MMSC) to use the subscriber email address as the lookup
	key and route messages accordingly.		key and route messages accordingly.
	UC ID #5 LUF-only provisioning: SSP wants to provision the registry		UC ID #4 Separation of responsibility: An SSP's operational
	for LUF lookup only and prefers LRF to be accomplished via		practices can seperate the responsibility of provisioning
	non-registry mechanisms. In this case the registry lookup		the routing information, and the associated identities, to
	will return a domain name and the originating SSP will rely		different entities. For example, a network engineer can
	on mechanisms such as ([RFC3263]) to obtain routing		establish a physical interconnect with a peering SSP's
	information. This routing information is managed by the		network and provision the associated domain name, host, and
	(terminating) SSP, via DNS mechanisms.		IP addressing information. Separately, for each new
			service subscription, the SSP's back office system
	3.1.1.4. Category: Administration		provisions the associated public identities.
	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		UC ID #5 Peering offer/acceptance: An SSP offers to allow
	instead, for ease of management, wishes to provision		terminations from another SSP by adding that SSP to a Data
	Routing Numbers (e.g., as in some number portability		Recipient Group it controls. This causes notification of
	implementations). Each RN effectively represents a set of		the offered SSP. An SSP receiving a peering offer should
	individual TNs, and that set of TNs is assumed to change		be able to accept or decline the offer. If the offer is
	'automatically' as TNs are ported in and ported out. Note		rejected the registry should not provision corresponding
	that this approach requires a query to resolve a TN to an		SED to the rejecting SSP. It is expected that this
	RN prior to using the provisioned data to route.		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.2. Requirements		3.1.2. Requirements
			EDITOR's NOTE: !!!!!THIS NEEDS TO BE REVISED AFTER WE SIGN-OFF ON THE
			USE CASES!!!!!
	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
	grouping and aggregation of public identities within		grouping and aggregation of public identities within
	destination groups.		destination groups.
	skipping to change at page 18, line 22		skipping to change at page 18, line 5
	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		FREQ12: The registry provisioning protocol MUST allow an SSP to
	provision LUF-only or LUF+LRF data in the registry via a		provision LUF-only or LUF+LRF data in the registry via a
	single provisioning interface and data model.		single provisioning interface and data model.
	3.2. Distribution of data into local data repositories
	This section targets use cases concerned with the distribution of SED
	to local data repositories. This is considered out-of-scope for this
	version of the document.
	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
	skipping to change at page 21, line 16		skipping to change at page 20, line 16
	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 (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Penn Pfautz		Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Penn Pfautz
	(AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey,		(AT&T Corp), Ray Bellis (Nominet), the co-chairs (Richard Shockey,
	Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of		Nuestar; and Alexander Mayrhofer, enum.at GmbH), and the editors of
	this document.		this document.
	This specific version is primarily the result of feedback from David		This specific version of the document is a result of contributions
	Schwartz (Xconnect) and Jean-Francois Mule (CableLabs), with input		from, primarily, David Schwartz (XConnect), Kenneth Cartwright (TNS,
	from other participants listed above.		Inc.) and Syed Ali (Neustar, Inc.). Other participants who reviewed
			and provided comments include: Alexander Mayrhofer (enum.at GmbH),
			Jean-Francois Mule (CableLabs), Manjul Maharishi (TNS, Inc.), and
			other participants on the DRINKS mailing list.
	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
End of changes. 42 change blocks.
	267 lines changed or deleted		270 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/