Network Working Group J. Klensin Internet-Draft Expires: January 18, 2006 V. Cerf MCI S. Bradner Harvard University July 17, 2005 Registration Policies for the IETF and IANA draft-klensin-iana-reg-policy-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 January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract For many years, the IETF has maintained, via the IANA, registries of protocol and parameter names and numbers. The primary purpose of these registries is to ensure that different methods and options are properly identified and distinguished. Registration of such names or numbers generally does not necessarily imply approval of the Klensin, et al. Expires January 18, 2006 [Page 1] Internet-Draft Registration Policies July 2005 technology in the corresponding protocol. Instead, registration represents the desire to keep choices distinctly identified, separated, and public to avoid conflicts in use. In recent years, various changes in the nature of the instructions given to the IANA, increased perceptions of scarcity in the number spaces associated with some of the parameters, and other issues have led to a shift in emphasis from "registration to keep identifiers unique" toward evaluations of the quality of proposals for and preferences among protocols. This document argues that shift is undesirable. It articulates and clarifies the principles that the reasons for evaluation of registration requests is to ensure a minimum quality of definition, that any assertions of scarcity to restrict registrations must be accompanied by a plan for evaluating and, if appropriate, eliminating the scarcity problem, and that, if a "no scarcity" plan is not possible, to establish criteria for making decisions that are as specific and objective as possible. This document is intended to update the general considerations of RFC 2434, the specific allocation rules of RFC 2780, and the evaluation criteria associated with other documents that condition an IANA registration on Expert Review with IESG oversight or on IESG or IETF action. [[NOTE IN DRAFT: The length of this abstract exceeds the RFC Editor's recommended limits. It will be shortened in future versions, but the longer one is believed to be helpful for I-D announcements, etc.]] Klensin, et al. Expires January 18, 2006 [Page 2] Internet-Draft Registration Policies July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Registration Principle: Clarity of Definition . . . . . . . 6 3. Registration Principle: Allocating Scarcity . . . . . . . . 6 3.1 Scarcity in Parameter Spaces . . . . . . . . . . . . . . . 6 3.2 Scaling and Scarcity Reduction . . . . . . . . . . . . . . 7 3.3 Legitimacy of Registration Requests . . . . . . . . . . . 8 4. Multiple category or arc registrations . . . . . . . . . . . 8 5. Interpretation of Requirements for IESG Review or Standards Action . . . . . . . . . . . . . . . . . . . . . . 8 6. Reflections on 2434bis . . . . . . . . . . . . . . . . . . . 9 6.1 Designated Experts . . . . . . . . . . . . . . . . . . . . 9 6.2 Override Procedure . . . . . . . . . . . . . . . . . . . . 10 6.3 Denial of Service Attacks . . . . . . . . . . . . . . . . 10 6.4 Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Internationalization Considerations . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 9. Security considerations . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 A. Changes from previous version . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1 Normative References . . . . . . . . . . . . . . . . . . 11 11.2 Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Klensin, et al. Expires January 18, 2006 [Page 3] Internet-Draft Registration Policies July 2005 1. Introduction For many years, the IETF has maintained, via the IANA registries of protocol and parameter names and numbers. The original purpose of these registries was to ensure that different methods and options are properly identified and distinguished. Registration did not imply approval of the technology in the corresponding protocol. Instead, registration represented only the desire to keep distinct options identified, separated, and public to avoid conflicts. In recent years, the previous very general instructions to the IANA about registrations have been superceded by the inclusion of specific instructions in RFCs that define IETF protocols. These instructions have included rules for the establishment of the relevant registries themselves and details on how requests should be submitted, and new values defined, for any paramaters defined by the RFC. In addition a number of RFCs have been produced to provide instructions for IETF protocols that were defined before such instructions began to be included. Examples of those RFCs containing registration instructions include [RFC2780], [RFC2939], [RFC3171], [RFC3228], [RFC3383], [RFC3438], [RFC3474], [RFC3475], [RFC3476], [RFC3575], [RFC3737], [RFC3818], [RFC3968], and [RFC3969]. These instructions, coupled with increased perceptions of scarcity in the number spaces associated with some parameters, have led to a shift in emphasis from "registration to keep identifiers unique" and toward evaluations of the quality of proposals and preferences about protocol design. The distinction between requiring clarity and lack of obvious conflict in a registration and blocking one unless the quality of the underlying protocol was adequate was, in retrospect, further confused by [RFC2434] (which describes elements of the registration model) in different places, as o "To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority." (abstract, repeated in first paragraph of section 1) o "... preferred way of insuring review, and is particularly important if any potential interoperability issues can arise. [...] A new option may define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols on which they are built." (section 2) o "Even when the space is essentially unlimited, however, it is usually desirable to have a minimal review to prevent the hoarding of or unnecessary wasting of a space." (section 2) Klensin, et al. Expires January 18, 2006 [Page 4] Internet-Draft Registration Policies July 2005 RFC 2434 was used as the primary guideline for the RFCs listed above that define IANA considerations for particular protocols. All three of the above statements are consistent with other text in RFC 2434, but the intent of the review is left open. In other words, it specifies how a review is to be performed, but not the criteria to be used. The present document argues that the apparent recent shift from "evaluate a registration request for clarity and to avoid interoperability problems" is undesirable and explicitly sets out evaluation principles for registrations. While it may be completely reasonable to require some specific level of approval of a protocol with an associated parameter value, especially when the specification for that allocation explicitly designates IETF approval and endorsement (see Section 4), this should not be used as a justification to require "approval" of registrations in general. For registrations, the principal reasons for review are to ensure adequate quality in the definitions to permit interoperability, to avoid redundant or spurious registrations, and to provide those who request the registrations an opportunity for non-binding IETF community advice on the nature of the parameters being proposed for registration or the protocol elements associated with them. A secondary, but still important, reason involves verification that the proposed protocol does not contain elements that are likely to cause serious harm to the Internet. However, the threshold for rejecting a registration on the basis of "serious harm" should be very high and represent broad and obvious community consensus. This is the case first because there might otherwise be suspicion that a claim of harm was being used to try to block an unpopular protocol or to give a favored one some advantage. Second, from a registration standpoint, the best way to handle a dangerous protocol may be to give it clear and distinct parameter values so its effects can be easily and accurately identified and quarantined. It should also be clear from experience with Peer-to-Peer protocols and other that the IETF does not and cannot control introduction and use of "non-standard" protocols. So registration is in some sense only a courtesy to the community. P2P protocols freely violate norms on the use of particular protocol identifiers and parameters but since the software often has but a single source, there is no confusion FOR THOSE INSTANCES of the software that comes from the same source and uses the same "conventions" albeit non-standard and even conflicting with standards. This document articulates and clarifies the principles that (i) the reasons for evaluation of registration requests is to ensure a minimum quality of definition, (ii) any assertion of a danger to the Internet or to the stable operation of other protocols (especially IETF Standards Track ones) must by supported by a public discussion to which all relevant parties can contribute, and (iii) that any Klensin, et al. Expires January 18, 2006 [Page 5] Internet-Draft Registration Policies July 2005 assertions of scarcity to restrict registrations MUST be accompanied by a plan for eliminating the scarcity problem or a conclusion, supported by IETF consensus, that it is not possible to do so and a corresponding rationing plan for the remaining space. These principles derive from the assumption that growth and innovation on the Internet continue to be core values of the IETF and the Internet community. In summary, unless the "scarcity" rules of Section 3 apply, this document updates all "IANA registration" documents and "IANA considerations" sections of documents to clarify the point that registration review is to focus on the issues above, rather than on concerns about, e.g., whether one protocol approach is better than another one. 2. Registration Principle: Clarity of Definition By longstanding IANA tradition, almost all protocol number or parameter registrations must be associated with a description of what the parameter represents. As mentioned in RFC 2434, while those descriptions are normally public, the IETF and IANA have sometimes made provisions for non-public definitions. But, in all cases, the definitions must be sufficiently clear to avoid any interoperability problems. Over the years, IANA has regularly sent registration requests back to the originator for clarification. Today, part of the purpose of review of registration requests in the IETF is to make determinations about whether an appropriate level of clarity has been achieved and about whether the documentation supplied is adequate. 3. Registration Principle: Allocating Scarcity As suggested in section 2 of [RFC2434], the size of a name space in which parameters are to be allocated determines whether care must be taken "to insure that the space doesn't become exhausted". However, that level of care MUST NOT be interpreted or implemented in an attempt to apply a single standard of taste or style to the Internet or otherwise as a mechanism for attempting to suppress innovation. A limited space requires diligent evaluation of requests to avoid spurious or vanity registrations and unnecessary ones, including registrations that are unlikely to ever be used. However, unless extraordinary circumstances arise, such evaluation must be carried out on the assumption that the size of the name space is, and will remain, adequate for all legitimate registrations of values that will be used with the associated protocols. 3.1 Scarcity in Parameter Spaces The size requirements for a particular name space may occasionally be Klensin, et al. Expires January 18, 2006 [Page 6] Internet-Draft Registration Policies July 2005 underestimated, creating a requirement to minimize allocations and registrations in that particular name space to avoid a clear danger of running out of the space. If that situation arises for a particular name space, and its existence is confirmed by the IESG after an IETF review and Last Call as described in [RFC2026], then new registrations may be temporarily restricted to those required to meet the needs of IETF protocol development. However, such restrictions MUST NOT be applied without initiation of a plan to evaluate and, if appropriate, eliminate the scarcity, as discussed in the next subsection. 3.2 Scaling and Scarcity Reduction Difficulties with scaling are always a significant risk factor on the Internet, with regard to both protocol design and administrative procedures. When a parameter field is of fixed length, estimates must be made, sometimes under considerable uncertainty and with high costs associated with incremental size, as to how much parameter capacity is needed. If such an estimate is incorrect and a significant danger arises of running out of space, "conservation", i.e., restrictions on registrations or allocations to save space, will delay the date on which no further space is available, but will not eliminate the risk of that occurring. Because of the damaging effects on Internet innovation of rejecting otherwise-legitimate registrations because of name space exhaustion, a decision that a name space is facing a capacity crisis MUST BE made explicitly by the community, as outlined above, and MUST BE associated with a plan to expand the relevant name space unless that is deemed to be infeasible (see below). A plan to expand the name space MAY take the form of chartering a Working Group or creating an IAB workshop to develop a plan within an appropriate time, or other approaches may be used. A determination that the expansion of a name space is infeasible MUST include criteria for making allocations in the balance of the existing space and those criteria must be fair and balanced. The determination of infeasibility and the allocation plan MUST represent the consensus of the IETF community, determined through the same mechanisms used to approve a document as a BCP (see [RFC2026]). It is the explicit intent of this specification that registration requests not be rejected for reasons of name space shortages unless either an effort has been initiated to eliminate the shortage or a formal determination has been made by the community that it is infeasible or undesirable to do so. Nothing in this document should be taken as requiring that every limited name space must be expanded, only that careful consideration of what to do about the scarcity situation be initiated, and initiated in a way that is visible and accessible for community participation, immediately upon a Klensin, et al. Expires January 18, 2006 [Page 7] Internet-Draft Registration Policies July 2005 determination of scarcity and that the consideration process be diligently pursued until some consensus conclusion is reached. 3.3 Legitimacy of Registration Requests [[Note in Draft: This subsection is temporary.]] Obviously, it must be possible for the IANA and the registration evaluation process to protect against denial of service attacks by virtue of a perpetrator registering as many parameters as possible so as to exhaust the address space. Since that issue exists whether or not this specification is accepted, it should be addressed generally in RFC 2434bis and more specifically in individual registry specification documents or sections. See Section 6. 4. Multiple category or arc registrations In a number of cases, registration procedures or protocols have provided for registrations in a number of different categories, where those categories are associated with different levels of requirements for registration but where interoperability may be achieved by the use of any of the categories. Examples of this approach include the distinction between "user" and "system" port numbers most recently described in [RFC2780] and the distinctions among the various registration arcs for media type registrations described in [RFC2048]. A decision by the IESG or other designated party to require that a registration be made in a different arc or subsidiary name space than was proposed is not to be considered a rejection of the registration request under the terms of this document. 5. Interpretation of Requirements for IESG Review or Standards Action A requirement for IESG approval, Standards Action, or RFC Publication implies that IESG approval is an acceptable alternative to the other two, not an exceptional case unless the requirement contains additional provisions specifying the conditions for IESG review and approval. Because, for reasons discussed above, the action on a registration request SHOULD BE to permit the registration unless special circumstances apply, the IESG MUST NOT deny a registration request for other than reasons of clarity without an IETF Last Call and IETF consensus that the rejection is appropriate for identified reasons consistent with those discussed in this document. If a registration request is denied for any reason, that reason must be stated explicitly and the decision may be appealed under the procedures specified in [RFC2026] or its successor(s). Klensin, et al. Expires January 18, 2006 [Page 8] Internet-Draft Registration Policies July 2005 Inevitably, almost any of the procedures discussed above or in RFC 2434, may result in delays as the application is evaluated. In the spirit of community comment, input, and consensus, feedback to those requesting an allocation is desirable and is to be encouraged. Registration delays while such discussions are ongoing are entirely appropriate as long as they do not cause unreasonable delays once the feedback and discussion processes runs their effective course. Of course, nothing in this document prevents an applicant from voluntarily withdrawing a registration request at any time that is deemed appropriate. 6. Reflections on 2434bis A revision of RFC 2434, known as [RFC2434bis] is being developed. This section discusses some important interactions between the model of that document and the one presented here. 6.1 Designated Experts 2434bis is fairly non-specific about the amount of authority that is reasonably delegated and for what purposes. This document takes the position that individual decisions, taken out the view of the community, should be significantly constrained with regard to both subject matter and process. In particular, designated experts are seen as appropriate as managers of discussion and feedback and to evaluate clarity of a specification and not as a decision focus on the appropriateness of a protocol or registration request. An exception might be made when the expert is given specific guidance from the community, but this document views even that as a high-risk situation. More generally, designated experts are appropriate only in situations in which it is reasonable to assume that feedback --on both the registration and the underlying protocol is sought by those who request the registration and where that feedback is seen by all parties as an important part of the process. As one example, a designated expert may be an appropriate source or channel of advice to both the requester and other other review bodies on the clarity of a specification. The designation and use of such experts is not appropriate for registries that are, or are likely to be, associated with significant controversy (of which declared scarcity is almost always an instance). When controversies about registrations exist or can be anticipated, an open, public process with community involvement and practical opportunity for timely appeals is almost always more appropriate. Klensin, et al. Expires January 18, 2006 [Page 9] Internet-Draft Registration Policies July 2005 6.2 Override Procedure RFC2434bis-02 contains provisions for an override procedure in section 4.3. The position of this document is that, while such procedures may be necessary and appropriate, they should be exposed to full view of the community so that timely feedback and, if necessary, appeal is possible. Consequently, if the override procedure is invoked, the IESG should notify the community that it is being done and, unless the situation involves severe time constraints, at least a brief Last Call or other request for community comments should be conducted on the proposed action. 6.3 Denial of Service Attacks At least in principle, it is possible to attack any registry by attempting massive registration of names or parameters so as to use up all of the available space. 2434bis should address this issue, at least to the extent of recommending that specifications that establish registries advise on how such attacks are to be repelled for those registries. 6.4 Appeals RFC 2434bis prohibits appeals beyond the IAB. There appears to be little or no justification for barring such appeals if a claim is made that the procedures are flawed or inadequate. 7. Internationalization Considerations This document specifies IETF procedures and does not interact with internationalization. 8. IANA Considerations This document specifies IETF and IESG considerations in recommending actions to IANA. It recommends that, when the IETF concludes that the protocol, extension, or option associated with a registration request is problematic or dangerous, the entry in the IANA registry should be annotated to identify the concern and, when appropriate, point to documentation or other materials that will better explain the concern or alternatives that might be less problematic. While this document specifies no particular registry actions for IANA, IANA should be prepared for requests from the IETF to annotate registry entries in that way. 9. Security considerations This document specifies IETF procedures. It should have no direct Klensin, et al. Expires January 18, 2006 [Page 10] Internet-Draft Registration Policies July 2005 impact on Internet security. It does, however, firmly advocate the principle that it is preferable for options or extensions that could pose security or operational risks to be throughly documented and carefully identified in preference to hiding them and hoping that they will disappear. 10. Acknowledgements Comments were received on discussion leading to this document, or on a preliminary draft, from Bob Braden, Dave Crocker, Spencer Dawkins, Ned Freed, John Loughney, and others that contributed to text in this document and are greatly appreciated. Appendix A. Changes from previous version [[Note in draft: This section to be removed before RFC publication.]] Changes from -00. 1. Added new material to discuss impact with and on RFC2434bis as Section 6 2. Made several small changes to clarify that name space expansion is not a requirement, only that serious consideration of the issue be initiated as soon as scarcity is noted. 3. Made several small changes to clarify that delays in registration to obtain feedback and to discuss the registration with the requestor and the community are appropriate as long as they are not unreasonably prolonged. 11. References 11.1 Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 11.2 Informative References [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Klensin, et al. Expires January 18, 2006 [Page 11] Internet-Draft Registration Policies July 2005 [RFC2434bis] Narten, T. and B. Carpenter, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-02.txt (work in progress), June 2005. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000. [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001. [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, February 2002. [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002. [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002. [RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON)", RFC 3474, March 2003. [RFC3475] Aboul-Magd, O., "Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON)", RFC 3475, March 2003. [RFC3476] Rajagopalan, B., "Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling", RFC 3476, March 2003. Klensin, et al. Expires January 18, 2006 [Page 12] Internet-Draft Registration Policies July 2005 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. [RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules", RFC 3737, April 2004. [RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004. [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004. [RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004. Authors' Addresses John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com Vinton G. Cerf MCI 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 USA Phone: +1 703 886 1690 Email: vinton.g.cerf@mci.com Klensin, et al. Expires January 18, 2006 [Page 13] Internet-Draft Registration Policies July 2005 Scott Bradner Harvard University 29 Oxford St Cambridge, MA 02138 US Phone: +1 617 495 3864 Email: sob@harvard.edu Klensin, et al. Expires January 18, 2006 [Page 14] Internet-Draft Registration Policies July 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. Klensin, et al. Expires January 18, 2006 [Page 15]