Network Working Group O. Lendl
Internet-Draft enum.at
Intended status: Informational February 25, 2008
Expires: August 28, 2008
VoIP Peering: Background and Assumptions
draft-lendl-speermint-background-01.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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This documents provides background for the work on VoIP peering and
tries to provide guidance on what kind of work is needed to
facilitate widespread SIP-based peering of telephony networks. It is
intended to spur discussion on the work about peering and should also
serve as input to the ongoing discussions on reducing Spam for
Internet Telephony (SPIT).
Lendl Expires August 28, 2008 [Page 1]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Interconnection Models . . . . . . . . . . . . . . . . . . . . 3
2.1. The PSTN model . . . . . . . . . . . . . . . . . . . . . . 3
2.2. The email model . . . . . . . . . . . . . . . . . . . . . 4
3. Why is SPEERMINT needed? . . . . . . . . . . . . . . . . . . . 5
3.1. Why did the Email Model fail for SIP? . . . . . . . . . . 5
3.2. The PSTN Model does not fit, either . . . . . . . . . . . 8
4. Core Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. The Real Problem with SPIT . . . . . . . . . . . . . . . . 9
4.2. What is a SIP URI? . . . . . . . . . . . . . . . . . . . . 9
4.3. Peering vs. Reachability . . . . . . . . . . . . . . . . . 10
4.4. The Key to Routing Data . . . . . . . . . . . . . . . . . 10
4.5. Lookups vs. Announcements . . . . . . . . . . . . . . . . 11
4.6. No National Solutions . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Lendl Expires August 28, 2008 [Page 2]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
1. Introduction
The Speermint WG is chartered to help with the interconnection of SIP
based layer 7 networks. It should not deal with basic IP
connectivity and SIP protocol issues; those are covered by other
working groups.
Speermint focuses on what guidelines (and perhaps protocol elements)
are needed by service providers and enterprises to move from ad-hoc,
manual peerings to a fully standardized, secure, easy to implement,
and thus widespread SIP based peering setup.
This document aims solely at the telephony network aspects of SIP and
ignores applications like Instant Messaging or Presence which might
also be implemented using SIP. The focus here is on the use of SIP
in PSTN replacement services.
Version -01 of this draft expands on the inplications of the
interconnection structure on the SPIT problem. The concepts listed
in here should thus also be worthwhile for the RUCUS EG.
This document was written as discussion input. It is not intended
for publication as an RFC.
2. Interconnection Models
In order to understand the VoIP peering world it is necessary to go
beyond pure protocol issues and instead talk about the ecosystems in
which the protocols operate. This section tries to be purely
descriptive and makes no recommendations.
2.1. The PSTN model
The public switched telephone network (PSTN) is built upon the
following fundamental assumptions:
o Global reachability is achieved by interconnecting individual
smaller networks. There is no global lower-layer connectivity: if
two networks are not directly interconnected, then calls are
passed through transit networks on the application layer.
o There are no ad-hoc connections between networks: all links are
manually configured (physical, or other transparent bit-pipes)
lines.
Lendl Expires August 28, 2008 [Page 3]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
o There is a clear separation between network operators and network
users. This applies both to protocols (e.g., SS7 ISUP versus
ISDN), as well as, to regulatory rules.
o Routing information is not directly passed from the destination
network to the source network via some global database. Instead,
transit networks communicate to their customers which destinations
they can handle.
o Accounting and settlement are core features.
2.2. The email model
SIP according to RFC 3261 [2] and RFC 3263 [3] follows an email alike
model. It can be summarized as follows:
o Email and SIP addresses are structured as username@domain. For
routing purposes, only the domain part is relevant. The username
is only interpreted by the machines serving this specific domain.
o The global, public DNS is used to map the domain from the address
to a prioritized set of ingress points that handle incoming
communication requests for this domain. As the DNS is agnostic to
the entity querying data stored there, all senders receive the
same set of ingress points.
o In order to achieve global reachability, these ingress points need
to accept incoming requests from the open Internet. If they
reject, for example, incoming packets from a VoIP provider X from
country Y then there is no backup path for this communication, and
the destination just will not be reachable from that VoIP provider
X.
o As anybody on the Internet can contact any destination domain, no
business relationship between sender and destination domain is
required. This implies that there is no settlement: No money is
changing hands because of such a communication.
o There is no inherent distinction between end users and service
providers hard-coded into the protocol. Any client can do the DNS
lookups himself and directly contact the destination servers.
o Usually clients do not talk directly to each other: On the source
side a SIP INVITE is forwarded to the outbound proxy that applies
the routing algorithm, which then contacts its peer on the
destination side that also performs additional processing before
handing off the communication to the destination side.
Lendl Expires August 28, 2008 [Page 4]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
The email model has proved to be extremely successful -- for email.
3. Why is SPEERMINT needed?
In theory, the Speermint WG is not necessary: The SIP RFCs envision
global reachability of all SIP devices over the public Internet.
Source networks just need to resolve the domain from the URI
according to RFC 3263 and send the INVITE to the SIP proxy in charge
of that destination domain.
Telephone number (TN) based calling is also supported: RFC 3761 [1]
provides TN to URI mapping and thus reduces the call routing problem
to the already solved case of SIP URI resolution.
* Apparently, the real world did not choose to implement and deploy
SIP and public ENUM as initially envisioned by their inventors. In
other words: the motivation for Speermint is the failure of the world
to conform to the original IETF vision of SIP based real-time
communication. *
3.1. Why did the Email Model fail for SIP?
Although SIP has won the protocol war against H.323 (just as SMTP won
against X.400), it failed to establish the same sort of ecosystem in
the Internet as SMTP was able to do. The number of SIP users who are
reachable via the open Internet using RFC 3263 is minuscule compared
to the number of SIP based telephones in operation today.
SIP as a protocol has succeeded; SIP as an ecosystem similar to SMTP
has failed.
The need for Speermint arises from that failure: SIP has seen
widespread deployment within enterprises and service providers, but
the inter-connection part of SIP has not: current deployments usually
do not follow RFC 3263, but use either hard-coded IP addresses or
private DNS to route calls between SSPs, if they use SIP at all and
not the PSTN.
The same applies to ENUM according to RFC 3761: The technology has
been successful (as the large number of private ENUM trees
demonstrates), but the original vision of ENUM proved to be elusive:
the "golden tree" under e164.arpa contains a fraction of entries
compared to the numbers found in private trees.
Speermint is chartered to provide solutions for the interconnection
problem. It is thus essential to examine why the current standards
have failed. Without this gap-analysis there is little chance that
Lendl Expires August 28, 2008 [Page 5]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
Speermint will come up with the missing pieces.
As mentioned before, this analysis cannot be restricted to pure
technological aspects, and will thus touch on the business models
implied by the technical standards. It is the firm believe of the
author that the IETF credo "we don't do business models" has been
implicitly violated by existing standards. One approach is thus to
identify these implications and augment the protocols to allow them
to support a varity of business models and ecosystems.
Business Model
The email model hard-codes a "sender-keeps-all" settlement regime.
As anybody is able to connect to anybody, no business relationship
is needed between communication partners. Thus, no termination
fees can be collected.
The economic model of the current carrier landscape in most
countries depends on these charges, and it just does not make
sense for any single carrier to allow anonymous incoming SIP-based
interconnection as that means lost income. If call patterns are
about symmetrical, switching to sender-keeps-all is revenue-
neutral for all carriers. There is no clear path on how such a
fundamental shift in the bedrock of telco settlement could happen.
(other than by regulatory fiat)
The end-state might be a viable business model, but there is no
incentive for any individual SSP to start the transition.
This argument applies only to SSPs that are substitutes for PSTN
carriers, and not to enterprises operating a SIP infrastructure.
Unwanted Calls
Spam over Internet Telephony (SPIT) is another concern. The free
for all nature of the email ecosystem has led to a barrage of
unsolicited email (SPAM) which poses a serious threat to the
usefulness of email.
Email is non-interactive: filters can be deployed to detect spam
by the content of the mail before the recipient is alerted. That
is not possible for SPIT; content is only available after the
recipient has picked up the phone. A number of SPIT mitigation
strategies have been proposed over the past few years, their
effectiveness is yet untested. See also [6].
As of 2008, SPIT is not a problem, mainly because the number of
open reachable SIP devices is so low. Just as SPAM only started
Lendl Expires August 28, 2008 [Page 6]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
to become a problem after open SMTP servers became common, many
SSPs fear that SPIT will appear if they open up their networks.
Identity
Traditional telecom services provide reasonably reliable caller
identification. Telcos trust each other's signalling and end
users have learned to trust caller-id (even if this trust is
somewhat unjustified). Such a trust model is not compatible with
the email model of open SIP servers: the INVITE message can come
from any host on the Internet and is thus not trusted.
Providing a reliable caller identification is also important for
policing: Harassing and abusive calls are more or less under
control, as legal and contractual rules can be enforced by tracing
calls back to the culprit.
SIP Identity (RFC 4474 [5]) uses a different approach that is
based on an authentication service cryptographically asserting the
identity of the caller. As such, it is different to the current
practice in the telco space, which is based on transitive trust.
QoS and Denial of Service
The email model is not suitable for stringent Quality of Service
(QoS) deployments. As there are no pre-arranged relationships
with between all communicating SIP servers, there are no
mechanisms to guarantee neither network performance on the IP
layer for the actual voice transmission, nor can there be
comprehensive tests on SIP layer compatibility.
As the ingress points need to be open to anybody on the Internet,
they are exposed to Denial of Service attacks.
This combination is at odds with the telco mind-set that thrives
on predictable quality and stringent service level guarantees.
Legal Requirements
Operators of public telephony services need to observe a range of
regulatory requirements. These rules were written for the PSTN
scenario with clearly defined boundaries between operators and
users of the telephone network. Changing the interconnection
model make these regulations a bad fit for the email model.
For example, if the user requests CLIR (Calling Line
Identification Restriction) then its SSPs needs to differentiate
the call handling, whether the peering partner is another
Lendl Expires August 28, 2008 [Page 7]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
commercial SSPs (transmit caller-ID, signal CLIR) or an enterprise
(suppress caller-ID). Interconnecting with other SSPs that
operate under the same rules simplifies compliance.
3.2. The PSTN Model does not fit, either
It is of course possible to rebuild the PSTN based on SIP instead of
SS7. Some might argue that this is what the IMS and NGN efforts are
all about. This is selling SIP and the Internet short: The basic
infrastructure that the Internet offers allows for far more flexible
interconnection arrangements than a simple copy of the PSTN
structure.
Shared Layer 3 Infrastructure
The PSTN is based on trunk lines connecting voice switches. These
trunks are manually established between carriers. Each such link
needs physical ports, as well as, dedicated bandwidth.
Establishing direct links between carriers is thus only sensible
if call volumes can justify the effort.
In contrast to the point-to-point link world of the PSTN, SIP
assumes an any-to-any IP based communication model. This has a
profound impact on the economics of interconnection: A new peering
is not a matter of provisioning a new bit-pipe, but just one of
configuring border elements on both sides.
Economic theory states that there must be a optimal number of
peerings per SSP given the costs to establish an interconnection
versus the costs of transit. As the cost structure is
fundamentally different, the mesh density of the optimal SIP based
network will deviate significantly from the current PSTN.
Enterprise Peering
As a corollary: Peering between TDM-based enterprise telephony
systems is usually limited to very high traffic cross-links. As
enterprise-to-enterprise calls do not require settlement, there is
a huge potential for additional peering in this space.
Dynamic Routing
Worldwide routing in the PSTN is still based mainly on manually
established routes; these routes reflect business relationships.
As a consequence, it takes years to a get a new number range
routed in the PSTN. The switch from SS7 to SIP must be taken as a
chance to upgrade the worldwide call routing to a better routing
algorithm.
Lendl Expires August 28, 2008 [Page 8]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
4. Core Assumptions
The author believes that some working assumptions have to be re-
thought based on the feedback from current deployment.
4.1. The Real Problem with SPIT
SPIT and QoS/DoS issues have often been cited as reason why so few
people (enterprises and commercial SSPs) run an open SIP service
(i.e. accept SIP calls from the public Internet without pre-
association). The IETF has taken on the challenge and tried to
develop protocol extensions that should help with the SIP adoption.
These are often based on the following reasoning:
+------------+ +-------------+ +-------------+
|We want to | |They need to | |They have a |
|interconnect|===(1)===>|run open |===(2)===>|problem with |
|SSPs | |SIP servers | |SPIT and DoS.|
+------------+ +-------------+ +-------------+
A lot of time has been spent on step (2). Protocols and procedures
have been proposed to mitigate the exposure of open SIP proxies.
These include the consent framework for SIP, SPIT identification,
anti-SPIT policy rules, the Identity: header, etc.
These are all worthwhile proposals that solve certain symptoms.
Regrettably, they do not remove the roadblocks to widespread SIP-
based peering. For that, they tackle the wrong set of problems.
They assume that the email model can be successful and we just need
to make sure that all the associated problems are addressed.
This assumption is wrong. The author believes that it is necessary
to tackle step (1) first.
The question therefore should not be "How do we deal with the
unpleasant side effects of universal peering?", but "How can we get
SSPs to peer at all?". Instead of "How to keep out the unwanted
connects?" we should focus on "How can we entice willing partners to
a peering?".
4.2. What is a SIP URI?
SIP URIs are used in various contexts: They can specify contact
points (sip:user@10.0.0.1), they can specify next hop information in
a private interconnection setting
(sip:012345678@sbc1.chicago.us.example.net), and they can be public
SIP URIs (sip:alice@example.com) for which the responsible SIP proxy
Lendl Expires August 28, 2008 [Page 9]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
can be determined using RFC 3263.
There is yet another interpretation of the SIP URI that may be
relevant for Speermint: The URI as a simple identifier of a telephony
customer without the commonly implied semantic on how that user can
be contacted.
While that is close to the public URI, the difference is important:
RFC 3263 does not apply. There is no simple, globally valid set of
ingress points for calls towards that URI. The default SIP call
routing logic just is not applicable to such URIs.
In other words: It is a very useful concept to use the SIP protocol
and the URIs from RFC 3261 without also adopting RFC 3263, because
the latter more or less implies the email model that has not seen a
lot of deployment yet. It is thus expected that any SIP URI
published in a public infrastructure ENUM will not imply the
applicability of RFC 3263.
In order to place calls, some alternative to RFC 3263 needs to be
developed that accommodates the needs of carriers.
4.3. Peering vs. Reachability
Whatever the interconnection setup, subscribers of a telephony
service expect to be able to call all subscribes of all other SSPs.
When the email model cannot be assumed, this requires the use of
transit networks and thus some sort of routing mechanism to find a
path to the destination SSP.
4.4. The Key to Routing Data
Currently, the PSTN side is using telephone numbers (TN) as the key
to the routing information, whereas the RFC 3263 SIP uses the domain
name.
The TN used to be the perfect identifier for routing as the
hierarchical structure of the number corresponded to the network
topology in the PSTN. The emergence of alternative carriers, number
porting, and service numbers (free-phone, premium rate, ...) changed
that: This is a form of "locator" / "identifier" split.
Prefix-based routing used to be the way to aggregate routes to
telephone numbers in order to keep the routing tables and their
updates manageable. While that is still useful to encode policies
like "Route all of +43 to Carrier XYZ", within a country number
portability made prefix-based routing increasingly inefficient.
Lendl Expires August 28, 2008 [Page 10]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
Looking at the routing information from a database design point of
view, it does not make sense to store the set of possible routes
(incl. all meta-data like prices, capacity, quality,...) for every
individual number, as these will be identical for at least all
numbers operated by a single carrier in some area.
Any routing protocol will thus scale by several orders of magnitude
better if it is based on some sort of "Route-ID" that comprises a
carrier identification plus optionally a service or region-specific
tag.
While the telephone number is the starting point of the routing
information lookup, it is not a good identifier to use as the key for
storing routes.
4.5. Lookups vs. Announcements
Generally speaking, there are two ways how to distribute routing
information:
On Demand
Whenever routing information is needed some external database is
queried.
Example: DNS (including ENUM)
Pro-active Distribution
The information for all possible destinations is distributed
before the first routing decision is made.
Example: BGP, OSPF
There are of mixed models as well, e.g., when an organization gathers
routing information pro-actively to load an internal database that is
then queried on an "on-demand" basis by network elements.
Alternatively, some systems might pro-actively fetch the fraction of
the global routing information covering the most likely destinations,
and only fall back to on-demand queries for the rest.
The on-demand model requires a lower level transport infrastructure
to contact the external database. It's thus clear that Layer 3
routing cannot use that model as this leads to a chicken-and-egg
problem. However, for VoIP peering basic Internet connectivity can
be assumed and the same constraints do not apply.
The pro-active model on the other hand operates under a different
Lendl Expires August 28, 2008 [Page 11]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
constraint: Distributing all information needed for the routing
decisions to all carriers requires that the aggregate dataset size of
these routing information tables does not exceed sensible size
limits. For example, it is not feasible to replace the MX record
lookup of mail-servers by a routing protocol which replicates the
domain-name to mail-server mapping information to all ISPs and
enterprise mail-servers. There are just too many domains in use and
thus the "mail-routing tables" would exceed all practical limits.
With regards to TN based calls, both options are possible. ENUM
according to RFC 3761 is a clear on-demand approach. On the PSTN
side, downloads of database dumps are a common method to distribute
routing information.
A scalable routing system is needed, up to the set of all active TN.
They number in the billions. Installing a "full routing table" into
a core telephony (soft-)switch is thus not feasible. Current PSTN
implementations cope by crude aggregation of routes to foreign
countries.
The number of reachable IP addresses is roughly of the same order of
magnitude, but the aggregation properties of IP addresses reduces to
global routing table to under 500000 entries without any impact on
the quality of the routing decisions. Telephone numbers do not
aggregate as well and therefore makes a TN-based protocol in the
style of BGP infeasible (that is one reason why TRIP [4] failed).
The obvious solution is to add an on-demand mapping step ahead of the
routing protocol. That on-demand mapping should include the option
to seed a cache with the most likely destination TNs.
4.6. No National Solutions
Telecom regulation, especially concerning number assignments and
interconnection rules, is a national matter. Calling patterns favor
local destinations: local and national calls make up the majority of
all calls. It is thus not surprising that number based PSTN (and
some of the emerging VoIP-based) routing exchanges only deal with
numbers from a single country code.
On the other hand, international voice termination markets deal
usually not with individual numbers, but with routes to number
prefixes.
Given the increasingly international footprint of voice operators the
country-specific ways of handling inter-carrier routing is an
anachronism. Just as the Internet routing does not care about
national borders, there is no inherent reason why a single set of TN
Lendl Expires August 28, 2008 [Page 12]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
mapping and voice routing protocols cannot be seamlessly deployed in
an international setting. There should be no need for special
handling per country-code in the routing logic.
Consider the case of a pan-European mobile operator Foo. If Foo has
signed a peering agreement with a local Austrian VoIP operator Bar,
then Bar should pass all calls over this link that terminate in any
GSM network that Foo operates. Ideally, Bar should notice when a
number was ported to Foo's network in Germany and adapt the routing.
If Foo acquires a new network in, say Bulgaria, then Bar should
automatically route all calls to that set of numbers over the peering
with Foo. All this should happen without Bar having to participate in
Germany- or Bulgaria-specific TN database exchanges.
All this has been standard in Internet-based communication: both BGP,
as well as, application layer protocols like SMTP or HTTP do not care
about national borders. The protocol to resolve a .com name is the
same as the one to resolve within .cn. BGP speakers announce routes
without any regard for national borders. Speermint should strive to
achieve the same level of universality.
This does not preclude local optimizations. For example, if the
mapping from TN to some sort of routing identifier is done by
Infrastructure ENUM, then it makes sense to pro-actively prime the
SSP name-servers with the data for all local numbers.
5. Security Considerations
Not applicable at this stage of the discussion.
6. IANA Considerations
Not applicable.
7. Acknowledgements
The ideas expressed in this draft evolved during discussions with a
large number of people. Version -01 includes significant input from
Hannes Tschofenig.
8. References
Lendl Expires August 28, 2008 [Page 13]
Internet-Draft VoIP Peering: Background and Assumptions February 2008
8.1. Normative References
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[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.
8.2. Informative References
[4] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
over IP (TRIP)", RFC 3219, January 2002.
[5] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[6] Rosenberg, J. and C. Jennings, "The Session Initiation Protocol
(SIP) and Spam", RFC 5039, January 2008.
Author's Address
Otmar Lendl
enum.at GmbH
Karlsplatz 1/9
Wien A-1010
Austria
Phone: +43 1 5056416 33
Email: otmar.lendl@enum.at
URI: http://www.enum.at/
Lendl Expires August 28, 2008 [Page 14]
Internet-Draft VoIP Peering: Background and Assumptions February 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).
Lendl Expires August 28, 2008 [Page 15]