DRINKS S. Channabasappa, Ed.
Internet-Draft CableLabs
Intended status: Informational M. Dolly, Ed.
Expires: April 30, 2009 AT&T Labs
October 27, 2008
DRINKS Use cases and Protocol Requirements
draft-channabasappa-drinks-usecases-requirements-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 April 30, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 1]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
Abstract
This document presents use cases that illustrate what constitutes
session establishment data, the functional components that need them,
and the protocol requirements for provisioning and managing session
establishment data within the identified functional components.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Provisioning a Registry . . . . . . . . . . . . . . . . . 5
3.2. Provisioning an ENUM Server . . . . . . . . . . . . . . . 6
3.3. LRF and LUF . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. LRF . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. LUF . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Generic SSP . . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Small SSP . . . . . . . . . . . . . . . . . . . . . . 8
3.4.3. Large SSP . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Miscellaneous Use Cases . . . . . . . . . . . . . . . . . 10
3.5.1. Separation of Responsibility . . . . . . . . . . . . . 10
3.5.2. Intra-Network vs Inter-Network . . . . . . . . . . . . 10
3.5.3. Massive Sunrise Provisioning . . . . . . . . . . . . . 10
3.5.4. Real-Time Provisioning . . . . . . . . . . . . . . . . 11
3.5.5. Establishing Destination Groups . . . . . . . . . . . 11
3.5.6. Direct and Selective Peering . . . . . . . . . . . . . 11
3.5.7. Indirect Peering to Selected Destinations . . . . . . 11
3.5.8. Fully Qualified TN Destinations . . . . . . . . . . . 12
3.5.9. TN Range Destinations . . . . . . . . . . . . . . . . 12
3.5.10. RN Destinations . . . . . . . . . . . . . . . . . . . 12
3.5.11. Non-TN Destinations . . . . . . . . . . . . . . . . . 12
3.5.12. Peering Relationship Management . . . . . . . . . . . 12
3.5.13. Peering Grant/Acceptance . . . . . . . . . . . . . . . 12
3.5.14. Points of Egress . . . . . . . . . . . . . . . . . . . 13
3.5.15. Tier 2 . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.16. Non-blocking transactions . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 2]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
1. Introduction
This document captures the use cases that have been proposed so far
within the DRINKS requirements design team. The goal is to seek
working group feedback to identify a set of in-scope use cases. The
end result of the use cases is to identify the data model and
requirements for provisioning and managing session establishment
data.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 3]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document also reuses the SIP terminology defined in [RFC3261].
The Lookup Function (LUF), Location Routing Functions (LRF) and other
session peering terms are defined [I-D.ietf-speermint-terminology].
In addition, this document specifies the following additional terms.
Destination Group: a set of global telephone numbers, dial codes or
public identities that can be associated with a given Destination.
A Destination Group logically groups data elements that share a
common Destination together.
Public Identity: a generic term that refers to a telephone
number(TN), a range of TNs, an email address, or other identity as
deemed appropriate. A public identity is represented as a
globally routable URIs of a user address (e.g.,
mailto:john.doe@example.net, sip:paul.speermint@example.com).
Routing Group: a logical grouping of routes. A Destination Group
may be associated with one or more routing groups based on its
association with the data recipient group.
Data Recipient Group: a list of SIP Service Providers (SSPs) that
have access to the associated Destination Group data.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 4]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
3. Use Cases
This Section contains the use cases presented so far. The use cases
are logically grouped into functional areas: provisioning a registry,
provisioning an ENUM server, LRF & LUF, and SIP Service Provider
(SSP). Use cases that are are not presently grouped are specified in
Section 3.5.
3.1. Provisioning a Registry
This Section targets use cases concerned with the provisioning of
session establishment data in the registry. Provisioning can be
accomplished in (near) real time through an automated interface
(e.g., from a service provisioning system) or by specifying an
effective date and time. When an effective date/time is used, the
registry validates the format and enters it into the registry
database with the effective date & time.
The following use cases are considered:
1. Provisioning destination groups and associated routing
information.
2. Provisioning data recipient groups.
3. Provisioning a public identity or range of TNs: A globally
routable TN or another type of public identity is provisioned and
assigned to a Destination Group. No effective date is provided
as it is desired to be made effective in (near) real time meaning
as soon as validations (format) are complete, the data is entered
into the Registry database. A distribution function may pick up
the provisioned instance in real-time or in batch mode to
distribute to each address server. Note that it is assumed that
the routing information for the Destination Group has already
been defined. This is another Use Case.
4. Public Identity is taken out of service: A public identity
(including a TN, 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 may also
trigger a number of delete updates during the distribution
operations to appropriate deletes to each address server.
5. Assigning a set of TNs to a different Destination Group changing
their routing: A set of public identities (e.g., set of TNs) are
assigned a different Destination Group which effectively changes
their routing information. This may be due to a network re-
arrangement, a Signaling path Border Element being split into
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 5]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
two, or a need to do maintenance, two carriers merging, or other
considerations. This scenario can also include an effective date
and time.
6. 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 action effectively changes the routing for all
public identities and associated services to the routing
information associated with the new Data Recipient Group and
Destination Group.
7. Defining a Routing Group: A Routing Group is a set of routes that
may include routes for a number of different public identities,
e.g., TNs, IM identifier, email. A Destination Group may be
associated with 1 or more Routing Groups based on its association
with the Data Recipient Group.
3.2. Provisioning an ENUM Server
This Section targets use cases concerned with the provisioning of
session establishment data in the ENUM Server. The following use
cases have been proposed:
1. Provisioning a Public Identify or set of Public Identities at an
effective date/time.
2. A Public Identify is taken out of service at an effective date/
time.
3. Assigning a set of Public Identities to a different destination
group, thereby changing their routing.
3.3. LRF and LUF
This Section contains use cases related to LRF and LUF. They are
presented in the following sub-sections.
3.3.1. LRF
1. Source service provider direct connection (bi-lateral): A
service provider may be connected directly with a peer network
hosting the ultimate SIP destination. Thesource service
provider is able to translate to obtain the ultimate destination
through LUF.
2. Source service provider direct connection (bi-lateral): A
service provider may be connected directly with a peer network
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 6]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
hosting the SIP destination. The source service provider is not
able to translate to the ultimate destination because the LUF
does not contain a translation.
3. Source service provider direct connection (bi-lateral): A
service provider may be connected directly with a peer network
not hosting the SIP destination. The Source service provider is
not able to translate to the ultimate destination because the
LUF does not contain a translation. The selected target network
is able to perform the LUF to identify the ultimate destination.
4. Source service provider is not connected directly with a peer
network hosting the ultimate SIP destination rather through an
intermediate transit network which is connected to a peer
network hosting the ultimate SIP destination. Note that
variations in use cases 1, 2 & 3 all apply.
5. Source service provider is not connected directly with a peer
network hosting the ultimate SIP destination, rather to a
clearing house network which is connected to a peer network
hosting the ultimate SIP destination.
6. Source service provider is not connected directly with a peer
network hosting the ultimate SIP destination rather through more
than one intermediate transit networks which are all connected
to a peer network hosting the ultimate SIP destination. The
source service provider has to chose the transit service
provider to select.
7. Source service provider has multiple paths to a destination
network both on inter-network connections and inter-transit
network connections. The source service provider wants to
select different transit networks and different routes to those
networks based on various criteria such as traffic load,
capacity, cost, latency, etc.
8. Roaming mobile user uses IMS service accessed through local
breakout, the service is located outside the serving network.
9. Roaming mobile user is disconnected from emergency service call
(via IMS local breakout). The PSAP is located in a network
outside of the serving network. The PSAP initiates a callback
to the mobile which should go to the serving network, not the
home network from the network the PSAP is located in.
10. A transit network connected to the source service provider has
had a route change or a network connectivity change which needs
to be communicated to its peer networks.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 7]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
11. A transit network has a change in the domains it is able to
reach (added, dropped/unavailable, route change) which it needs
to send to its peer networks.
12. The transit network uses LRF to route internally to the network
and to select one of several possible exit points, next hop
transit network and specific connection between networks.
13. The service provider may have fixed domain routing specified in
the LRF which overrides the domain routing provided by peer
networks.
14. The service provider may have fixed routing specified in the LRF
as a default until a peer network identifies it is able to
provide alternate (better) routing.
3.3.2. LUF
A service provider's LUF is connected to several different Registries
some for national numbers, some for enterprise identifiers (e.g.
@example.com translating to @example.nt for an enterprise user who
has a mobile with a public user identity or GRUU (3GPP TS 23.228)
which is part of an enterprise domain. {What if there is a collision
and conflict between some particular number or domain between
registries?}
3.4. SSP
This Section contains SIP Service Provider specific use cases. They
are presented in the following sub-sections.
3.4.1. Generic SSP
An SSP provisions a registry to offer different routes to different
interconnecting parties. The SSP uses the same routes for an
aggregation of public identities (e.g., TNs) and desires to be able
to specify routing for the aggregate. Routes consist of a set of RRs
of any legitimate type.
3.4.2. Small SSP
The small SSP provides coverage to a small city only with 3 different
peer interconnects: 1) To another small SSP covering an adjacent
small city; 2) to a mid-sized SSP providing coverage to the remainder
of the state; 3 to a large multi-national SSP providing SSP transit
services for the remainder of the world.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 8]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
3.4.2.1. Configuring small SSP routing
The small SSP with a small number of SSP peer arrangements prefers to
statically define and provision the SED routing through network
engineering tools by the network engineering staff. This is because
the domain coverage of each peer SSP will not change very frequently
and the small SSP does not want to incur the cost and complexity of a
dynamically established routing data.
3.4.2.2. Small SSP LUF/LRF consolidation
A small SSP only needs a single network element to handle its entire
LUF/LRF needs and as such combines the LUF and LRF. The routing
associations in this network element are provisioned statically
through network management tools by network operation or engineering
staff.
3.4.3. Large SSP
The large SSP provides coverage to a large country: the SSP is
administratively divided into regions. The SSP provides SSP transit
services to smaller SSPs operating in the same areas. The SSP has
both direct SSP connections for national and international service
and indirect SSP connections for international service to some
countries based on traffic levels. This results in multiple possible
routes to some destination SSPs through different intermediate SSPs.
Each SSP region has a different sub-set of peer SSPs that it is
directly connected to (e.g. Some regions may have to route
internally to another SSP region to reach the destination SSP).
3.4.3.1. Configuring large SSP routing
The large SSP has a large number of direct and indirect peer
arrangements along with multiple possible routes to the same
destination SSP. The large SSP prefers to only provision the SSP
peers and have the elements such as SBCs learn the routes based on
peer SSP advertisements to eliminate routing errors (loops, dead
ends, etc.) which are service affecting and almost impossible to
troubleshoot in a network of this size.
3.4.3.2. Large SSP LUF/LRF separation and LRF distribution
A large SSP needs to centralize its LUF but split off the LRF for
deployment in decentralized regional network elements. The routing
associations in the regional LRFs are provisioned dynamically through
advertisements by the large SSP peering SSPs regarding which domains
they are able to handle.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 9]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
3.4.3.3. Large SSP peering with a small SSP
A large SSP peers with a small SSP. The small SSP is unable to
support the cost and complexity of dynamically advertising to its
peer SSPs the domains it is able to reach directly or indirectly.
The large SSP provisions routing association data statically
representing the domains which the small SSP can reach either
directly or indirectly, through network management tools by network
operation or engineering staff.
3.5. Miscellaneous Use Cases
This Section contains all the use cases that were not categorized as
belonging to the specific groups indicated above. Based on further
discussions these may be re-classified.
3.5.1. Separation of Responsibility
An SSP's business practices are such that; (i) network engineering
and planning personnel are responsible for provisioning the points of
interconnect (e.g. hosts and IP addressing information), and (ii)
back office systems are responsible for number management
provisioning of TNs. An example flow would be: a network engineer
establishes physical interconnect with a peering SSP's network and
provisions associated domain name, host, and IP addressing
information, which is provisioned to the registry/ENUMserver.
Separately, for each new service subscription, the SSP's back office
system provisions the associated TNs or other public identities.
3.5.2. Intra-Network vs Inter-Network
SSP wishes to provision their intra-network Session Establishment
Data (SED) such that it enables current and future network services
to identify and route real-time sessions. For example, in the case
of VoIP calls it allows one CMS (calling) to discover another
(called). The SSP provisions IP addressing information of each CMS,
which is provisioned to the registry/ENUMserver but only distributed
to their own local ENUM server. This SED may differ from the SED
that is distributed to other local ENUM servers.
3.5.3. Massive Sunrise Provisioning
Based on configurable thresholds, sunrise may imply a batch
asynchronous provisioning process. For instance, an SSP has
commissioned a new ENUM server and wishes to download a very large
number of telephone numbers. Rather than stream individual TNs in
real-time, one at a time, towards the ENUM server the SSP's back-
office system prefers to perform the operation as a set of one or
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 10]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
more batches. The SSP has just commissioned a new ENUM server which
they plan to employ as a centralized routing server. The network
engineering group has provisioned, upon their ENUM server, the IP
addressing information of all CMS which constitute the SSP's
topology. During a regularly scheduled maintenance window the SSP
would like to download from its back office system the TNs associated
with each CMS.
3.5.4. Real-Time Provisioning
Post-sunrise, an SSP wishes to have their back-office systems add or
remove TNs per normal business operations. Over the course of a day
there is churn in the SSP's subscriber base and as such they would
like the ability to stream, in real-time, additions, modifications
and deletions.
3.5.5. Establishing Destination Groups
An SSP wishes to control the flow of traffic into their network
(ingress) based on groupings of Public Identities, called Destination
Groups. Associating each group of Public Identities with a specific
set of ingress SBEs or points-of-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 in to the
Destination Groups and associate those destination groups with the
appropriate points of ingres. The destination groups and points of
ingress are provisioned to the Registyr/Enumserver. Need to separate
this use case into two.
3.5.6. Direct and Selective Peering
In this case the SSP is the actual carrier-of-record; the entity
serving the end user. And 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.
3.5.7. 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.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 11]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
3.5.8. Fully Qualified TN Destinations
The SSP wishes to add or remove one or multiple fully qualified TN
destinations in a single provisioning request.
3.5.9. TN Range Destinations
The SSP wishes to add or remove one or multiple TN Range destinations
in a single provisioning request. TN Ranges support number ranges
that need not be 'blocks'. In other words the TN range start can be
any number and the TN range end can be any number that is greater
than the TN range start.
3.5.10. RN Destinations
The SSP does not wish to provision individual TNs, but instead, for
ease of management, wishes to provision RNs. 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.
3.5.11. 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.
3.5.12. Peering Relationship Management
An SSP wishes to have the peering relationship management process
factilitated through automation. An SSP can offer itself as a Peer
to another SSP and that peer can accept or reject that peering
relationship.
3.5.13. Peering Grant/Acceptance
An SSP wishes to facilitate the establishment of peering
relationships and interconenct points with its peers. It submits a
grant to a potential peering partner for a point of interconnect.
The Grantee can accept or ignore the grant. The act of granting and
accepting is facilitated by an automation process.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 12]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
3.5.14. Points of Egress
An SSP has a peering relation ship with a peer. And when sending
messages to that peer's point of interconnection, the originating SSP
wishes to egress through one or more points of egress. These points
of egree may vary for an given peer.
3.5.15. Tier 2
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 records may be employed instead.
3.5.16. Non-blocking transactions
An SSP is loading a large update in the registry (for example, a
large amount of adds & delete operations due to a Destination Group
being split into 2). In the meantime, the SSP wants to change a
route linked with another Destination Group because it has been
misconfigured .
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 13]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
4. Security Considerations
Session establishment data allows for the routing of SIP sesions
within, and between, SIP Service Providers. Access to this data can
compromise the routing of sessions and expose a SIP Service Provider
to attacks such as service hijacking and denial of service. The data
can be compromised by vulnerable functional components and interfaces
identified within the use cases.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 14]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
5. IANA Considerations
This document does not register any values in IANA registries.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 15]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
6. Acknowledgments
This document is a result of various discussions held by the DRINKS
requirements design team, which is comprised of the following
individuals, in alphabetical order: Deborah A Guyton (Telcordia),
Gregory Schumacher (Sprint), Jean-Francois Mule (CableLabs), Kenneth
Cartwright (Verisign), Manjul Maharishi (Verisign), Penn Pfautz (AT&T
Corp), the co-chairs (Richard Shockey, Nuestar; and Alexander
Mayrhofer, enum.at GmbH), and the editors of this document.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 16]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.espp-protocol]
Cartwright, K., Dimig, S., Teodoro, M., and J-F. Mule,
"ENUM-SIP Server Provisioning Protocol (ESPP)",
draft-mule-peppermint-espp-protocol-02.txt (work in
progress), July 2008.
[I-D.ietf-speermint-terminology]
Malas, D. and D. Meyer, "SPEERMINT Terminology",
draft-ietf-speermint-terminology-16 (work in progress),
February 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 17]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
Authors' Addresses
Sumanth Channabasappa
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: sumanth@cablelabs.com
Martin Dolly
AT&T Labs
USA
Email: mdolly AT att.com
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 18]
Internet-Draft channabasappa-drinks-usecases-reqs October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Channabasappa, Ed. & Dolly, Ed. Expires April 30, 2009 [Page 19]