Internet DRAFT - draft-lendl-sip-peering-policy
draft-lendl-sip-peering-policy
Network Working Group O. Lendl
Internet-Draft enum.at
Expires: June 25, 2006 December 22, 2005
Publishing SIP Peering Policy
draft-lendl-sip-peering-policy-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 June 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This documents proposes the use of DNS entries to publish a SIP
proxy's policy for accepting incoming calls. Such published policies
can be used to selectively establish peering relationships between
VoIP service providers.
Lendl Expires June 25, 2006 [Page 1]
Internet-Draft SIP Peering Policy December 2005
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Federations . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Publication of per-Domain Policies . . . . . . . . . . . . . 7
6. Resource Records . . . . . . . . . . . . . . . . . . . . . . 8
6.1 Federation Membership . . . . . . . . . . . . . . . . . . 8
6.2 Technical Restrictions . . . . . . . . . . . . . . . . . . 9
6.3 Interpretation rules . . . . . . . . . . . . . . . . . . . 10
7. The Big Picture . . . . . . . . . . . . . . . . . . . . . . 11
7.1 Relation to Infrastructure ENUM . . . . . . . . . . . . . 11
7.2 Call Processing Algorithm . . . . . . . . . . . . . . . . 12
7.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1 Normative References . . . . . . . . . . . . . . . . . . 14
11.2 Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Lendl Expires June 25, 2006 [Page 2]
Internet-Draft SIP Peering Policy December 2005
1. Terminology
This document uses the terminology as defined in
draft-meyer-voipeer-terminology-01.txt [5].
The acronym VSP will stand for "VoIP Service Provider".
FIXME: Nothing in this document requires VSPs to be commercial
service providers, the same principles and algorithms apply to
enterprises and private SIP proxies as well. Depending on the
discussions in the SPEERMINT WG, later revisions of this draft may
thus use the term Internet Telephony Administrative Domain (ITAD)
instead of VSP.
2. Introduction
Open and standard-compliant SIP services on the Internet are per
definition interoperable, hence 'interconnected'. No extra work
needs to be done to route calls between these services as long as the
user is able to enter full SIP URIs. If the user-interface is
restricted (e.g. by using an analogue telephone adaptor in
combination with a 12-key telephone) then ENUM as defined by RFC 3761
[1] can be used to map telephone numbers to SIP URIs.
PSTN replacement services usually use a sequence of digits as the
dial-string and not SIP URIs. These digits can be translated to
E.164 [4] numbers, thus ENUM could be used to interconnect two such
services on a VoIP basis. Due to a variety of technical, political,
and commercial reasons these services often do not assign public SIP
URIs to their customers and do not accept incoming SIP calls from the
Internet. Such services usually use the PSTN as the default network
for voice interconnection.
Interconnecting two VoIP services via the PSTN is wasteful:
o Voice quality is degraded by repeated transcoding.
o Service limitation: IM, presence and video capabilities are lost
during PSTN transit.
o PSTN transit is usually charged by the minute.
The original SIP framework is similar to electronic mail: all SIP
URIs are resolvable via DNS and the associated SIP servers are
reachable via the public Internet. As the model email shows, this is
a powerful and open architecture which does not distinguish between
the servers of a service-provider, an enterprise or a private person.
This model has shown to have several drawbacks as well:
Lendl Expires June 25, 2006 [Page 3]
Internet-Draft SIP Peering Policy December 2005
SPAM
As anybody can send email from any computer connected to the
Internet unwanted communication of questionable motives are a
plague.
Sender Identity
There is no technical protection build into the system which
guarantees the authenticity of sender identity. This is widely
exploited both by email worms, phishing and other frauds.
Right now, there is extensive work being done to combat these
problems of the open email system. These fixes usually work be
restricting the openness of email and by adding cryptographic
signatures to email.
There are some interesting proposals regarding end-to-end
authentication in the SIP context as well:
draft-ietf-sip-identity-06.txt [6] is one example.
The PSTN uses a different mode: carriers trust each other and each
carrier is supposed to authenticate and police its own customers.
As VoIP services are starting to build interconnections they are
trying to avoid the pitfalls of a completely open interconnection
regime. Implementing User ENUM as described in RFC 3761 is a binary
choice: Either you publish the SIP URIs and operate an open SIP
server or you don't. There is no middle ground where a service-
provider can announce that he is willing to accept some incoming
calls via SIP but will reject others. The protocol described in this
document is designed to publish such policy choices in an
interoperable fashion by means of the DNS.
Over the last years, a number of companies have established SIP
peering fabrics based on either private ENUM trees or SIP redirect
proxies. These services solve the problem of interconnection between
members but have scaling issues when a VSP wants to participate in
more than one of such services.
There is thus a need to introduce a generic approach to these ad-hoc
peering solutions. The main aim needs to be to avoid a sequential
trying of peering fabrics. Instead, a simple query needs to suffice
to tell the originating network whether peering is possible and which
peering framework it can use to route a call.
Lendl Expires June 25, 2006 [Page 4]
Internet-Draft SIP Peering Policy December 2005
3. Requirements
A system for selective VoIP interconnection needs to fulfill the
following requirements:
Unified solution for all peering policies
The method shall be extensible to cover existing and future
peering policies. These start by a closed system which accepts
only incoming calls from selected peers (i.e. a set of bilateral
peerings) and include the model of membership in a number of
peering fabrics or carrier clubs. The case of an open SIP proxy
should be covered as a special case as well.
Domain Based
Although the initial call routing may be based on E.164 numbers a
generic peering method should not rely on numbers but rather on
URIs. We assume that all SIP URIs with the same domain-part share
the same set of peering policies, thus the domain of the SIP URI
may be used as the primary key to any information regarding the
reachability of that SIP URI.
No blocked calls
An originating VSP shall be able to determine whether a SIP URI is
open for direct interconnection without actually sending a SIP
INVITE. This is important as unsuccessful call attempts are
highly undesirable as they can introduce high delays due to
timeouts and can act as an unintended denial of service attack.
(e.g. by repeated TLS handshakes)
Scaling
The maintenance of the system needs to scale beyond simple lists
of peering partners. It needs to incorporate aggregation
mechanisms to avoid scaling with O(n*n), where n is the number of
participating VoIP services. Per-VSP opt-in without consultation
of a centralized 'peering registry', but rather by publishing
local configuration choices only is highly desirable. The
distributed management of DNS is a good example for the
scalability of this approach.
Independence of lower layers
The system needs to be independent of details on what technologies
are used route the call and which are used to ensure that only
approved peering partner actually connect to the destination SIP
Lendl Expires June 25, 2006 [Page 5]
Internet-Draft SIP Peering Policy December 2005
proxy. It should not matter whether restrictions are implemented
by private L3 connectivity ("walled gardens"), firewalls, TLS
policies or SIP proxy configuration.
Administrative and technical policies
The reasons for declining vs. accepting incoming calls from a
prospective peering partner can be both administrative
(contractual, legal, commercial, or business decisions) and
technical (certain QoS parameters, TLS keys, domainkeys, ...).
The method should accommodate all conceivable policies.
Minimal additional cost on call initiation
Since each call setup implies execution of the proposed algorithm
it should incur minimal overhead and delay, and employ caching
wherever possible to avoid extra protocol roundtrips.
Look beyond SIP
The problem of selective peering is not limited to SIP-based
communication. Other protocols may benefit from a generic
framework as well, such as SMTP mail. The proposed system thus
should be generic enough to encompass other protocols as well.
4. Federations
The proposed method is based upon the concept of a "Federation". A
federation in this context is defined as follows:
A Federation is a group of VoIP service providers which
* agree to receive calls from each other via SIP,
* agree on a set of administrative rules for such calls
(settlement, abuse-handling, ...), and
* agree on specific rules for the technical details of the
interconnection.
This document does not define what these rules can be and how they
are communicated to all members of a federation. There is no
requirement to make those rules public.
Federations shall use fully qualified domain names as their
identifiers.
All SIP service providers are assumed to be a member of a federation
with the same name as their domain.
Lendl Expires June 25, 2006 [Page 6]
Internet-Draft SIP Peering Policy December 2005
The federation named "." (just a dot, the empty domain) stands for
the public Internet. A SIP service provider who announces his
membership in "." will accept calls as defined in the generic SIP
standard documents.
FIXME: Or perhaps use URIs as in XML name-spaces instead of domains.
Examples:
o A set of VoIP service providers form an association and agree to
accept calls from each other via the public Internet as long as
the SIP call uses TCP/TLS as transport protocol and presents a
X.509 cert which was signed by the association's own CA.
o A set of VoIP service providers build a L3 network dedicated to
VoIP peering ("walled garden", similar to the 3GPP GRX network).
They agree to accept calls from all participants in that network
and bill each other via a clearinghouse.
o A set of VoIP service providers agree to accept calls originating
from within the same country. They use a set of firewall rules to
block calls from abroad.
o Peering fabric based on SIP: A company sets up a SIP proxy which
acts as a forwarding proxy between the SIP proxies of all
participating VSPs. The group of these VSP form a federation
whose technical rules state that calls have to be routed via that
central proxy.
5. Publication of per-Domain Policies
The domain part of the destination SIP URI is the natural key for the
peering policy of the SIP proxy serving that domain. It is thus a
sensible choice to publish the policy for incoming calls towards a
SIP URI in the DNS zone of its domain.
There are two types of policies a VSP may advertise:
o A list of federations which this domain belongs to.
Federations are identified by domain names thus this is a list of
domains.
If a VSP announces its membership in a federation, it declares
that it will accept calls originating from all other members of
that federation. There is no need to announce technical details,
as members of that federation already are assumed to know how to
talk to each other.
Lendl Expires June 25, 2006 [Page 7]
Internet-Draft SIP Peering Policy December 2005
o Technical requirements for contacting the SIP proxy serving this
domain.
This is similar to RFC 3263 [3], but with an important
distinction: The premise of RFC 3263 is universal connectivity
between SIP services. In that context, the aim is to select the
best transport protocol for SIP and determine the correct IP
address and port. The aim here is different: universal
connectivity is NOT assumed, rather the protocol is used to
determine whether a connection is possible in the first place.
There are no defaults to fall back to.
Publishing technical requirements are a way of expressing "I don't
usually accept calls from the Internet, but if you can do X or (Y
and Z) then I'll accept your calls.". Such policy announcements
are independent of any federation rules: they cannot be used to
alter the technical rules of a federation.
6. Resource Records
FIXME: the RRs described are here to illustrate the basic idea.
Suggestions on the format are explicitly welcome.
SIP proxies following the optional parts of RFC 3263 already query
for NAPTR records in the destinations domain. Adding SIP peering
policy information in NAPTRs increases the size of the DNS response
but does not incur an extra network roundtrip.
To accomodate these larger DNS responses is it recommended that these
lookups utilize EDNS0 to avoid fallbacks to TCP queries. FIXME: make
EDNS0 mandatory as in [8]?
6.1 Federation Membership
The following NAPTR records indicate federation memberships of the
SIP proxy serving this domain:
Lendl Expires June 25, 2006 [Page 8]
Internet-Draft SIP Peering Policy December 2005
; order pref flags service regexp replacement
IN NAPTR 10 50 "p" "D2F+SIP" "" voip.vix.at.
IN NAPTR 20 50 "p" "D2F+SIP" "" voip.example.com.
;
; Interpretation:
;
; This VSP prefers calls under the rule of voip.vix.at but
; will also accept calls from other members of the
; voip.example.com federation.
;
; Calls from the public Internet will not be accepted.
;
Figure 1
o FIXME formal spec.
o FIXME flags? 'p' for "policy"
o FIXME service? D2F stands for "domain to federation". If we use
URIs as namespace, then "D2U+FED:SIP" could be possible.
o FIXME do we want more than one federation in one NAPTR, e.g.
"voip.vix.at+xconnect.com" to save space in he NS answer? In that
case we need to use the regexp field and not the replacement.
o FIXME if we use URIs for federation Ids, then they move into the
regexp as well.
The order/preference fields are used to indicate a preference under
which federation's rules it prefers to receive the call.
6.2 Technical Restrictions
RFC 3261 mandates support for TCP, TLS and UDP in all SIP proxies.
RFC 3263 builds on that. Quote:
If a SIP proxy, redirect server, or registrar is to be contacted
through the lookup of NAPTR records, there MUST be at least three
records - one with a "SIP+D2T" service field, one with a "SIP+D2U"
service field, and one with a "SIPS+D2T" service field.
This "MUST" needs to be reconsidered in this context, as it forces
VSP to accept calls over unsecured SIP transports.
Parts of the technical policies (e.g. "we accept only calls via TCP/
TLS") can be expressed with the means of RFC 3263, others (e.g.
"domainkeys are required", "sip-indentity-signatures required")
cannot.
FIXME There needs to be a consensus on how to express which
algorithms are required. This name-space needs to be defined and
administered. (IANA? URNs like in XML-DSIG?)
Lendl Expires June 25, 2006 [Page 9]
Internet-Draft SIP Peering Policy December 2005
The syntax must be expressive enough to say ((ALG1 and ALG2) or (ALG3
and ALG4)).
Proposed syntax:
; order pref flags service regexp replacement
IN NAPTR 10 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:identity!" .
IN NAPTR 10 51 "p" "D2P+SIP" "!.*!urn:ietf:sip:calist:THAWTE+FREECA!" .
IN NAPTR 20 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:domainkeys!" .
IN NAPTR 20 51 "p" "D2P+SIP" "!.*!urn:ietf:sip:TLS!" .
;
; Interpretation:
;
; This VSP will accept calls from the public Internet if
; the request is signed according to SIP-Identity using certs
; signed by THAWTE or FREECA.
;
; Alternatively,
;
; calls arriving via TLS and signed with domainskeys are
; accepted as well.
;
Figure 2
o FIXME formal spec.
o FIXME flags? Still 'p' for policy?
o FIXME service? D2P stands for "domain to policy". As we use URNs
as namespace, things like "D2U+POLICY:SIP" could be possible.
o FIXME RFC 3263 uses "SIP+D2U", "SIP+D2T" and "SIP+D2S". ENUM uses
the service in a reverse way, e.g. "E2U+sip" or "E2U+H323". Do
we go with the ENUM example or the RFC3263 precedent?
6.3 Interpretation rules
o If no NAPTR records as defined by this document are found in the
target domain, then the normal rules according to RFC 3263 apply.
o If a domain announces its memberships in the special federation
"." then it will accept calls under the RFC 3263 regime.
o If a domain announces membership in multiple federations, then it
will accept calls according to the rules of each federations. If
a VSP participates in one or several private peering fabrics and
accepts calls from the public internet as well, then it needs to
announce membership in those federations and in ".".
o For the purpose of the call routing algorithm, technical
restrictions can be regarded as ad-hoc federation definitions.
All entries with the same priority field taken together act as the
definition of a federation which uses the public Internet as the
Lendl Expires June 25, 2006 [Page 10]
Internet-Draft SIP Peering Policy December 2005
Layer 3 network and where SIP proxies conform to these
restrictions.
o If technical restrictions and federation memberships are
announced, then an originating VSP can use either the federation's
rules or the public Internet with the appropriate protocols to
make the call.
o RRs for technical restrictions cannot be used to modify the rules
of a federation.
7. The Big Picture
7.1 Relation to Infrastructure ENUM
Private VoIP interconnection fabrics as they are in operation right
now do a good job of facilitating the peering if the originating VSP
selects the right fabric for each call. As long a VSP only
participates in two or three such fabrics sequential trying of these
fabrics may be feasible. The delays caused by unsuccessful dips add
up and a disruption of any one such service can impact the overall
call processing times. Parallel querying of all peering systems is
an option to cope with multiple peering system, but this does
increase the complexity of the call processing.
Each peering dip into any fabric's routing logic answers the
following questions:
1. Is the destination reachable via SIP in the context of this
fabric?
2. What call setup method and parameters should I use? (e.g. use
TLS? Which cert to present? Route the call via a special SBC?
Do some L3 magic to ensure QoS?)
There is reason to assume that the proliferation of VoIP peering
points will be similar to that of layer 3 peering points. A larger
VSP might thus be participating in a significant number of such
fabrics.
If we split up the dip from above into
1. Is the destination reachable via SIP at all?
2. Will the destination network accept calls from me?
3. What call setup method and parameters should I use?
then the first two can be be implemented with a public lookup which
is unified over all peering fabrics. Infrastructure ENUM will take
care of the first point. This document defines a solution for the
Lendl Expires June 25, 2006 [Page 11]
Internet-Draft SIP Peering Policy December 2005
second.
The third item can well be implemented in a propriety and private
fashion.
7.2 Call Processing Algorithm
E.164 Based calling:
1. Collect the dial-string from user
2. Apply the dial-plan to get an E.164 number
3. Use ENUM to map the number to a SIP URI (perhaps using
draft-haberler-carrier-enum-01 [7])
4. Query for NAPTR records in the domain of the SIP URI
5. If neither "D2F+SIP" nor "D2P+SIP" entries are found, then the
destination proxy does not support policy announcements as
defined by this document. Route the call according to RFC 3263
(i.e. query for SRV, then A records).
6. Group all "D2P+SIP" entries by the order field. Create a list
containing these groups, a "D2F+SIP" entry with the
destination's domain and order 0, and all "D2F+SIP" entries from
the DNS. Sort this list according to the order field.
7. Loop over this sorted list (lowest order first). For each entry
try:
8. If the entry is of type "D2F+SIP", check if the federation of
this record is in the the originating SIP service provider's own
list of federations (which includes "." if the originating VSP
chooses to do termination to open SIP proxies). If yes, try to
complete the call according to the well-known rules of that
federation. If for some reason this does not work as
advertised, continue with the algorithm.
9. If the entry is a group of "D2P+SIP" records, check if all
technical restrictions can be met. If yes, place the call using
that specifications. Once again, if this does not work as
advertised, continue with the algorithm.
10. [end of loop]
11. If no usable entries have been found, then this call cannot be
routed via SIP.
URI based calls start with step 4.
7.3 Examples
In all the following examples, a private peering arangement between
the calling and the called VSP takes precedence over all other
options.
Lendl Expires June 25, 2006 [Page 12]
Internet-Draft SIP Peering Policy December 2005
One federation
$ORIGIN example.com
; order pref flags service regexp replacement
IN NAPTR 10 50 "p" "D2F+SIP" "" voip.vix.at.
IN NAPTR 20 50 "p" "D2F+SIP" "" .
;
In this case, example.com announces that it prefers calls via the
"voip.vix.at" framework, but is also willing to accept calls from
the Internet.
Federations and technical restrictions
; order pref flags service regexp replacement
IN NAPTR 10 50 "p" "D2F+SIP" "" voip.vix.at.
IN NAPTR 20 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:domainkeys!" .
;
In order to contact the SIP proxy for example.com, the originating
SIP proxy must either use the "voip.vix.at" framework (preferred)
or use a domainkeys-signed request over the public Internet.
Federations and complex technical restrictions
; order pref flags service regexp replacement
IN NAPTR 10 50 "p" "D2F+SIP" "" voip.vix.at.
IN NAPTR 20 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:TLS!" .
IN NAPTR 20 51 "p" "D2P+SIP" "!.*!urn:ietf:sip:calist:THAWTE!" .
IN NAPTR 30 50 "p" "D2F+SIP" "" voip-exchange.example.org.
;
In this example, the sending VSP has the following options:
1. Use the rules of "voip.vix.at" (preferred).
2. Connect via the public Internet using TLS with a cert signed
by THAWTE.
3. Use the rules of "voip-exchange.example.org".
8. Security Considerations
The NAPTRs proposed here publish information which is not public if
VSP just rely on private interconnection agreements. These records
are similar to the public routing registries for BGP4 as maintained
by the RIRs. They are just records indicating who peers with whom
but do not hold details on how the interconnection is achieved.
Lendl Expires June 25, 2006 [Page 13]
Internet-Draft SIP Peering Policy December 2005
The published technical requirements for incoming calls could be used
by malicious callers to find possible attack vectors. This should be
a non-issue for all VSP who do not rely on security-by-obscurity.
The publishing of the peering policy via the DNS RR described in this
draft will reduce the number of unwanted calls, as all well-meaning
VSP will follow them, but these records cannot substitute measures to
actually enforce the published peering policy.
9. IANA Considerations
FIXME: This document defines an IANA registry for the technical
restrictions fields.
FIXME: This document registers the protocol fields XXXX in NAPTRs.
10. Acknowledgements
The author would like to thank Michael Haberler, Alexander Mayrhofer,
Richard Stastny, and John Todd for their contributions.
11. References
11.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.
11.2 Informative References
[4] ITU-T, "The international public telecommunication numbering
plan", Recommendation E.164, May 1997.
[5] Meyer, D., "Terminology for Describing VoIP Peering and
Interconnect", draft-meyer-voipeer-terminology-01 (work in
progress), October 2005.
[6] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
Lendl Expires June 25, 2006 [Page 14]
Internet-Draft SIP Peering Policy December 2005
[7] Haberler, M. and R. Stastny, "Combined User and Carrier ENUM in
the e164.arpa tree", draft-haberler-carrier-enum-01 (work in
progress), October 2005.
[8] Conroy, L. and J. Reid, "ENUM Requirement for EDNS0 Support",
draft-conroy-enum-edns0-01 (work in progress), October 2005.
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 June 25, 2006 [Page 15]
Internet-Draft SIP Peering Policy December 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lendl Expires June 25, 2006 [Page 16]
