Network Working Group D. Schwartz
Internet-Draft Kayote Networks
Intended status: Informational E. Katz
Expires: April 27, 2007 XConnect Global Networks
J. Barkan
Digitalshtick
October 24, 2006
Session Peering Use Cases for Federations
draft-schwartz-speermint-use-cases-federations-00.txt
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 27, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a use case involving session peering in
Service Provider Federations. The scenario is based on the
deployment experience gleaned from one such active federation. The
focus in this document is on SIP layer interactions and supporting
protocols commonly used in Federation based Layer 5 peering.
Schwartz, et al. Expires April 27, 2007 [Page 1]
Internet-Draft Speermint Use Cases October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . 4
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Peering Service Providers (PSPs) . . . . . . . . . . . . . . . 7
6. High-Level Peering Models . . . . . . . . . . . . . . . . . . 7
6.1. Bi-Lateral or direct peering . . . . . . . . . . . . . . . 8
6.2. Assisted peering . . . . . . . . . . . . . . . . . . . . . 9
6.3. Indirect peering . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Schwartz, et al. Expires April 27, 2007 [Page 2]
Internet-Draft Speermint Use Cases October 2006
1. Introduction
The purpose of this document is to highlight some of the actual
peering models that are in practical use (commercial or other) today.
This document should not be seen as a set of requirements for what
peering should or should not be; rather, it is a statement of how
voice-service provider peering is occurring in the IP world today.
It is descriptive, not prescriptive. This document starts with a
conceptual framework for understanding peering models. This
framework is then mapped into the three identified peering model
categories described in the SPEERMINT terminology draft [9].
Finally, a use case containing elements of all models and closely
modeling an actual peering instance is presented.
2. Terminology
Terminology in this document follows the conventions listed in [9]
with the following additions:
OU: Originating User - User Agent making the call
O-VSP: Originating Voice Service Provider - VSP providing voice
services to OU
TU: Terminating User - User Agent receiving the call
T-VSP: Terminating Voice Service Provider - VSP providing voice
services to TU
PSP: Peering Service Provider - A logical entity providing 1 or
more of the 5 peering functions described in the next section
D-PSP: PSP providing location function or service enabling direct
(D) peering [9]relationship
I-PSP: PSP providing peering functions on behalf of a VSP enabling
indirect (I) peering [9]. Can include all peering functions or
services other than location service
A-PSP: PSP providing all peering functions on behalf of VSP
enabling Assisted (A) peering [9]. As opposed to the prior two
PSP types, access to A-PSP is restricted to VSPs sharing the same
federation as defined in [9]
Schwartz, et al. Expires April 27, 2007 [Page 3]
Internet-Draft Speermint Use Cases October 2006
3. Conceptual Model
A set of functional building blocks is defined for modeling peering.
All models discussed in this document are analyzed with respect to
six functions or services associated with the call setup across
peering networks. Each of these functions presented below has an
orthogonal layer of policy associated with it that defines the
implementation of the function. The functions are:
L (Location) Location of termination Voice Service Provider
I (Interoperability) Signaling/media compatibility with T-VSP
S (Security) Security of transport, authenticity of O-VSP/T-VSP
T (Trust) Privacy, Identity [6], Authentication management, SPIT
R (Routing) Priority based traffic management
C (Cost) Cost of call
Each of these peering functions should have a policy framework
associated with it consisting of the actual content (e.g. TLS vs.
IPSec), negotiation and enforcement. Policy can be negotiated via
anything from a simple fax to a dynamic, real- time policy exchange
engine. Such negotiation is outside the scope of this document. As
for policy content, the bullets below give some examples:
Location Function Policy Content:
o Query mechanism and format of data (NAPTR [1] , SIP 3XX [2])
o Location of authoritative information (Remote, Local)
o Type of data returned (Domain, IP)
if domain - resolution of domain (static, DNS SRV [3])
o Whose location returned (T-VSP, Intermediary)
o O-VSP has access to (All data, Selected peers)
o Data retrieval (Unlimited, Rate limited)
Schwartz, et al. Expires April 27, 2007 [Page 4]
Internet-Draft Speermint Use Cases October 2006
Interoperability Function Policy Content:
o Supported RFCs
o DTMF mechanism [5]
o B2BUA Vs Proxy [2]
o Supported codecs[4]
o Transcoding function
Security Function Policy Content:
o Type (IPSec, TLS)
o Symmetric (IPSec IKE, mutual TLS)
o Asymmetric (TLS + Digest)
Trust Function Policy Content:
o Peering relationship
Privacy (signaling, media, location)
Identity (Authentication server)
Authentication (OU, O-VSP)
o Per call
SPIT (queries/sec, sequential requests, blacklists etc)
Routing Function Policy Content:
o Priority based limiting
Concurrent calls
Schwartz, et al. Expires April 27, 2007 [Page 5]
Internet-Draft Speermint Use Cases October 2006
Call starts / sec
Congestion
Cost Function Policy Content:
o Gratis/Fee
o Type of charge (per query, per call, per minute)
o Prepaid/Postpaid
o Currency
Please note that the content just described can exist at a number of
overlapping logical entities including:
o At a PSP
o At a PSP, for a given Federation entity
o Static between specific peers O-VSP and T-VSP
o On a call by call basis between the peers
4. Scope
This document does not address the following issues relating to the
use cases:
o Provisioning of information by the VSPs to location servers
(e.g. Zone transfers, EPP, etc.)
o Negotiation of Policy
o Financial/business Motivations
o Issues discussed extensively in other documents including:
ENUM NAPTR query [1]
Schwartz, et al. Expires April 27, 2007 [Page 6]
Internet-Draft Speermint Use Cases October 2006
SIP redirect mechanism
SRV "decoding" query [3]
Trust or security mechanisms [7],[8]
5. Peering Service Providers (PSPs)
PSPs as defined as follows:
A PSP is a logical network entity providing one or more of the six
peering functions described above. It may be co-located at one or
both of the peered VSPs, or it may be a separate, independent
entity.
The following matrix presents the functionality associated with each
PSP type
| D-PSP | I-PSP | A-PSP |
------------------------------------------------------
Location | Yes | No | Yes |
------------------------------------------------------
Interoperability | No | Optional | Yes |
------------------------------------------------------
Security | No | Optional | Yes |
------------------------------------------------------
Trust | No | Optional | Yes |
------------------------------------------------------
Routing | No | Optional | Optional |
------------------------------------------------------
Cost | Optional | Optional | Optional |
------------------------------------------------------
Figure 1: PSP functionality matrix
PSPs will be represented in the diagrams as circles containing the
relevant functional elements. As noted above in the terminology
section, access to PSP functionality may be limited to members of a
federation. In this document membership in a federation will be
denoted with the word "member" associated with a link to a PSP.
6. High-Level Peering Models
The three models described below are defined in the SPEERMINT
terminology draft [9]. These models are reviewed here in the context
of our conceptual framework. Short examples are provided for the
Schwartz, et al. Expires April 27, 2007 [Page 7]
Internet-Draft Speermint Use Cases October 2006
sake of completeness and clarity.
6.1. Bi-Lateral or direct peering
The figure below depicts a typical Bi-Lateral or direct peering
relationship. While there may not be a need for a location service
to provide remote lookup (i.e. in the case where all T-VSP user
information is known by O-VSP) this is usually not the case. More
often than not, the T-VSP user list is not known remotely and there
is a need for T-VSP to be queried via either SIP redirect mechanism
or ENUM to attain the required information. For the purposes of this
document, VSPs upload their numbers to an externally reachable
location service denoted as D-PSP. While in almost all cases of Bi-
lateral relationships both O-VSP and T-VSP share a D-PSP (and could
technically be considered members of this D-PSP "federation" - as
shown in the figure below), depending on D-PSP policy, O-VSP may not
need to be a member (e.g. share any of his own user base) in order to
retrieve information about other members serviced by this D-PSP.
_____
(member) /D-PSP\ (member)
******* | | ********
* | (C) | *
* ====| (L) | *
* || \_____/ *
* ||(2) *
* || *
+---------+ +---------+
| O-VSP | | T-VSP |
| | | |
| ******* | | ******* |
| * (I) * | | * (I) * |
| * (L) * | (S)(T) | * (C) * |
| ******* |--------| ******* |
+---------+ (3) +---------+
/ \
/ \
(T)/ \
/ (4)/\
/\/(1) /TU\
/OU\ /____\
/____\
Figure 2: Direct peering example
The flow in this figure is as follows:
Schwartz, et al. Expires April 27, 2007 [Page 8]
Internet-Draft Speermint Use Cases October 2006
(1) OU sends signaling request containing TU username to O-VSP.
Note the (T) depicting the need for trust between OU and O-VDP.
As mentioned above, there are two popular protocols in use for
purposes of querying the location service (2), namely ENUM and SIP
INVITE (resulting in 3XX redirect message). In either case the
resulting call routing data (CRD) [9] containing next hop routing
information for this particular call is in the form "sip:TU@
T-VSP". This next hop domain name resolution service provided by
D-PSP is denoted by the (L) enclosed in the D-PSP.
Once the next hop domain is retrieved there is a need for
resolution into a routable address. This is performed by O-VSP
(hence the (L) in the O-VSP) and can be done either statically
based on preconfigured values or dynamically via DNS SRV. In
either case, the call is then routed to T-VSP (3) over a secure
channel and finally onto TU (4). Note that both O-VSP and T-VSP
contain the interoperability function (I) as in most cases the
Session Border Controller (SBCs) in each is responsible for this
functionality. Note also that the link connecting the two VSPs
has both (S) and (T) denoting the need for both transport layer
security (S) and trust (T) in the form of Authenticated Identity.
Finally, note the cost functions (C) located both at D-PSP and at
T-VSP indicating possible charges associated with traffic (query
or signaling) arriving at these entity.
6.2. Assisted peering
As described in the speerming-terminology draft, assisted peering
involves the deployment by the federation of centralized SIP
elements. These elements provide SIP proxy functionality, and are
often implemented in practice by Session Border Controllers (SBCs),
which may "filter" "normalize" and provide network-hiding for
incoming messages en route to their final destination. Fear and
distrust coupled with continued interoperability and security
concerns have revived the need for the neutral central element role
enabled by this peering model.
The figure below depicts a simplified assisted peering scenario
containing two VSPs in an A-PSP assisted peering (A.K.A spoke and
hub) federation. Note that as opposed to the case of the D-PSP
federation where "membership" of the querying party is optional, in
this model it is mandatory.
Schwartz, et al. Expires April 27, 2007 [Page 9]
Internet-Draft Speermint Use Cases October 2006
_____
(member) /A-PSP\ (member)
************* | | ************
* =====| (I) | *
* // |(R) (L)| *
* // --| (C) |---- *
* (2)// / \_____/ \ *
* // (3)/ (4)\(S) *
* // /(T) \(T) *
* // /(S) \ *
+---------+ +---------+
| O-VSP | | T-VSP |
| | | |
| ******* | | ******* |
| * (I) * | | * (I) * |
| * (L) * | | * * |
| ******* | | ******* |
+---------+ +---------+
| |
|(1) |(5)
(T)| |
/\ /\
/OU\ /TU\
/____\ /____\
Figure 3: Assisted peering example
The flow being presented in this figure is one where end user OU is
trying to call end user TU with both end users receiving services
from different VSPs belonging to an assisted peering federation. The
flow is as follows:
(1) OU sends a signaling request containing the TU username to
O-VSP. O-VSP cannot resolve the TU on its own, and in order to
determine the reachability of TU, must send a location query (2)
to the federation (note the (L) function in A-PSP). Since this is
an assisted peering federation, the response is in the form TU@
A-PSP signifying that the signaling needs to traverse the A-PSP.
Once the A-PSP domain is retrieved there is a need for translation
into a routable address. This can be done statically (hence the
(L) in the O-VSP) or dynamically via DNS SRV. In either case, the
call is then routed to the A-PSP (3) over a secure channel. (note
that step 2 can be eliminated by sending signaling directly to
A-PSP).
The reason for the popularity of this model can be attributed to
the concentration of functions provided by A-PSP. As an external
element, A-PSP can provide the full set of services for VSPs, and
Schwartz, et al. Expires April 27, 2007 [Page 10]
Internet-Draft Speermint Use Cases October 2006
through its own relationships with the VSP, eliminate the need of
all VSPs for pair-wise trust and service relationships. A-PSP can
potentially encompass a large namespace of users that is
accessible in one query (L) to external VSP members (or not -
depending on policy). In addition there is an interoperability
function (I) usually performed by a SIP Proxy, almost guaranteeing
interoperability and protocol interchangeability between member
VSPs. As part of the interoperability there is also is media sub-
function enabling the federation to enforce a standard set of
codecs or alternatively provide transcoding functionality to make
sure there is media interoperability as well. Finally, A-PSP can
implement the routing function (R) enabling traffic shaping and
throttling across the federation.
In this flow A-PSP looks up the next hop for this call, receives
an answer of the form sip:TU@T-VSP and translates to a routable
next hop using either statically configured information or
dynamically using DNS SRV. Next, A-PSP runs through additional
logic before deciding if call can be routed to its destination.
If no rules prevent the completion of the call it is then routed
(4) to T-VSP and finally to TU (5). Here too note the possible
cost function associated with A-PSP.
6.3. Indirect peering
The "Indirect" model defines a peering relationship that utilizes
transient peering networks or VSPs that assist in connecting the OU
to the TU. It is hard to implement this model without the additional
use of one of the other models as the relationship of the O-VSP with
the I-PSP will be either direct or assisted. For the sake of
simplicity, this section will discuss a relatively simple model and
leave a more complicated one for the next section. A simplistic
model appears in the figure below. Note that in this figure O-VSP is
not a "member" of the same D-PSP as T-VSP. For this reason he is not
granted direct access to T-VSP. Instead, the query (2) yields the
address of an intermediary I-PSP that T-VSP does have a relationship
with. In this scenario I-PSP and T-VSP are both "members" of a
D-PSP.
Schwartz, et al. Expires April 27, 2007 [Page 11]
Internet-Draft Speermint Use Cases October 2006
_____
/D-PSP\ (member)
| | *********
=========| (L) | *
// | (C) | *
(2)// //_____/ *
// || * *
// || *(member) *
// (4)|| * *
+---------+ /----------\ +---------+
| O-VSP | | I-PSP | | T-VSP |
| | | | | |
| ******* | | ******** | | ******* |
| * (I) * | | *(I)(R)* |(S)(T)| * (I) * |
| * (L) * |------| *(L)(C)* |------| * * |
| ******* | (3) | ******** | (5) | ******* |
+---------+ \----------/ +---------+
| |
(T)| (6)|
| |
/ /\
/\/ (1) /TU\
/OU\ /____\
/____\
Figure 4: Indirect peering example
The flow in this scenario is as follows:
(1) OU sends signaling request containing TU username to O-VSP.
O-VSP does not know who the user is and decides to query (2) D-PSP
(which may be a public or private ENUM tree) about TU. Since
T-VSP does not know or trust O-VSP, T-VSP does not want to accept
any traffic directly from O-VSP and wants I-PSP to process call
first to make sure it will not cause any trouble to T-VSP. T-VSP
thus registers TU as belonging to I-PSP so that response to query
in (2) is in the form sip:TU@I-PSP. O-VSP sends (3) the request
to I-PSP. Note that there may be no trust relationship (T) or
security relationship (S) between the two VSPs. Depending on
policy at I-PSP this lack of security may cause call to be
rejected. I-PSP has many peering functions available to it and
after finding out where to route the call (4) and decoding the
next hop domain information I-PSP can enforce policy for T-VSP
prior to sending off to T-VSP (5) for its final destination (6).
Note cost functions (C).
Schwartz, et al. Expires April 27, 2007 [Page 12]
Internet-Draft Speermint Use Cases October 2006
7. Use case combining different peering models
Actual real world peering models often contain more complexities than
can be described by the individual models described above. However,
by combining and composing these models, a more faithful
representation can be found.
Consider a case where T-VSP has the flowing three relationships with
other VSPs. The first relationship is an open one whereby T-VSP
accepts traffic from anyone. The second relationship is as a member
of a closed federation or premier club providing a higher class of
service to all its members. In this federation there are no
business, trust or technical issues preventing peering amongst
members as the strict membership requirements reduce these risks for
all members. The third relationship consists of premier type peers
who are technically incapable of peering with all other members of
the premier federation. They may have protocol or codec issues
denying them equal access to all members of the premier federation.
The three relationships shall be denoted for the sake of this example
OPEN, PREM and R-PREM. Incoming traffic from OPEN is accepted
providing the following conditions are met:
Complete anonymity of termination routing information is preserved
preventing possibility of direct outside contact and bypassing of
policy
Filtering of message for malicious content is performed prior to
acceptance of call by T-VSP
Calls suspected as SPIT messages are flagged or blocked before
acceptance
Dynamic throttling of outside traffic is available to give higher
priority to premier traffic
The scenario described above is presented in the figure below
Schwartz, et al. Expires April 27, 2007 [Page 13]
Internet-Draft Speermint Use Cases October 2006
+----------+ __________ (member) +---------+
| | / \**********| |
| OPEN |Signaling | A-PSP |Signaling | |
| |----------| |----------| |
+----------+ \__________/ | |
+----------+Location __________ (member) | |
| |==========/ D-PSP \**********| |
| PREM | \__________/ | T-VSP |
| |Signaling | |
| |--------------------------------| |
+----------+ | |
+----------+Location __________ (member) | |
| |==========/ D-PSP \**********| |
| | \__________/ | |
| R-PREM |Signaling __________ Signaling | |
| |----------/ I-PSP \----------| |
+----------+ \__________/ +---------+
Figure 5: Hybrid peeering example
As can be seen in the figure above, the open provider OPEN must
traverse an assisted peering federation A-PSP before being allowed to
reach T-VSP. The premier peer PREM shares a D-PSP with T-VSP and as
this relationship is just a Bi-Lateral one there is no need for
intermediaries. The reduced premier provider R-PREM shares both a
D-PSP and an I-PSP with T-VSP. As opposed to the OPEN that requires
a full blown A-PSP, since the R-PREM does not require anonymity, the
I-PSP is enough to bridge the technical divide.
8. Comparison of Models
In real world peering deployments, VSPs are players and stakeholders
in the global VoIP space. As such, peering entities must consider
financial and technical tradeoffs between the different models.
Financial tradeoffs include capital and operational expenses
associated with each model and technical tradeoffs include
scalability and reliability of each model. Future versions of this
document will present these tradeoffs in a detailed fashion.
9. Security Considerations
All Security considerations related to the SIP protocol are also
applicable in peering relationships.
Schwartz, et al. Expires April 27, 2007 [Page 14]
Internet-Draft Speermint Use Cases October 2006
10. IANA Considerations
NA
11. Acknowledgements
This document is based on contributions made by Baruch Sterman, Mike
Berkowitz and Brocha Strous of Kayote Networks and Natan Tiefenbrun
of XConnect Global Networks.
12. References
12.1. Normative References
[1] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2119, September 2000.
[2] 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.
[3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[5] Petrack, S. and H. Schulzrinne, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[6] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003.
[8] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
12.2. Informative References
[9] Mayer, D., "SPEERMINT Terminology",
draft-ietf-speermint-terminology-06.txt, September 2006.
Schwartz, et al. Expires April 27, 2007 [Page 15]
Internet-Draft Speermint Use Cases October 2006
[10] Mule, J., "SPEERMINT Requirements for SIP-based VoIP
Interconnection", draft-ietf-speermint-requirements-00.txt,
June 2006.
[11] Mahy, R., "A Minimalist Approach to Direct Peering",
draft-mahy-speermint-direct-peering-00.txt, June 2006.
[12] Malas, D., Kahn, S., Peno, R., and A. Uzelac, "SPEERMINT
Routing Architecture Message Flows",
draft-ietf-speermint-flows-00.txt, September 2006.
[13] Haberler, M., Hammer, M., and O. Lendl, "A Federation based
VOIP Peering Architecture",
draft-lendl-speermint-federations-03.txt, September 2006.
Authors' Addresses
David Schwartz
Kayote Networks
Malcha Technology Park
Building # 1
Jerusalem 90961
Israel
Phone: +972 52 347 4656
Email: david.schwartz@kayote.com
URI: www.kayote.com
Eli Katz
XConnect Global Networks
1 Ballards Lane
London N3 1LQ
United Kingdom
Phone: +44 (0) 870 794 9990
Fax: +44 (0) 870 794 9991
Email: ekatz@xconnect.net
URI: www.xconnect.net
Schwartz, et al. Expires April 27, 2007 [Page 16]
Internet-Draft Speermint Use Cases October 2006
Jeremy Barkan
Digitalshtick
Shalom Yehuda 6
Jerusalem 93395
Israel
Phone: +972 2 6728069
Email: jeremyb@digitalshtick.com
URI: www.digitalshtick.com
Schwartz, et al. Expires April 27, 2007 [Page 17]
Internet-Draft Speermint Use Cases October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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).
Schwartz, et al. Expires April 27, 2007 [Page 18]