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]