Network Working Group L. Andersson Internet-Draft Acreo AB A. Farrel Old Dog Consulting G. Swallow Cisco Systems K. Kompella Juniper Networks A. Zinin Alcatel B. Fenner AT&T Labs - Research December 2005 MPLS and GMPLS Change Process draft-andersson-rtg-gmpls-change-02 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. Copyright Notice Copyright (C) The Internet Society (2005). Andersson, et al. [Page 1] Internet-Draft MPLS and GMPLS Change Process December 2005 Abstract 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 responsibility 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. When possible, existing liaison relationships are used. Status of this Proceess Note that this process is still in flux; although the general shape of the process is expected to remain the same, the details, especially in the realm of liaisons and interactions with other SDOs, may change. Comments are solicited and should be addressed to the Routing Area mailing list at routing-discussion@ietf.org and/or the authors. Andersson, et al. [Page 2] Internet-Draft MPLS and GMPLS Change Process December 2005 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 Organizations outside the IETF . . . . . . . . . . . . . . 8 2.6 Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3. MPLS and GMPLS Change Process . . . . . . . . . . . . . . . . 10 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Description . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Preliminary investigation . . . . . . . . . . . . . . 11 3.2.2 Initiating changes or extensions to (G)MPLS protocols . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3 Problem statement review . . . . . . . . . . . . . . . 12 3.2.4 Charter update . . . . . . . . . . . . . . . . . . . . 12 3.2.5 Problem statement evaluation . . . . . . . . . . . . . 13 3.2.6 Not accepted requirements . . . . . . . . . . . . . . 14 4. Extensibility and Architecture . . . . . . . . . . . . . . . . 16 5. (G)MPLS protocols . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1 Normative References . . . . . . . . . . . . . . . . . . . 20 8.2 Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 22 Andersson, et al. [Page 3] Internet-Draft MPLS and GMPLS Change Process December 2005 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. When possible, existing liaison relationships ([RFC4052], [RFC4053]) are leveraged. 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 describing extensions or changes to he (G)MPLS protocols is requested via the RFC Editor they will looped back through the process described in this document, using the mechanism described in [RFC3932]. 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.6. 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. [Page 4] Internet-Draft MPLS and GMPLS Change Process December 2005 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. Two working groups in the IETF's Routing Area have been responsible for work to develop 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 were 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. This 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 (and/or liaison statements, if appropriate). 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 closed. Andersson, et al. [Page 5] Internet-Draft MPLS and GMPLS Change Process December 2005 Further, another IETF working group MAY be appointed, in accordance with the process described in this document, to handle 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; and developing 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 over which the data is transported. While the MPLS working group focuses on packet- and frame-switched technologies, the CCAMP working group work focuses on common methods across a broad spectrum of switching technologies including packet and frame 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 (and/or liaison statements, if appropriate). 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. Further, another IETF working group MAY be appointed, in accordance with the process described in this document, to handle extensions and/or changes to the protocols specified by the CCAMP working group. Andersson, et al. [Page 6] Internet-Draft MPLS and GMPLS Change Process December 2005 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 LSPs, 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 (TEWG). 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 Detection (BFD) working group, also use the (G)MPLS protocols and mechanisms, and when this involves 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 VPNs. 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 group 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 Andersson, et al. [Page 7] Internet-Draft MPLS and GMPLS Change Process December 2005 adaptable to other (G)MPLS technology working groups if such a need 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 Internet-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 Organizations outside the IETF A number of standards development organizations (SDOs) and industrial forums use or reference 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, after an optional preliminary investigation, 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 by the IETF 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 to meet the requirements even if the IETF agrees that the requirement is valid. As described in [RFC4052], informal communications such as e-mail to working group mailing lists often facilitates working together. However, if desired, the Internet-Draft containing the requirement may be submitted to the working group using a liaison statement. That way, the IETF's response to the request will be given as the reply to the liaison, with no risk of confusing an individual participant's opinion for that of the group as can happen on mailing lists. Andersson, et al. [Page 8] Internet-Draft MPLS and GMPLS Change Process December 2005 2.6 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 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 is called the 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. [Page 9] Internet-Draft MPLS and GMPLS Change Process December 2005 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 Start +-------------+ | |optional | +-----------------------|preliminary |<-------Start | |investigation| V +-------------+ +---------+ +---------+ +---------+ |problem |discussion |review by| ACK | IESG/ | ACK |statement|---------->|wg chairs|------------->| IAB |-------+ | id |on mailing |and ads | request to |decision | | +---------+ list +---------+ IESG/IAB to +---------+ | | appoint rewg | | | NAK and charter |NAK rewg | V req eval | chartered| +---------+ | to work| |response | | on problem| |to the | | statement| |problem |<------------------+ | +->|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(s) Figure 1: Change Process Overview Figure 1 gives an overview of the (G)MPLS change process. A more Andersson, et al. [Page 10] Internet-Draft MPLS and GMPLS Change Process December 2005 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 want to extend and/or change the (G)MPLS protocols, and the responsibilities of the (G)MPLS working groups, the Routing Area and the IETF in general. 3.2.1 Preliminary investigation This step is optional, and is intended to provide a lightweight way to "feel out" the IETF's position on a proposal without going to the effort of writing an Internet-Draft. When an external SDO has an application or set of requirements that it believes may require extensions to the (G)MPLS protocols it should send details to the IETF as a liaison. The liaison can be sent directly to the rewg if known, or to the Routing Area if a rewg must still be determined. To respond to the liaison, the IETF will examine the supplied requirements and provide one of four answers as a liaison reply: a. Requirements not understood. Further discussion required. b. Requirements understood, but judged to be out of scope for the IETF. c. Requirements understood, but no protocol extensions are needed. It may be desirable for the external SDO to cooperate with the appropriate working group in the production of an Applicability Statement Internet-Draft. d. Requirements understood, and the IETF would like to develop protocol extensions. This results in execution of the rest of the procedure, described below. 3.2.2 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 Andersson, et al. [Page 11] Internet-Draft MPLS and GMPLS Change Process December 2005 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 Internet-Draft SHALL be sent to the IETF as an individual submission 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 mailing list, as this is the Area containing the working group that has specified the protocol being changed, which 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. If desired, a liaison statement may be sent to the Routing Area requesting IETF review of these requirements. The WG chairs or ADs will respond to this liaison as described in section 3.2.2.2 of [RFC4053], providing the result of the evaluation described in Section 3.2.3 and Section 3.2.5 of this document. 3.2.3 Problem statement review The MPLS and CCAMP working group chairs, in conjunction with the Routing 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 essential part in forming a decision. If the decision is that a requirement evaluation is warranted, the ADs decide which working group should act as the rewg. During this process, and the evaluation in Section 3.2.5, the document authors (or some delegate) SHOULD make themselves available on the mailing list in order to more rapidly facilitate this review. 3.2.4 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. If the IESG, in consultation with the IAB, approves of the charter 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. 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 Andersson, et al. [Page 12] Internet-Draft MPLS and GMPLS Change Process December 2005 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 requirement 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.5 Problem statement evaluation The rewg will evaluate the problem statement ID and based on the evaluation make a recommendation to the IESG/IAB. If the requirements document was included in a liaison statement as described in Section 3.2.2, this recommendation will be the response to the liaison. The recommendation may be: o that it is not a problem that falls within the remit of the IETF or that it is a not problem that 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 rejected 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 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 requirements 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 Andersson, et al. [Page 13] Internet-Draft MPLS and GMPLS Change Process December 2005 the requirements RFC, as soon as the problem space is sufficiently 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.6 Not accepted requirements Whenever a problem statement Internet-Draft is not accepted, this should be clearly communicated to the authors of the draft. This communication could take any of several forms: o It might be obvious after the author(s) have presented the problem statement at a working group meeting that the requirements will be accepted. In this case it is considered enough to capture this in the meeting minutes. o If working group chairs and/or ADs take a consensus decision meaning that the requirements will not be accepted, this decision MUST be sent to the working group mailing list, with a copy to the authors. Andersson, et al. [Page 14] Internet-Draft MPLS and GMPLS Change Process December 2005 o If the problem statement were accompanied by a liaison or a communication, then a response MUST be sent to the organization originating the liaison or communication. Andersson, et al. [Page 15] Internet-Draft MPLS and GMPLS Change Process December 2005 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. Andersson, et al. [Page 16] Internet-Draft MPLS and GMPLS Change Process December 2005 5. (G)MPLS protocols The set of RFCs that constitutes the (G)MPLS protocols are the standards track RFCs from the (G)MPLS working groups. A list of these RFCs is not supplied here since their number is increasing rather quickly since there are new IDs going through working group last call and awaiting publication in the RFC-Editor's queue. For the purpose of extending and changing any protocols specified in Experimental RFCs developed by the (G)MPLS working groups, those protocols are considered to be part of the (G)MPLS protocols. Andersson, et al. [Page 17] Internet-Draft MPLS and GMPLS Change Process December 2005 6. Security Considerations Documents that describe cooperation procedures, like this one does, have no direct Internet security implications. Andersson, et al. [Page 18] Internet-Draft MPLS and GMPLS Change Process December 2005 7. Acknowledgements The input given by Scott Bradner and Bert Wijnen has been useful and detailed. Review feedback and discussions with various members of the ITU-T has been helpful in refining the process described in this document. Thanks in particular to the members of Question 14 of Study Group 15, and to the management of Study Group 15. Andersson, et al. [Page 19] Internet-Draft MPLS and GMPLS Change Process December 2005 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. [RFC4052] Daigle, L., "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005. [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC4053, April 2005. 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. [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", RFC 3356, August 2002. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. Authors' Addresses Loa Andersson Acreo AB Email: loa@pi.se Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk George Swallow Cisco Systems Email: swallow@cisco.com Andersson, et al. [Page 20] Internet-Draft MPLS and GMPLS Change Process December 2005 Kireeti Kompella Juniper Networks Email: Kireeti@juniper.net Alex Zinin Alcatel Email: zinin@psg.com Bill Fenner AT&T Labs - Research 75 Willow Rd Menlo Park, CA 94025 USA Phone: +1 650 330-7893 Fax: +1 650 463-7037 Email: fenner@research.att.com Andersson, et al. [Page 21] Internet-Draft MPLS and GMPLS Change Process 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. Andersson, et al. [Page 22]