    Network Working Group                                  L. Andersson, Ed.
    Request for Comments: 4929                                      Acreo AB
    BCP: 129                                                  A. Farrel, Ed.
    Category: Best Current Practice                       Old Dog Consulting
                                                                   June 2007

          Change Process for Multiprotocol Label Switching (MPLS) and
               Generalized MPLS (GMPLS) Protocols and Procedures

    Status of This Memo

       This document specifies an Internet Best Current Practices for the
       Internet Community, and requests discussion and suggestions for
       improvements.  Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (C) The IETF Trust (2007).

    Abstract

       This document provides guidelines for applying or extending the MPLS
       or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's (G)MPLS
       working groups' responsibility for the (G)MPLS protocols.  This
       document is directed to multi-vendor fora and Standards Development
       Organizations (SDOs) to provide an understanding of (G)MPLS work in
       the IETF and documents the requisite use of IETF review procedures
       when considering (G)MPLS applications or protocol extensions in their
       work.  This document does not modify IETF processes.

    Andersson & Farrel       Best Current Practice                  [Page 1]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    Table of Contents

       1. Introduction ....................................................3
          1.1. Document Source ............................................4
          1.2. Conventions Used in This Document ..........................4
       2. Overview of (G)MPLS within the IETF .............................4
          2.1. IETF Working Groups Developing (G)MPLS Technology ..........5
               2.1.1. Multiprotocol Label Switching Working Group .........5
               2.1.2. Common Control & Measurement Plane Working Group ....5
               2.1.3. MPLS and CCAMP Division of Work .....................6
          2.2. Other (G)MPLS Technology-Related Working Groups ............6
          2.3. Organizations Outside the IETF .............................7
       3. Overview of (G)MPLS Change Process ..............................8
       4. MPLS and GMPLS Change Process ...................................9
          4.1. Flow Diagram ..............................................10
          4.2. Description of Process Stages .............................11
               4.2.1. Preliminary Investigation ..........................12
               4.2.2. Requirements Statement Evaluation ..................13
               4.2.3. Working Group Procedures ...........................14
               4.2.4. REWG Evaluation of the Requirements Statement I-D ..14
               4.2.5. AD Evaluation of Completed Requirements
                      Statement I-D ......................................14
               4.2.6. IESG review of Requirements Statement I-D
                      and PSWG Charter ...................................15
               4.2.7. Solutions Work .....................................15
       5. Rejecting the Requirements Statements I-D ......................16
          5.1. Reasons for Rejection .....................................16
          5.2. Actions Required When Rejecting Requirements
               Statement I-Ds ............................................18
          5.3. Appeals ...................................................18
       6. Abandonment of the Solutions I-D ...............................19
          6.1. Appeals ...................................................19
       7. (G)MPLS Integrity and Ownership ................................19
       8. Security Considerations ........................................20
       9. Acknowledgements ...............................................20
       10. IANA Considerations ...........................................21
       11. References ....................................................21
          11.1. Normative References .....................................21
          11.2. Informative References ...................................21

    Andersson & Farrel       Best Current Practice                  [Page 2]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    1.  Introduction

       The MPLS and GMPLS technology is developed in two main tracks in the
       IETF.  "MPLS" refers to the work done for packet switched networks,
       while "GMPLS" refers to the efforts to apply the MPLS protocols to
       all types of networks including packet and non-packet technologies.

       Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS"
       is used in this document 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.

       [RFC4775] discusses procedural issues related to the extension or
       variation of IETF protocols by other SDOs.  It provides the
       guidelines and procedures to be used by other SDOs when considering
       the requirements for extensions to IETF protocols.  [RFC4775]
       recommends that major extensions to, or variations of, IETF protocols
       only take place through normal IETF processes or in coordination with
       the IETF.

       The (G)MPLS protocol families were developed within the IETF and
       constitute significant protocol suites within the Internet standards.
       The (G)MPLS suites of protocols have become popular for a number of
       new applications and deployment scenarios.  There have been concerns
       with regards to other technology fora developing, using, and
       publishing non-standard protocol extensions as a standard not only
       for use within their community, also for wider use by the industry.
       Especially concerning is the development of extensions, without
       consulting the (G)MPLS working groups, which are in conflict with
       efforts on-going in the (G)MPLS working groups, and then presented to
       the (G)MPLS working group as 'fait accompli'.

       The definition and publishing of non-standard extensions by other
       fora, without IETF review, and outside of the IETF publication
       process, regardless if rationalized as limited to use among fora
       vendors, or limited to a particular application, or rationalized as
       allowing timely demos, has the unfortunate potential to hinder
       interoperability and increase complexity of the protocol, sows
       confusion in the industry, and circumvents the Internet standards
       process that exists to ensure protocol implementability.  As
       described in [RFC4775], non-standard extensions, including
       experimental values, are not to be portrayed as industrial standards
       whether by an individual vendor, an industry forum, or a standards
       body.

       This document clarifies the IETF's MPLS and Common Control and
       Measurement Plane (CCAMP) working groups' roles and responsibilities
       for the (G)MPLS protocols and documents the requisite use of, and how

    Andersson & Farrel       Best Current Practice                  [Page 3]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       to apply, the [RFC4775] procedure of using the IETF review processes,
       [RFC2026] and [RFC2418], for fora wishing to apply or extend the
       (G)MPLS protocols.  Use of the IETF review processes will ensure an
       open process for protocol development and ensure a non-harmful
       evolution for these IETF protocols, which will benefit the larger
       industry users' community.  IETF itself cannot enforce a forum to use
       the (G)MPLS change procedure, though any forum not following it, when
       applying for IANA assignment or IETF publication, will be delayed
       until this procedure has been completed.

       This document does not change the formal IETF standards process as
       defined in [RFC2026] and [RFC2418].  It is consistent with the
       general procedures for protocol extensions defined in [RFC4775] and
       shows how they are applied in the case of (G)MPLS.  Any procedures
       described in this document are to be implemented in a way consistent
       with these three documents.  They MUST be used when other SDOs and
       fora wish to propose (G)MPLS changes.  They SHOULD be used internally
       within the IETF unless the changes concerned are considered non-
       controversial by the responsible Area Director(s) (e.g., covered by
       the working group charter), in which case other aspects of the normal
       IETF standards process cover the necessary procedures.

    1.1.  Document Source

       This document is the joint work of the IETF Routing Area Directors,
       the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaisons
       to the ITU-T.  It had considerable review and comment from key
       members of the ITU-T who have given their time and opinions based on
       experience for which the authors are grateful.  The IESG has also
       provided valuable input to arrive at the process documented here.
       The acknowledgements section lists those whose contributions have
       been particularly helpful.

    1.2.  Conventions Used in This Document

       Although this document is not a protocol definition, 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].  This usage
       is chosen to make the steps and procedures completely clear.

    2.  Overview of (G)MPLS within the IETF

       This section describes the key IETF working groups developing the
       (G)MPLS technology and provides information on IETF working groups
       using the (G)MPLS technology.

    Andersson & Farrel       Best Current Practice                  [Page 4]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       It should be remembered that the IETF environment is highly dynamic.
       Working groups and whole areas come and go.  The overview of the
       relevant working groups within the IETF is only a snapshot in time.

    2.1.  IETF Working Groups Developing (G)MPLS Technology

       Two working groups in the IETF's Routing Area are responsible for
       work related to developing the (G)MPLS technologies:  Multiprotocol
       Label Switching (MPLS) working group and the Common Control and
       Measurement Plane (CCAMP) working group.

       The following sections provide brief overviews of the chartered work
       of these two IETF working groups.

    2.1.1.  Multiprotocol Label Switching Working Group

       The Multiprotocol Label Switching (MPLS) working group is responsible
       for standardizing the base technology that uses label switching, and
       for describing the implementation of Label Switched Paths (LSPs) 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.

       This document assumes that the MPLS working group remains the
       chartered authority on MPLS technologies, but notes that the IETF may
       appoint another working group (refer to [RFC2418]) to handle specific
       extensions or changes to the protocols.  Further, in the event that
       the MPLS working group completes its work and is closed, the IETF
       will use the non-working group standards track document process
       (described in [RFC2026]) using designated experts from the community
       [RFC2434] for the MPLS protocols.

    2.1.2.  Common Control & Measurement Plane Working Group

       The IETF Common Control and Measurement Plane (CCAMP) working group
       coordinates the work within the IETF defining common control and
       measurement planes 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.  It also includes the
       development of 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 called
       Generalized MPLS (GMPLS), indicating that CCAMP addresses a
       generalized technology, where labels are defined in such a way that

    Andersson & Farrel       Best Current Practice                  [Page 5]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       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.

       The procedures in this document assume that the CCAMP working group
       remains the authority on GMPLS technologies, but acknowledges that
       the IETF may appoint another working group (refer to [RFC2418]) to
       handle specific extensions or changes to the protocols.  Further, in
       the event that the CCAMP working group completes its work and is
       closed, the IETF will use the non-working group standards track
       document process (described in [RFC2026]) using designated experts
       from the community [RFC2434] for the GMPLS protocols.

    2.1.3.  MPLS and CCAMP Division of Work

       From time to time, the MPLS and CCAMP working groups decide to divide
       work between themselves in a way that does not strictly follow the
       split between the working groups as defined in the working group
       charters.  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 technologies.

       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 working
       group chairs, in conjunction with their Area Directors, may redirect
       the proposal to another working group.

    2.2.  Other (G)MPLS Technology-Related Working Groups

       Problem statements and requirements for (G)MPLS technology have been
       produced by several working groups in addition to the MPLS and CCAMP
       working groups.  IETF working groups are defined for the management
       of specific tasks by their charter.  Their charter defines their
       role, relationship with other working groups, and the applicable
       procedures to follow when extensions to (G)MPLS may be needed.  This
       section provides an overview of the (G)MPLS-related groups and their
       responsibilities.  Additional information describing the working
       groups and their charters is available on the IETF web pages.

       The IP over Optical (IPO) working group and the Internet Traffic
       Engineering working group (TEWG) are examples of working groups which
       focus on problem statements and requirements for (G)MPLS to be
       considered by the (G)MPLS working groups.  These working groups have
       not specified any protocols.

    Andersson & Farrel       Best Current Practice                  [Page 6]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       The Bidirectional Forwarding Detection (BFD) working group, also may
       use the (G)MPLS protocols and mechanisms.  The BFD working group is
       chartered for requirements evaluation and protocol specification
       related to BFD.  If the working group needs to extend or change the
       (G)MPLS protocols, the procedures specified by its charter and the
       IETF's standard processes are applicable.

       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.
       Much of the work of the L2VPN and L3VPN working groups does not
       include specifying new protocols or extensions to existing protocols.
       Where extensions are needed, the procedures as specified by their
       charters and the IETF's standard processes are applicable.

       The Layer 1 VPN (L1VPN) working group is chartered to specify
       mechanisms necessary for providing Layer 1 VPN services
       (establishment of layer 1 connections between CE devices) over a
       GMPLS-enabled transport service-provider network.  Protocol
       extensions required for L1VPN will be done in cooperation with MPLS,
       CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary.  That
       is, the L1VPN working group will not develop GMPLS protocol
       extensions in isolation, but will develop requirements and propose
       extensions that will be reviewed and approved by the (G)MPLS working
       groups.

       The Pseudo Wire Emulation End to End (PWE3) working group is a
       working group that may use the (G)MPLS protocols in its
       specifications.  Should the PWE3 specifications require extension or
       changes to the (G)MPLS protocols, the procedures as specified by its
       charter and the IETF's standard processes are applicable.

    2.3.  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 or informal
       liaison relationships with the IETF [RFC4052].  The IETF exchanges
       information with these organizations about what is happening on both
       sides, including plans and schedules, using liaison statements
       [RFC4053].  More details about the cooperation relationship between
       the IETF and the ITU-T can be found in [RFC3356].

       The procedures in this document are applicable to all organizations
       outside the IETF whether or not they have formal liaison
       relationships with the IETF.  If any organization outside the IETF
       has a requirement for extensions or modifications to the (G)MPLS
       protocols then the procedures in this document apply.

    Andersson & Farrel       Best Current Practice                  [Page 7]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    3.  Overview of (G)MPLS Change Process

       This is a non-normative section, as it is intended to provide a high-
       level view of [RFC4775] procedures for protocol extensions.
       Application of these procedures for (G)MPLS are defined in detail in
       Section 4.

       Whenever there is reason to believe that a particular problem may be
       solved by use of or extensions to the (G)MPLS protocols, a
       communication using the formal liaison process, or, for a forum
       without a formal relationship, an informal communication, may be used
       to discuss the problem with the IETF ([RFC4052] and [RFC4053]).
       Collaboration with the IETF in the early discussion phase will
       facilitate a timely understanding of whether the problem has already
       been solved, may be outside the scope of the (G)MPLS protocols, or
       may require more investigation.

       Whenever any extension or change to the (G)MPLS protocols is desired,
       a problem statement and/or requirements statement must be produced
       and must be submitted to IETF as an Internet-Draft.  When the
       requirements come from an external organization, informal
       communications, such as e-mail to working group mailing lists, is
       strongly encouraged as it facilitates timely and cooperative work.
       However, if desired, the Internet-Draft, containing the
       requirement(s), may be submitted to the working group using a formal
       liaison statement.  IETF's response to the request will be given as a
       reply to the liaison.  This use of formal communication reduces the
       risk of confusing an individual participant's opinion for that of the
       group as can happen on mailing lists, though it does introduce a more
       lengthy communication cycle.  If there is no formal liaison
       relationship, a communication may be sent directly to the (G)MPLS
       working group, a relevant Area Director, or the IESG.

       The IETF, through the appropriate Area Director, and the chairs of
       the MPLS and CCAMP working groups for (G)MPLS related work, will
       direct the requirements draft to an appropriate working group for
       assessment and comment.  This process may require communication and
       discussion for clarification, but the IETF undertakes to perform the
       assessment in a timely manner.

       In assessing the requirements statement I-D, the IETF may determine:

       - that the requirements can be satisfied without modifications to the
         (G)MPLS protocols

    Andersson & Farrel       Best Current Practice                  [Page 8]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       - that the requirements are not sufficiently general or there is not
         sufficient interest to do a standards-track solution to warrant a
         Standards-track change to the (G)MPLS protocols

       - that the requirements justify a standards-track change to the
         (G)MPLS protocols

       - that the requirements might not be possible to satisfy without
         violating the (G)MPLS architecture in a way that would harm the
         (G)MPLS technology

       - that the requirements should be combined with other requirements to
         solve a more general problem or solve the same problem in a more
         flexible way.

       In the event that the IETF agrees to develop a solution, the IETF
       will set milestones that would result in timely delivery of the
       solution in a timely manner.  If the IETF rejects the requirements,
       this will only be done with clear explanation and full discussion
       with the source of the requirements.

       The solutions that are developed within the IETF may be sourced from
       external organizations and presented for review, discussion,
       modification, and adoption as Internet-Drafts.  Such solutions drafts
       may be presented to the IETF in advance of the completion of the
       requirements work, but all solutions will be processed through the
       normal IETF process with other proposed solutions.  Solution drafts
       are adopted as an IETF working group draft when the requirements are
       stable, and not before the protocol-responsible working group has a
       charter item to cover the solutions work.  It is strongly recommended
       for interested parties to start informal discussion in the IETF, as
       early as possible, and to co-author in the IETF's work.  It is not
       recommended for the source forum to continue to work on solutions in
       parallel with on-going work in the IETF.  If the protocol-responsible
       working group is unable to accept the work (e.g., due to current work
       load), the IETF processes ([RFC2418]) provide alternate options for
       ensuring the work is completed.

    4.  MPLS and GMPLS Change Process

       This section defines the (G)MPLS change process and the rules that
       must be followed in order to make extensions or changes to the
       (G)MPLS protocols.  The language of [RFC2119] is used in order to
       clarify the required behavior of the IETF and the originator of the
       change request.  It is consistent with the general procedures for
       protocol extensions defined in [RFC4775].  Any interpretation of
       procedures described in this document and their implementation are to
       be in a way consistent with [RFC4775].

    Andersson & Farrel       Best Current Practice                  [Page 9]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       Anyone who intends to use one of the existing (G)MPLS protocols, but
       thinks that it will not satisfy their needs MUST use the procedures
       described in this document.  They SHOULD be used internally within
       the IETF unless the changes concerned are considered non-
       controversial by the responsible Area Director(s) (e.g., covered by
       the working group charter), in which case other aspects of the normal
       IETF standards process apply.  Changes or extensions to the (G)MPLS
       protocols MUST NOT be made by any other mechanism.  The IETF MUST NOT
       endorse any publications (including RFCs, whether on the Standards
       Track, Informational, or Experimental) that change or extend the
       (G)MPLS protocols except for those that arise through the correct
       execution of the procedures in this document.  The IETF MUST NOT
       endorse any IANA action that allocates (G)MPLS protocol codepoints,
       except as a result of actions arising from the correct execution of
       the procedures in this document.

    4.1.  Flow Diagram

       Figure 1 gives a visual overview to illustrate the roles of a (G)MPLS
       requirements evaluation working group (REWG) and (G)MPLS protocol
       solutions working group (PSWG).  The figure presents two alternatives
       for a requestor: (1) contact the IETF early in the problem definition
       phase (preliminary investigation), or, (2) later, with a requirements
       statement.  The figure is for illustration only; it does not contain
       all of the possible interactions and IETF procedure alternatives.
       The text in the subsequent sections describes the process.

    Andersson & Farrel       Best Current Practice                 [Page 10]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

         Start                     +-------------+
           |                       |optional     |
           +--<--------------------|preliminary  |<-------Start
           |                       |investigation|
           V                       +-------------+
       +------------+            +---------+              +---------+
       |requirements| discussion |review by|     YES      |  IESG   | YES
       |statement   |----------->|WG chairs|------------->|decision |------+
       |I-D         | on mailing |and ADs  | request to   |         |      |
       +------------+   list     +---------+ IESG to      +---------+      |
                                  |          appoint REWG   |              |
                                  |NO        and charter    |NO        REWG|
                                  V          req eval       |     chartered|
                           +-------------+                  |    to work on|
                           |response     |                  |  requirements|
                           |to the       |                  |     statement|
                           |requirements |<-----------------+              |
                        +->|statement    |<----------------+               |
                        |  +-------------+                 |               |
                        |      ^                           |               |
                      NO|      |     NO                    |               |
                        |      +-----------------+         |               V
                        |                        |         |  NO    +------+
                    +--------+                +-------+    +--------| REWG |
                    | IESG/  |        YES     |  AD   |             |  req |
        +-----------|decision|<---------------|review |<------------| eval |
        |PSWG       |        |   request to   |       |     YES     |      |
        |chartered  +--------+   IESG to      +-------+             +------+
        |to work                 approve I-D
        |                        and charter
        |                        PSWG (if needed)
        |          +---------+
        |          | IETF    |             +-----+
        +--------->|  PSWG   |-----/ /---->| RFC |
             +---->| process |             +-----+
             |     +---------+
         solutions
            I-D
                         Figure 1: Change Process Overview

    4.2.  Description of Process Stages

       This section describes how the (G)MPLS change process works, what is
       expected from individuals or organizations that want to extend or
       change the (G)MPLS protocols, and the responsibilities of the IETF.

    Andersson & Farrel       Best Current Practice                 [Page 11]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    4.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.  The intention is to determine
       whether the problem has been examined already, whether the problem is
       in scope for the IETF, and whether solutions are already known.

       Although the preliminary investigation phase is optional it is
       RECOMMENDED that the originator of any requirements consult and
       discuss the issues concerned as early as possible to avoid any wasted
       effort, and the preliminary investigation phase provides a mechanism
       to do this.

       Useful discussions may be held at this stage in order to ensure that
       the problem statement and requirements statement Internet-Drafts
       contain the right material.  This step is described as lightweight
       because no Internet-Draft is required and because the step largely
       involves offline discussions.  However, it may be the case that this
       step involves considerable technical discussions and may, in fact,
       involve an extensive, substantive exchange of ideas and opinions.

       This step SHOULD be carried out informally on the mailing list of the
       REWG or on the Routing Area discussion mailing list, and MAY be
       initiated by any individual, group of individuals, external
       organization, or IETF working group.

       When an external SDO has a liaison relationship with the IETF, it MAY
       carry out this step using a formal liaison.  The liaison SHOULD be
       sent to the designated liaison manager who is responsible for
       forwarding them to the IESG who will assign a Responsible AD.  The
       initiators of the liaison SHOULD make themselves available for
       discussion on the selected mailing list.  If a formal liaison is
       used, the IETF will respond using the procedures of [RFC4053].

       At this stage, a problem statement I-D MAY be produced to help
       further the discussions and to clarify the issues being addressed.

       A possible outcome of this preliminary investigation is that the
       requirements and problem are understood, but agreed to be out of
       scope for the IETF.  Alternatively, it may be that the problem can be
       solved with existing protocols.  The full list of outcomes from the
       preliminary investigation phase are similar to those for the
       requirements statement evaluation phase described in Section 4.2.2,
       but the requirements statement evaluation phase that allows wider
       IETF community participation in developing a complete requirement set
       MUST form part of the process if the IETF is to consider to develop
       protocol solutions.  The process cannot move direct from the

    Andersson & Farrel       Best Current Practice                 [Page 12]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       preliminary investigation phase to the development of solutions
       unless the working group agrees (e.g., the problem is minor).

    4.2.2.  Requirements Statement Evaluation

       Before the IETF can formally pronounce on requests to change or
       extend the (G)MPLS protocols, a requirements statement I-D MUST be
       written per [RFC2026].

       The requirements statement I-D MUST be introduced by the authors to
       the IETF through an email to the REWG mailing list, to the Routing
       Area discussion mailing list, or by a formal liaison from an external
       SDO which will result in the IETF introducing the requirements
       statement I-D to the REWG mailing list.  If the requirements
       statement I-D is brought to the IETF through a formal liaison, the
       initiators of the liaison SHOULD make themselves available for
       discussion on the designated IETF mailing lists.

       After discussion on the IETF mailing lists, the responsible Area
       Director MUST decide whether the requirements will be formally
       evaluated by the IETF, and MUST deliver a response to the per
       [RFC4053] and [RFC4775].  If a formal liaison was not used, the
       response SHOULD be delivered to the appropriate contact as listed on
       the communication.

       The IETF response MUST be sufficiently explanatory to inform the
       requesting organization of what, if anything, the IETF has decided to
       do in response to the request.  The following list is provided to
       illustrate possible responses:

       a.  Requirements not understood.  Further discussion is required.

       b.  Requirements understood, but judged to be out of scope for the
           IETF.  In this case, the originator of the requirements can work
           on requirements and solutions and will not be impeded by the
           IETF.  The IETF may request to be kept informed of progress.

       c.  Requirements understood, but no protocol extensions are needed.
           It may be desirable for the external SDO to cooperate with the an
           IETF 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.  The requirements raised in the
           requirements statement I-D may be combined with other
           requirements to produce more general extensions or changes to the
           (G)MPLS protocols.

    Andersson & Farrel       Best Current Practice                 [Page 13]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    4.2.3.  Working Group Procedures

       In many cases, the problem covered by the requirements statement I-D
       will fall within the scope of the existing charter of a working
       group.  In this case, the responsible Area Directors will designate
       the working group as the REWG and pass the requirements statement I-D
       to the working group for evaluation.  If the problem is not covered
       by an existing charter, other alternatives (refer to [RFC2418]) may
       be used, e.g., rechartering, BOF, chartering a new working group.

       If the IETF modifies its prior decision to accept the work, the IETF
       MUST communicate this to the requestor in a timely manner.

    4.2.4.  REWG Evaluation of the Requirements Statement I-D

       The objective of the REWG evaluation process is to determine a clear
       and complete statement of the requirements for changes or extensions
       to the (G)MPLS protocols.  This will necessitate normal IETF working
       group procedures in the REWG and MAY include the generation of
       revisions of the requirements statement I-D in cooperation between
       the members of the REWG and the original authors of the requirements
       statement I-D.

       The originators of the requirements statement I-D MUST make
       themselves available to discuss the work on the REWG mailing list.
       If this does not happen, the chairs of the REWG MAY determine that
       there is insufficient support for the work and MAY reject the
       requirements statement I-D.

       The output of the REWG will be either:

       - a completed requirements statement I-D that has been accepted by
         working group consensus within the REWG and has passed through
         working group last call;

       or

       - a rejection of the requirements using the response procedure as
         described in Section 5.

    4.2.5.  AD Evaluation of Completed Requirements Statement I-D

       As with all Internet-Drafts produced by a working group, the ADs will
       review the completed requirements statement I-D produced by the REWG.
       The ADs will then pass the document to the IESG for review.  If
       charter changes are needed or a new PSWG needed, the appropriate
       process will be followed.

    Andersson & Farrel       Best Current Practice                 [Page 14]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    4.2.6.  IESG review of Requirements Statement I-D and PSWG Charter

       As with all Internet-Drafts, the IESG will review and make a decision
       on the progression of the requirements statement I-D.

       If the IESG rejects the requirements statement I-D, it will generate
       an appropriate response to the working group (and, if needed, to the
       originator of the request).

       The IESG will review any proposed charter changes for the PSWG or, if
       needed, consider alternatives.  This might include the formation of a
       new working group specifically to work on the solutions.

    4.2.7.  Solutions Work

       The appropriate PSWG will start work on solutions following the
       normal IETF process.

       Solutions I-Ds MAY be prepared externally (such as within an external
       organization) or within the IETF, submitted to the IETF for draft
       publication using the procedures of [RFC2418], and introduced to the
       PSWG for consideration.  Such I-Ds MAY be submitted at earlier stages
       in the process to assist the REWG in its development and discussion
       of the requirements, but no I-D will be formally considered as a
       solutions I-D until the PSWG has a charter item that covers the work
       and the REWG chairs are confident that the requirements are stable.

       The IETF makes no guarantees that an externally produced solutions
       I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST
       consider such an I-D for review and revision as a possible solution
       I-D, using the same open procedures ([RFC2418]) as for any individual
       submission.  The IETF's procedures are based on open and fair
       participation, and thorough consideration of technical alternatives.

       Interested parties (both implementers and users) of the SDO
       originating the request are strongly encouraged to participate in the
       PSWG to ensure appropriate interest is shown in the solutions work
       and to provide timely solutions development.  The IETF's work, as
       that of any SDO, is driven by its participants.  The IETF is an open
       community and any SDO requesting IETF solutions work SHOULD ensure
       appropriate industry interest in the work, or the IETF MAY
       discontinue its support of the work.  Appropriate communication of
       the discontinued work will be made to the originator of the request
       (if the originator is reachable).

       The final development of the solutions I-D is subject to the normal
       working group review, consensus, and last call within the PSWG.

    Andersson & Farrel       Best Current Practice                 [Page 15]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       Where the requirements originated from an external organization, the
       PSWG SHOULD regularly communicate its progress using a formal liaison
       process if one exists.  This communication SHOULD also be used to
       request review input and comment on the development of the solutions
       I-D.  The solutions I-D MUST be communicated to the originating
       organization during working group last call for final review against
       the requirements.  When the solutions I-D is complete (normally upon
       completing working group last call and/or on entering the RFC
       Editor's queue) the PSWG MUST inform the originating organization of
       the completed solution.

    5.  Rejecting the Requirements Statements I-D

       Rejection of the requirements statements is a sensitive matter for
       the authors of the requirements and MUST be handled with full
       disclosure and explanation by the IETF.  All working group actions
       are taken in a public forum ([RFC2418]).

       The requirements can be rejected at various stages of the process as
       described in the previous sections.  The person or group that makes
       the rejection is responsible for generating an explanation of the
       rejection and MUST follow the [RFC4775] process.  Possible reasons
       for rejection are described in this section.

    5.1.  Reasons for Rejection

       The requirements statement I-D can only be rejected with full
       disclosure by the IETF.  Possible reasons for rejection and possible
       next steps as described here.

       - Requirements not understood.  Either during preliminary
         investigation or during evaluation of the requirements statement
         I-D, it was not clear what the requirements are, or what the
         problem being addressed is.

         This rejection forms part of an on-going communication and it is
         expected that the process will continue with further iterations.

       - Out of scope for the IETF.  Many stages of this process may
         determine that the requirements are out of scope for the IETF.  In
         this case, the IETF MUST NOT constrain the authors of the
         requirements statement I-D from working on a solution.  If any
         (G)MPLS changes are later identified, the requestor MUST reinitiate
         the (G)MPLS change procedure.

       - No protocols extensions or changes are needed.  At some stage in
         the evaluation of the requirements it may become clear that they
         can all be met through appropriate use of existing protocols.  In

    Andersson & Farrel       Best Current Practice                 [Page 16]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

         this case, no further evaluation of the requirements is required,
         but the REWG MUST explain how the protocols can be used to meet the
         requirements and MAY cooperate with the authors of the requirements
         statement I-D in the production of an Applicability Statement
         Internet-Draft or a Profiles Internet-Draft that explains precisely
         how the existing protocols can be used to meet the requirements.

       - Insufficient support within the IETF.  Although the work described
         within the requirements statement I-D is within scope for the IETF,
         and despite the support of the originators of the requirements
         statement I-D on the REWG mailing list, the chairs of the REWG have
         determined that there is insufficient support in the REWG to
         complete requirements statement I-D and initiate solutions work in
         the PSWG.  In this case, the IETF MUST NOT restrict the authors of
         the requirements statement I-D from working on a solution.  The
         solution (and/or IANA codepoints requested) SHALL be presented to
         the IETF's (G)MPLS PSWG for review and possible publication as an
         Informational or Experimental RFC, and, pending IETF review
         results, the IETF SHALL NOT block applications to IANA for
         codepoints.  If IANA codepoint assignments are required, the IANA
         Requirements prescribed for those assignments in the relevant RFCs
         MUST be satisfied.  It is highly recommended for the SDO to
         encourage its participants to participate in the IETF work to
         ensure appropriate industry representation in the work.

       - Insufficient support for the work from the original requesters.  If
         the authors of the requirements statement I-D do not make
         themselves available on the REWG mailing list for discussion of the
         requirements or do not contribute the completion of the
         requirements statement I-D, the chairs of the REWG MAY determine
         that there is insufficient support for the work and MAY reject the
         requirements statement I-D.  In this case, the IETF MUST NOT grant
         permission for the work to be carried out in any other
         organization, and MUST NOT endorse the publication of any changes
         or extensions to the (G)MPLS protocols and MUST NOT instruct IANA
         to allocate any codepoints.  The requirements may be reintroduced
         by starting the procedure again from the top.

       - Satisfying the requirements would break the technology.  It is
         possible that an assessment will be made that, although the
         requirements are reasonable, it is not possible to satisfy them
         through extensions or changes to the (G)MPLS protocols without
         violating the (G)MPLS architecture in such a way as would break the
         (G)MPLS technology.  In this case, a recommendation will be made
         that some other technology be used to satisfy the requirements.
         See Section 7 for further discussions of the protection of the
         integrity of the (G)MPLS technology.  In this case, the IETF MUST
         NOT grant permission for the work to be carried out in any other

    Andersson & Farrel       Best Current Practice                 [Page 17]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

         organization, and MUST NOT endorse the publication of any changes
         or extensions to the (G)MPLS protocols and MUST NOT instruct IANA
         to allocate any codepoints.

    5.2.  Actions Required When Rejecting Requirements Statement I-Ds

       Upon rejection, the IETF MUST make a clear statement of why the
       requirements statement I-D has been rejected and what next step
       actions are acceptable (refer to Section 5.1).

       The communication of the rejection depends on the form of the
       original submission as follows.

       - If the requirements are brought to the IETF as a preliminary
         investigation (see Section 4.2.1) through an email exchange then
         the response MUST be made as an email response copied to an IETF
         mailing list so that it is automatically archived.

       - If the requirements are brought to the IETF as a preliminary
         investigation (see Section 4.2.1) through a formal liaison, the
         rejection MUST be delivered through a formal liaison response.

       - If a requirements statement I-D has been produced and discussed on
         an IETF email list, the response MUST be made as an email response
         and copied to the email list.

       - If a requirements statement I-D has been produced and brought to
         the IETF through a formal liaison, the rejection MUST be delivered
         through a formal liaison response.

       - If an IETF working group has been involved in the review or
         production of any Internet-Drafts for the requirements or for the
         solutions, the working group MUST be notified of the rejection and
         the reasons.

       The responsibility for the generation of the response lies with the
       person, people, or group that instigates the rejection.  This may be
       the IESG, one or more Area Directors, one or more working group
       chairs, or a designated expert [RFC2434].  In the case of the use of
       a liaison relationship, the IETF's liaison manager has responsibility
       for ensuring that the procedures in this document, and particularly
       the rejection procedures, are followed.

    5.3.  Appeals

       [RFC2026] contains additional information related to procedure
       disagreements and appeals.  The rejection of a requirements statement
       I-D as described in Sections 5.1 and 5.2 may be appealed in the event

    Andersson & Farrel       Best Current Practice                 [Page 18]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       it is disputed and cannot be reversed by direct discussion between
       the parties.  The conflict resolution and appeal mechanism is
       documented in [RFC2026].

    6.  Abandonment of the Solutions I-D

       Once the solutions work has been started by the PSWG, it may be
       abandoned before completion.  This can happen if the PSWG chairs
       determine that there is no longer working group support for doing the
       work.  This could arise, for example, if no one (including the
       originators of the requirements statement I-D) is willing to
       contribute to the development of a solutions I-D.

       In the event that the solutions work is abandoned by the PSWG, the
       Area Directors responsible for the PSWG MUST be consulted.  The
       originators of the requirements statement I-D MUST be informed that
       the work has been abandoned using a mechanism dependent on how the
       requirements were introduced (as discussed in Section 5.2).

       If the solution is abandoned in this way, work on solutions for the
       requirements MUST NOT be started in another forum.  The status of
       extensions and changes to the (G)MPLS protocols with regard to the
       specific requirements returns to how it was before the process
       started.  Any new examination of the requirements MUST commence at
       the top of the process.

    6.1.  Appeals

       The abandonment of a solutions I-D may be appealed in the event it is
       disputed and cannot be reversed by direct discussion between the
       parties.  The conflict resolution and appeal mechanism is documented
       in [RFC2026].

    7.  (G)MPLS Integrity and Ownership

       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.

       The architectural implications of additions or changes to the (G)MPLS
       protocols MUST consider interoperability with existing and future
       versions of the protocols.  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 and risk impacting the protocol as
       a whole.  Therefore, to minimize operational and technical risks to

    Andersson & Farrel       Best Current Practice                 [Page 19]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

       the (G)MPLS technology, IETF processes SHALL be followed for any
       requests on extensions to (G)MPLS protocols.  With respect to (G)MPLS
       protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS
       protocol, as long as the working group exists.  All changes or
       extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG.

    8.  Security Considerations

       All requirements statement I-Ds MUST give full consideration to the
       security impact of the proposed additional features or functions.
       All solutions I-Ds MUST consider the impact on the security of the
       protocol extensions and to the pre-existing protocol.

       This documents does not itself introduce any security issues for any
       (G)MPLS protocols.

       The IETF process is itself at risk from denial of service attacks.
       This document utilizes the IETF process and adds clarity to that
       process.  It is possible, therefore, that this document might put the
       IETF process at risk.

       Therefore, provided that the number of requirements statement I-Ds is
       not unreasonable, there will be no significant impact on the IETF
       process.  The rate of arrival of requirements statement I-Ds MAY be
       used by the IESG to detect denial of service attacks, and the IESG
       SHOULD act on such an event depending on the source of the
       requirements statement I-D and the perceived relevance of the work.
       The IESG might, for example, discuss the issue with the management of
       external organizations.

    9.  Acknowledgements

       The input given by 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.  Important discussions were
       held with the following participants in the ITU-T: Yoichi Maeda, Greg
       Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, George Newsome,
       Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, and Ben Mack-
       Crane.

       Thanks for further review comments to Brian Carpenter, Stewart
       Bryant, Sam Hartman, Mark Townsley, and Dave Ward.  Thanks to Spencer
       Dawkins for the GenArt review.

    Andersson & Farrel       Best Current Practice                 [Page 20]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    10.  IANA Considerations

       This document makes no specific requests to IANA for action.  The
       procedures described in this document assume that IANA will adhere to
       the allocation policies defined for the (G)MPLS codepoint registries
       and that the IETF will not endorse allocation of codepoints from
       those registries except where work has been carried out in accordance
       with the procedures described in this document.

    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", BCP 14, RFC 2119, March 1997.

       [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
                  Procedures", BCP 25, RFC 2418, September 1998.

       [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
                  IANA Considerations Section in RFCs", BCP 26, RFC 2434,
                  October 1998.

       [RFC4052]  Daigle, L., Ed., and Internet Architecture Board, "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, RFC 4053, April 2005.

       [RFC4775]  Bradner, S., Carpenter, B., Ed., and T. Narten,
                  "Procedures for Protocol Extensions and Variations", BCP
                  125, RFC 4775, December 2006.  2006.

    11.2.  Informative References

       [RFC3356]  Fishman, G. and S. Bradner, "Internet Engineering Task
                  Force and International Telecommunication Union -
                  Telecommunications Standardization Sector Collaboration
                  Guidelines", RFC 3356, August 2002.

    Andersson & Farrel       Best Current Practice                 [Page 21]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    Authors' Addresses

       George Swallow
       Cisco Systems
       EMail: swallow@cisco.com

       Deborah Brungard
       AT&T
       EMail: dbrungard@att.com

       Bill Fenner
       AT&T
       EMail: fenner@research.att.com

       Ross Callon
       Juniper Networks
       EMail: rcallon@juniper.net

       Kireeti Kompella
       Juniper Networks
       EMail: Kireeti@juniper.net

       Alex Zinin
       Alcatel
       EMail: zinin@psg.com

       Scott Bradner
       Harvard University
       EMail: sob@harvard.edu

    Editors' Addresses

       Loa Andersson
       Acreo AB
       EMail: loa@pi.se

       Adrian Farrel
       Old Dog Consulting
       EMail: adrian@olddog.co.uk

    Andersson & Farrel       Best Current Practice                 [Page 22]

    RFC 4929             MPLS and GMPLS Change Process             June 2007

    Full Copyright Statement

       Copyright (C) The IETF Trust (2007).

       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.

       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, THE IETF TRUST 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.

    Intellectual Property

       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.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Andersson & Farrel       Best Current Practice                 [Page 23]