Network Working Group L. Andersson Internet-Draft Acreo AB Expires: May 23, 2005 A. Farrel Olddog consulting G. Swallow Cisco Systems K. Kompella Juniper Networks A. Zinin Alcatel November 22, 2004 MPLS and GMPLS Change Process draft-andersson-rtg-gmpls-change-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 May 23, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Andersson, et al. Expires May 23, 2005 [Page 1] Internet-Draft MPLS and GMPLS Change Process November 2004 The MPLS and GMPLS protocol suites have become quite popular for a growing number of applications and deployment scenarios. One result of this popularity is a large number of suggestions for modifications and extensions. The IETF needs to be flexible and responsive in how it handles these suggestions, and has a responsiblity to supervise the growth and evolution of MPLS and GMPLS protocols. This memo describes the process through which individuals, working groups and external standards bodies can influence the development of the MPLS and GMPLS standards. This process means that extensions and changes to protocols specified by these working groups can only be made through the IETF, the body that created the (G)MPLS ((Generalized) Multiprotocol Label Switching) technologies. Andersson, et al. Expires May 23, 2005 [Page 2] Internet-Draft MPLS and GMPLS Change Process November 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Managing the (G)MPLS technology in the IETF . . . . . . . . . 5 2.1 Multiprotocol Label Switching Working Group . . . . . . . 5 2.2 Common Control & Measurement Plane Working Group . . . . . 6 2.3 MPLS and CCAMP cooperation . . . . . . . . . . . . . . . . 7 2.4 Other (G)MPLS technology working groups . . . . . . . . . 7 2.5 Routing Area and Routing Area working groups . . . . . . . 8 2.6 Organizations outside the IETF . . . . . . . . . . . . . . 8 2.7 Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3. MPLS and GMPLS Change Process . . . . . . . . . . . . . . . . 10 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Initiating changes or extensions to (G)MPLS protocols . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2 Problem statement review . . . . . . . . . . . . . . . 11 3.2.3 Charter update . . . . . . . . . . . . . . . . . . . . 11 3.2.4 Problem statement evaluation . . . . . . . . . . . . . 12 3.2.5 Not accepted requirements . . . . . . . . . . . . . . 13 4. Extensibility and Architecture . . . . . . . . . . . . . . . . 15 5. (G)MPLS protocols . . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 8.2 Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 20 Andersson, et al. Expires May 23, 2005 [Page 3] Internet-Draft MPLS and GMPLS Change Process November 2004 1. Introduction This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS related standards. This process means that (G)MPLS extensions and changes can only be done through the IETF, the body that created the (G)MPLS technology. In particular the MPLS and/or CCAMP Working Groups need to be involved in the process. The IETF will not endorse publishing (G)MPLS technology extension RFCs that did not follow the processes described here. If publication of individual Internet-Drafts requesting extensions or changes the (G)MPLS protocols by the RFC Editor are requested they will looped back through the process described in this document. IANA has allocation policies for all of the code point registries it manages. In many cases, IANA will refer back to the IETF when asked to make an allocation. In the case of changes or extensions to the (G)MPLS protocols, the process described in this document will be used to judge whether or not a code point allocation that should be made. The (G)MPLS technology is developed in two main tracks in the IETF. "MPLS" refers to the work done for packet switched networks, while the "GMPLS" refers to the efforts to apply the MPLS protocols to all types of networks. Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" is used to indicate both of these tracks. A terminology section that covers the use of terms and concepts used in this document is found in Section 2.7. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Andersson, et al. Expires May 23, 2005 [Page 4] Internet-Draft MPLS and GMPLS Change Process November 2004 2. Managing the (G)MPLS technology in the IETF This section outlines the applicability of the (G)MPLS change process specified in this document. It lists the key IETF working groups developing the (G)MPLS technology, examples of IETF working groups using the (G)MPLS technology and possible parties interested in using, extending or changing the (G)MPLS technology. A terminology local to this document that will be used in specifying the change process is also included. Currently there are two working groups in the IETF Routing Area working on the (G)MPLS technology. The Multiprotocol Label Switching (MPLS) working group and the Common Control and Measurement Plane (CCAMP) working group. This section (Section 2) gives an overview of the work these IETF working groups are currently chartered to do, and some of the working groups that use the (G)MPLS technology. It should be remembered that the IETF environment is highly dynamic, working groups and whole areas come and go. The overview of the IETF structure is only a snapshot in time. 2.1 Multiprotocol Label Switching Working Group The Multiprotocol Label Switching (MPLS) working group is responsible for standardizing the base technology for using label switching and for describing the implementation of label-switched paths over various packet and frame-based link level technologies. The working group charter includes procedures and protocols for the distribution of labels between routers, as well as encapsulations, operation and management, traffic engineering and multicast considerations. When the (G)MPLS technology was broken out to be developed by multiple working groups, one of the assumptions was that for changes and extensions to the existing MPLS protocols the MPLS working group should accept requirements, relevant to protocols specified by the MPLS working group or for work items on the working group charter, from other working groups. The MPLS working group also accepts requirements from other sources, e.g., individuals or external standards bodies. Such requirements SHALL be sent to the working group in the form of Internet-Drafts. Documents that propose extensions or changes to the MPLS protocols, e.g. those that specify new MPLS methods or new MPLS encapsulations MUST be handled according to the processes described in this document by the MPLS working group or by the MPLS Designated Expert (a.k.a. caretaker) appointed by the IESG if the MPLS working group has been Andersson, et al. Expires May 23, 2005 [Page 5] Internet-Draft MPLS and GMPLS Change Process November 2004 closed. One exeception to this rule is when other IETF working groups has been appointed, in accorance with the process descrbide in this document, to handled extensions and/or changes to the protocols specified by the MPLS working group. 2.2 Common Control & Measurement Plane Working Group The IETF Common Control and Measurement Plane (CCAMP) working group coordinates the work within the IETF defining a common control plane and a separate common measurement plane for ISP and SP core tunneling technologies. This includes, but is not limited to, defining signaling protocols and measurement protocols such that they support multiple physical path and tunnel technologies using input from technology- specific working groups such as the MPLS working group; protocol-independent metrics and parameters for describing links and paths that can be carried in protocols. The technology that the CCAMP Working group focuses on is sometimes called Generalized MPLS (GMPLS), indicating that CCAMP addresses a generalized technology, where labels are defined in such a way that they will be compatible with the technology they are transported over. While the MPLS working group focuses on packet- and frame-switched technologies, the CCAMP working group work focuses on common methods accross a broad spectrum of switching technologies. In this respect GMPLS can be viewed as a superset of MPLS. When the (G)MPLS protocols were broken out to be developed by multiple working groups one of the assumptions was that the CCAMP working group should take input in the form of requirements from other working groups. The CCAMP Working group is also open for requirements from other sources, e.g., individuals or external standards bodies. Such requirements SHALL be sent to the working group in the form of Internet-Drafts. Documents that propose extensions or changes to protocols that have been specified by the CCAMP working group, e.g., documents that specify new GMPLS methods and new GMPLS encapsulations MUST be handled according to the processes described in this document by the CCAMP working group or by the GMPLS Designated Expert (a.k.a. caretaker) if the CCAMP working group has been closed. One exeception to this rule is when other IETF working groups has been appointed, in accorance with the process descrbide in this document, to handled extensions and/or changes to the protocols specified by the CCAMP working group. Andersson, et al. Expires May 23, 2005 [Page 6] Internet-Draft MPLS and GMPLS Change Process November 2004 2.3 MPLS and CCAMP cooperation From time to time the MPLS and CCAMP working groups decide to divide work between themselves in a way that does not always strictly follow the split between the working groups as defined in the working groups charter. This is the case, e.g. for P2MP TE LSP's, where the MPLS working group is specifying requirements and base technology for all of the (G)MPLS area. An entity or individual that wishes to propose extensions or changes to (G)MPLS should first decide to which Working Group (MPLS or CCAMP) it will bring the proposal. However, the MPLS and CCAMP WG chairs, in conjunction with their Area Directors, MAY redirect the proposal. 2.4 Other (G)MPLS technology working groups There have been several working groups working on (G)MPLS requirements, e.g., the IP over Optical (IPO) working group and the Internet Traffic Engineering Working Group (te-wg). These working groups have not specified any protocols, but have been a source of requirements to be considered by the (G)MPLS working groups. Other working groups, e.g. the Bidirectional Forwarding (BFD) working group also use the (G)MPLS protocols and mechanisms, and when this involve extending and/or changing the protocols specified by the (G)MPLS working groups, this has to be submitted to the working group that originally specified the protocol in the form of an Internet-Draft. The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have been chartered to specify a limited number of solutions for Provider Provisioned VPN's. Both working groups are in the Internet Area. It is assumed that the work of L2VPN and L3VPN does not include specifying new protocols, however, should protocol changes and/or extensions be made to protocols specified by the (G)MPLS working groups, these changes and/or extensions SHALL be submitted to the (G)MPLS working group that originally specified the protocol in the form of an Internet-Draft. The Pseudo Wire Emulation End to End (PWE3) working group is a working in the Internet Area that also uses the (G)MPLS protocols in its specifications. Should the PWE3 specifications require extension and/or changes to the (G)MPLS protocols these changes and/or extensions SHALL be submitted to the (G)MPLS working group that originally specified the protocol in the form of an Internet-Draft. It is assumed that the change process for the MPLS and CCAMP Working groups, specified in this document, will be applicable or at least adaptable to other (G)MPLS technology working groups if such a need Andersson, et al. Expires May 23, 2005 [Page 7] Internet-Draft MPLS and GMPLS Change Process November 2004 should arise. If the requirements for a proposal to change or extend (G)MPLS protocols falls under the purview of a (G)MPLS technology Working Group, the review process MUST involve both the technology Working Group(s) that understand the requirements as well as the Working Group(s) that shepherd protocol changes. Should this be the case, that other working group needs to explicitly state this in a Inernet-Draft and take it through the normal IESG review process. The set of (G)MPLS technology working groups, as indeed IETF working groups in general, changes over time. A list of the current set of working groups and areas will be found at http://www.ietf.org/html.charters/wg-dir.html 2.5 Routing Area and Routing Area working groups The change process specified in this document, if this is found beneficial, could be extended to any and all Routing Area working groups, and thus be applicable to all the protocols specified by those Routing Area working groups. Should this be the case those working groupss, or the Routing Area AD's, need to state this in an Internet-Draft and take it through the normal IESG review process. 2.6 Organizations outside the IETF A number of standards development organizations (SDOs) and industrial forums are using or referencing the (G)MPLS protocols in their specifications. Some of these organizations have formal liaison relationships with the IETF, and sometimes these liaison relationships go back several years. The IETF exchanges information with these organizations about what is happening on both sides, including plans and schedules. However, if any organization outside the IETF thinks they need to extend and/or change an existing (G)MPLS protocol or create a new protocol in the (G)MPLS area, a description of the requirement that brought the organization to this conclusion MUST to be submitted to the (G)MPLS working groups in the form of Internet Drafts. Such Internet-Drafts SHALL be handled in a timely manner according to the process described in this document. Note that the Internet Draft must detail the requirements. This Internet-Draft MAY be accompanied by a separate Internet Draft that proposes a way to meet the requirements. The IETF is not required to accept the way suggested Andersson, et al. Expires May 23, 2005 [Page 8] Internet-Draft MPLS and GMPLS Change Process November 2004 to meet the requirements even if the IETF agrees that the requirement is valid. 2.7 Terminology o (G)MPLS working groups - in this document the term (G)MPLS working groups is used to indicate the MPLS and the CCAMP working groups, and any future working group specifically chartered by the IESG to work on the development or extension of the (G)MPLS protocols. o (G)MPLS technology working groups - the (G)MPLS working groups plus any working groups chartered to specify requirements on the (G)MPLS protocols and working groups using the (G)MPLS protocols in their specifications, see sections Section 2.1, Section 2.2 and Section 2.4 for examples of (G)MPLS technology working groups. o (G)MPLS protocols - in this document the term (G)MPLS protocols is used to indicate the union of the protocols specified by the (G)MPLS working groups. o requirement evaluating working group (rewg) - in the process described below, the working group charged with the task of evaluating a certain problem statement and a certain set of requirements is termed the rewg o protocol specifying working group (pswg)- in the process described below the working group chartered to specify certain changes and/or extensions to the (G)MPLS protocols are called - pswg. o problem statement Internet-Draft - the draft that initiates the discussion on changing or extending the (G)MPLS protocols. This Internet Draft needs to include a detailed problem description and a set of requirements that the (G)MPLS protocols need to meet to solve the problem. o solutions Internet-Draft - a specification on how to change or extend the (G)MPLS protocols to meet the requirements in the problem statement Internet-Draft - this is not required but MAY be useful. Andersson, et al. Expires May 23, 2005 [Page 9] Internet-Draft MPLS and GMPLS Change Process November 2004 3. MPLS and GMPLS Change Process This section includes Figure 1 in Section 3.1 that summarizes the (G)MPLS change process, and Section 3.2 that discusses the process in more detail. 3.1 Overview +-------+ +---------+ +---------+ | prob |discussion |review by| ACK | IESG | ACK | statem|---------->|wg chairs|------------->| IAB |-------+ | id |on mailing |and ad's | request to |decision | | +-------+ list +---------+ IESG/IAB to +---------+ | | appoint rewg | | | NAK and charter |NAK rewg | | req eval | chartered| | | to work| V | on prob| | statement| |response | | | |to the | | | |prob | <---------------+ | +->|statement| <-------------------+ | | +---------+ | | | ^ | | |NAK | NAK | | | +-----------------+ | V | | | NAK +-------+ +--------+ +-------+ +------| rewg | | IESG | ACK | AD | ACK | req | +-----------| IAB |<-------------- |review |<----------| eval | | wg |decision| request to | | | | |chartered +--------+ IESG/IAB to +-------+ +-------+ |to work approve wg |solution charter changes | +---------+ | | IETF | +--------->| WG |-----/ /----> RFC | process | +---------+ ^ | solutions ID Andersson, et al. Expires May 23, 2005 [Page 10] Internet-Draft MPLS and GMPLS Change Process November 2004 Figure 1 The figure above gives an overview of the (G)MPLS change process. A more detailed discussion on the key elements in the process is found below. 3.2 Description This section discusses in more detail how the (G)MPLS change process works, what is expected from individuals or organizations that wants to extend and/or change the (G)MPLS and the responsibilities of the (G)MPLS working groups, the Routing Area and the IETF in general. 3.2.1 Initiating changes or extensions to (G)MPLS protocols Anyone who intends to use one of the existing (G)MPLS protocols, but thinks that it will not satisfy their needs MUST write an Internet- Draft (ID) explaining the problem they are trying to solve and why the existing (G)MPLS protocols will not work. This Internet-Draft - the problem statement ID - MUST include a detailed set of requirements that (G)MPLS would need to meet to solve the particular problem. The ID MUST also describe in detail any security issues that arise from meeting the requirements. This Interenet-Draft SHALL be sent to the IETF as an individual Ineternet-Draft and after it is published the authors should send a note to the appropriate mailing list to start discussion on the problems discussed in the Internet-Draft. The mailing list to use will in most cases be the Routing Area maililng list, as this is the Area containing working group that has specified the protocol being changed and that will likely be the rewg. The IESG or the Routing Area ADs may decide to use a specific working group mailing list for this discussion. 3.2.2 Problem statement review The MPLS and CCAMP working group chairs in conjunction with the Routing Area ADs will determine if the particular problems raised in the Internet-Draft should be evaluated by a working group. This mailing list discussion will be an essentail part in forming a decission. If the decision is that a requirement evaluation is warranted a decision is taken, by the ADs, on which working group should act as the rewg. 3.2.3 Charter update If the chairs and the ADs both feel that the particular problems should be added to the MPLS or the CCAMP Working Group charter the ADs will propose specific charter modifications for the Working group to the IESG and IAB. If the IESG and the IAB approve of the charter Andersson, et al. Expires May 23, 2005 [Page 11] Internet-Draft MPLS and GMPLS Change Process November 2004 changes the working group can then update its charter and start the work to evaluate the requirements and the problems described in the Internet-Draft. In a separate Internet-Draft the authors of the problem statement (or anyone else) MAY describe a set of changes to the (G)MPLS protocols that would meet the requirements. This Internet-Draft would not be considered by the rewg as part of the requirement evaluation, but no discussions on progressing the draft will be held until a working group has been chartered to work on a solution, i.e. one of the possible outcomes of the process described in this document. The IETF is not required to accept the solutions proposed in such an Internet-Draft. There may in fact exist more than one Internet-Draft trying to meet the requirements specified in the problem statement draft. If this is the case neither draft will be considered in the requirment evaluation process. They will all be held until a working group has been chartered to work on a solution and then all solutions drafts will be brought to the chartered working group. 3.2.4 Problem statement evaluation The rewg will evaluate the problem statement ID and based on the evaluation make a recommendation to the IESG/IAB. The recommendation may be: o that it is not a problem that falls within the remit of the IETF or could be solved by extending or changing the (G)MPLS protocols o that no changes or extensions to the (G)MPLS protocols are justified because the problem is not a general enough one. In these two cases the IETF will not publish an RFC that attempts to get around the decision. The IETF works based on a rough consensus within the working group, i.e. even if a proposal is not reject based on the criteria above, it is still possible for the working group to decide that it is not something that should be done in the working group. o that the problem is real and extensions to the (G)MPLS protocols are justified, and that a work item should be added to the charter of the appropriate working group - if the ADs agree then they will bring the proposal before the IESG and IAB. If the IESG (with IAB advice) agrees that the task should be added to that particular charter then the rewg can work on it with the aim of developing a Andersson, et al. Expires May 23, 2005 [Page 12] Internet-Draft MPLS and GMPLS Change Process November 2004 final set of requirements to be forwarded to the working group that will handle the specification of the protocol changes. In this case the rewg will evaluate and refine the requirements, merging them with other rewuirments if warranted. The result of these deliberations will be captured in a requirements RFC. The IESG may add a new task to the pswg charter prior to the publication of the requirements RFC, as soon as the problem space is sufficently understood. The protocol specifying working group will then develop the modifications or extensions to the (G)MPLS protocol needed to fulfill the requirements. If such a requirements document is added to a working group charter and if a proposed solution has previously been published as an Internet-Draft, the pswg may evaluate the proposed solution - but there is no requirement that any particular proposal be adopted. The (G)MPLS working groups are REQUIRED to protect the architectural integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS architecture with features that do not have general use beyond the specific case - they also MUST NOT modify the architecture just to make some function more efficient at the expense of simplicity or generality. o that the problem is real and that they would be solved with extensions to the (G)MPLS protocols, but that this for some reason is not best done within the IETF, but within some other SDO. The IETF might in such a case come to an agreement with this SDO that it MAY specify the protocol extensions and that these will be described in a ID sent to the IETF for review and eventually be published as an RFC. In this case the IETF enters into some limited commitments towards the SDO undertaking the protocol specification, e.g. support in reviewing and publishing the work. 3.2.5 Not accepted requirements Whenever a problem statement Inter-Draft is not accepted this should be clearly communicated to the authors of the draft. This communication could take any of several forms; it might be obvious after author(s) has presented the problem statement at a working group meeting that the requirements will be accepted it is considered enough capturing this in the meeting minutes; if working groups Andersson, et al. Expires May 23, 2005 [Page 13] Internet-Draft MPLS and GMPLS Change Process November 2004 chairs and/or ADs takes the concensus decision meaning that the requirments will not be accpted this decision should be sent to the working group mailing list, with a copy to the authors; if the problem statement were accompanied by a liaison or communication a response should be sent to the organization originating the liaison or communication. Andersson, et al. Expires May 23, 2005 [Page 14] Internet-Draft MPLS and GMPLS Change Process November 2004 4. Extensibility and Architecture In an idealized technical design, the extensibility design would be self-contained, and it would be inherent that new extensions and new headers would naturally have an architectural coherence with the original protocol. However, this idealized vision has not been attained in the world of standards tracks protocols. Implications for interoperability can be addressed by capabilities negotiation rules. The effects of adding features that overlap or that deal with a point solution and are not general are much harder to control with rules. Therefore the (G)MPLS technology calls for this architectural guardianship by its Working Groups. We encourage other protocol working groups with highly extensible protocols to review whether they need more coordination of extensions as in the (G)MPLS case. Andersson, et al. Expires May 23, 2005 [Page 15] Internet-Draft MPLS and GMPLS Change Process November 2004 5. (G)MPLS protocols The set of RFC³s that constitutes the (G)MPLS protocols are the standards track RFCs from the (G)MPLS working groups. We don't supply a list of these RFCs since these numbers are increasing rather quickly since there are new IDs going through working group last call and awaiting publication in the in the RFC-Editors queue. For the purpose of extending and changing any protocols specified in Experimental RFCs developed by the (G)MPLS working groups they are considered to be part of the (G)MPLS protocols. Andersson, et al. Expires May 23, 2005 [Page 16] Internet-Draft MPLS and GMPLS Change Process November 2004 6. Security Considerations Note: Needs to be filled in Andersson, et al. Expires May 23, 2005 [Page 17] Internet-Draft MPLS and GMPLS Change Process November 2004 7. Acknowledgements The input given by Bill Fenner, Scott Bradner and Bert Wijnjen has been useful and detailed. Andersson, et al. Expires May 23, 2005 [Page 18] Internet-Draft MPLS and GMPLS Change Process November 2004 8. References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2 Informative References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Authors' Addresses Loa Andersson Acreo AB EMail: loa@pi.se Adrian Farrel Olddog consulting EMail: adrian@olddog.co.uk George Swallow Cisco Systems EMail: swallow@cisco.com Kireeti Kompella Juniper Networks EMail: Kireeti@juniper.net Alex Zinin Alcatel EMail: zinin@psg.com Andersson, et al. Expires May 23, 2005 [Page 19] Internet-Draft MPLS and GMPLS Change Process November 2004 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 (2004). 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. Andersson, et al. Expires May 23, 2005 [Page 20]