<div class="moz-text-flowed" style="font-family: -moz-fixed">

Network Working Group                                       L. Andersson
Internet-Draft                                              Ericsson Inc
Intended status: Standards Track BCP                                             D. Ward
Expires: March 8, 9, 2010                                     Cisco Systems
                                                                M. Betts
                                                                 Huaweil
                                                               A. Farrel
                                                                  Huawei
                                                       September 8, 9, 2009

 Joint

               IETF and ITU-T Multi-Protocol Label Switching (MPLS)
              Transport Profile process

                   draft-ietf-mpls-tp-process-00.txt (MPLS-TP) Document Process

                    draft-ietf-mpls-tp-process-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 1, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The decision to develop a Multiprotocol Label Switching (MPLS)
   Transport Profile (MPLS-TP) in cooperation between the IETF and the
   ITU-T does not
   fully define and is document processes for development in RFC 5317 as the decision of the required
   RFCs. Joint Working
   Team on MPLS-TP.

   This document complements provides additional detail of the processes documented in for the JWT
   decision with a few separate elements; it:

   o
   development of IETF RFCs on MPLS-TP. It provides an adaptation of the
   IETF working group process,

   o process; identifies the expected participation in
   the process by the ITU-T,

   o ITU-T; and clarifies the decision rules and conventions
   regarding MPLS-TP documents.

   This document is doe not intended to specify any ITU-T process; to the
   extent necessary ITU-T activities
   will be done according to ITU-T process/rules.

   Nor is this

   This document is intended to does not specify or modify the normal IETF working
   group
   process, it process. It is limited to the temporary specific adaptations of that
   process
   that is to facilitate the cooperation agreement between the result of that IETF and ITU-T accepted the proposal in
   the JWT report to jointly develop
   the MPLS Transport Profile.  In
   general it may be said that these adaptations are introduced ITU-T on MPLS-TP, and to ensure a good and consistent document
   review across the two organizations.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .................................................. 4
     1.1. Terminology  . . . . . . . . . . . . . . . . . . . . . . . ............................................... 4
       1.1.1. IETF terms Terms and abbreviations . . . . . . . . . . . . .  5 Abbreviations .......................... 4
       1.1.2. ITU-T terms Terms and abbreviations  . . . . . . . . . . . .  5 Abbreviations ......................... 6
     1.2. Purpose and Intent of Cooperation on MPLS-TP .............. 6
   2. Adaptation of the IETF working group process . . . . . . . . .  7 Working Group Process .................. 8
     2.1.  Adaptation of the IETF working group process . . . . . . .  7 Consensus and Mailing Lists .......................... 8
     2.2. Communications with the ITU-T ............................. 8
     2.3. Adapted IETF Working Group Process ........................ 9
       2.3.1. Flow Chart ............................................ 9
       2.3.2. The IETF MPLS-TP process . . . . . . . . . . . . . . . . .  8
       2.2.1.  Developing a Process ............................. 11
     2.4. Naming Conventions for MPLS-TP document  . . . . . . . . . . . .  9 Documents ................. 15
   3. Expectations on ITU-T participation Participation in the process . . . . . . 14 Process ........... 16
     3.1.  Becoming a MEAD team document  . . . . . . . . . . . . . . 14 Team Document Review ................................ 17
     3.2.  Comments on MEAD team documents by participants in the
           ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Working Group Document Review ............................ 17
     3.3.  Poll for working group documents . . . . . . . . . . . . . 14
     3.4.  Responding to an IETF Working Group Last Call  . . . . . . 15
   4.  Specific guidelines that apply and Document Approval ............ 18
     3.4. Non-Response to work on Liaisons ................................. 19
   4. Guidelines For MPLS-TP work in the ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ..................... 20
   5. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 17 Considerations .......................................... 20
   6. Security considerations  . . . . . . . . . . . . . . . . . . . 18 Considerations ...................................... 20
   7. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19 .............................................. 21
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 ................................................... 21
     8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 ..................................... 21
     8.2. Informative References . . . . . . . . . . . . . . . . . . 20 ................................... 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 .............................................. 22

1. Introduction

   When

   The IETF and ITU-T have entered into the an agreement to develop MPLS-TP, the JWT
   Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP).
   This agreement included is known as the decision Joint Working Team on MPLS-TP (JWT)
   Agreement and is documented in [RFC5317]. The agreement states that the
   MPLS-TP documents
   should will be developed "according to documented in IETF processes".  It was also
   assumed RFCs, and assumes that there would will
   be close cooperation with the ITU-T in reviewing these IETF
   documents.  The JWT decision is documented in RFC 5317 [RFC5317].

   However, RFCs.

   This document provides additional detail of the process processes for this close cooperative review was mostly
   left to be decided the
   development of IETF RFCs on MPLS-TP as follows.

   o  It Provides an adaptation of the IETF working group process, with
      respect to the how the IETF will take input from the ITU-T on
      MPLS-TP topics.

   o  It identifies the expected participation by the ITU-T in the
      document development process, noting that the documents evolved.  The ITU-T has committed
      to responding promptly to IETF working group last calls, this calls in a way
      that may require the development of the response ITU-T to develop responses via
      correspondence.

   Nor is this

   o  It clarifies the rules regarding MPLS-TP documents.

   This document is intended to does not specify or modify the normal IETF working
   group
   process, it process. It is limited to the temporary specific adaptations of that
   process
   that is to facilitate the cooperation agreement between the result of that IETF and ITU-T accepted the proposal in
   the JWT report to jointly develop
   the MPLS Transport Profile.  In
   general it may be said that these adaptations are introduced ITU-T on MPLS-TP, and to ensure a good and consistent document
   review across the two organizations.

   This document complements the process as documented in the JWT
   decision with a few separate elements; it:

   o  Provides an adaptation of the IETF working group process, with
      respect to the role of the teams (MPLS Interoperability Design
      Team (MEAD Team), the Joint Working Team (JWT) and the ITU-T
      MPLS-TP ad hoc team) that has been set up to facilitate the
      development of MPLS-TP; see Section 2.

   o  Identifies the expected participation by the ITU-T in the document
      development process; see Section 3.

   o  Clarifies decision rules regarding MPLS-TP documents; see
      Section 4.

   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].
   Although this document is not a protocol specification, this language
   is used for clarity and decisiveness.

1.1. Terminology

   This section includes a number of terms and abbreviations that are
   used in this document. The section is split into two subsection; subsection:
   IETF terms and ITU-T terms.

1.1.1. IETF terms Terms and abbreviations Abbreviations

   o  JWT - Joint Working Team, a team with participants with experience
      from standards development in the IETF and the ITU-T.

      Note: The JWT is not part of either the IETF or ITU-T, but a group
      that has been set up to facilitate cooperation on MPLS-TP between
      the two organizations.

   o  JWT documents decision - the A set of documents envisioned recommendations on the procedural approach
      to the development of MPLS-TP made by the JWT and documented in
      [RFC5317].

   o  JWT agreement - The agreement between IETF and ITU-T based on the
      documentation
      JWT decision to jointly develop MPLS-TP according IETF processes.

   o  JWT documents - The set of documents envisioned in the JWT decision, see RFC 5317
      decision [RFC5317].

   o  MEAD team - MPLS Interoperability Design Team, a temporary team
      with participants with experience from standards development for
      MPLS and transport networks. The MEAD team is chartered to
      coordinate the development of MPLS-TP within the IETF and to
      coordinate the on MPLS-TP cooperation with the ITU-T.

   o  MPLS-TP documents - the The following sets of documents are counted as
      MPLS-TP documents:

      *  Internet Drafts  Internet-Drafts that are coordinated by the MEAD team.

      *  Individual Internet Drafts Internet-Drafts that addresses the MPLS-TP problem
         space.

      *  Working group Internet Drafts Internet-Drafts that addresses the MPLS-TP
         problem space.

      *  Internet Drafts  Internet-Drafts that are considered for publication as RFCs by
         the IESG and that addresses the MPLS-TP problem space.

      *  Internet Drafts  Internet-Drafts that are approved for publication as RFCs by
         the IESG and that addresses the MPLS-TP problem space.

      *  Published RFCs that addresses the MPLS-TP problem space.

      *  ITU-T Recommendations and draft Recommendations in various
         stages of development that addresses address the MPLS-TP problem space.

      Documents that originates originate from the IRTF RFC stream is are NOT
      considered as MPLS-TP documents.

   o  MPLS-TP mailing list - An IETF mailing list (mpls-tp@ietf.org)
      established specifically for the discussion of MPLS-TP issues
      within the IETF. The MPLS-TP list is the mailing list that is used
      decide consensus on MPLS-TP issues. This is an open mailing list
      with publicly available archives.

   o  MPLS-TP responsible working group chair - An IETF MPLS working
      group chair assigned responsibility for the IETF MPLS-TP effort
      by the IETF Routing Area Directors.

   o  MPLS-TP responsible AD - An IETF Routing Area Director with
      management responsibility for the MPLS-TP effort.

   o  IETF liaison to the ITU-T on MPLS - An individual assigned
      responsibility by the IAB for managing the liaison relationship
      to the ITU-T in regard of all issues concerning MPLS, including
      MPLS-TP.

1.1.2. ITU-T terms Terms and abbreviations Abbreviations

   o  Ad Hoc Team on MPLS-TP (ahtmplstp) - A team established by SG Study
      Group 15 of the ITU-T to coordinate the work on MPLS-TP within the
      ITU-T and to act as a focal point for communication with the IETF. IETF
      about MPLS-TP.

   o  Ad Hoc Team on MPLS-TP mailing list - An ITU-T mail exploder
      (ahmpls-tp@lists.itu.int) established specifically for the
      discussion and coordination of the MPLS-TP effort within the
      ITU-T.

   o  Contribution - a A contribution is a document that is submitted to
      the ITU-T to advance work on the development of a Recommendation
      or to propose the development of a new Recommendation.

   o  Recommendation - a A Recommendation is the an ITU-T standards document.

2.  Adaptation

1.2. Purpose and Intent of the IETF working group process Cooperation on MPLS-TP

   The IETF working group processes as defined in RFC 2026 [RFC2026] are
   for the purpose and objectives of the development activity on MPLS-TP updated as follows. is
   described in [RFC5317]. The IETF works according to a 'rough consensus' model, where working
   group chairs determine JWT decision includes the consensus after discussions on recognition
   that the mailing
   lists.  This design authority for MPLS (including MPLS-TP) is applicable the IETF.
   At the same time, the JWT decision recognises the role of the ITU-T
   in providing input (especially input to the requirements statements)
   to the development process for MPLS-TP. There is also a clear
   statement of expectation that the ITU-T's opinions will be heard
   within the IETF and must be properly considered during the
   development of MPLS-TP documents.

   The development of standards for MPLS-TP is, therefore, carried out
   within the IETF according to IETF process and with strong input from
   the ITU-T. This input takes three forms (see also Section 2.2):

   o  Active participation.

      All interested parties are encouraged to participate in the
      development of MPLS-TP standards within the IETF through the
      normal IETF process. In short, this involves the generation and
      documentation of new ideas as Internet-Drafts, and the discussion
      of work in progress through the IETF mailing lists. The IETF is
      not a membership organisation, and the mailing lists are open.

   o  Informal communication.

      It is recognised that discussions about MPLS-TP will take place
      within the Questions and Study Groups of the ITU-T. In order to
      speed up the development process and ensure smooth communications,
      the ITU-T is requested to make informal (i.e., email)
      communications to the IETF whenever any issues or questions
      arise. Informal communication can be sent by any individual or
      rapporteur of a Question as an email to the MPLS-TP mailing list.
      The chairs of the ahtmplstp may also summarise discussions within
      the ITU-T (especially those on the ahtmplstp mailing list) and
      communicate them to the IETF via email.

   o  Formal communication.

      The formal liaison process with the IETF is described in [RFC4052]
      and [RFC4053]. The process will be used for ensuring that specific
      progress steps are check-pointed and recorded, and for making sure
      that appropriate responses are generated in a timely manner.

   The objective of cooperation between the IETF and ITU-T is to ensure
   full participation of interested parties to make sure that all
   opinions are heard with the intention of producing sound and stable
   MPLS-TP documentation. It is understood that the neither the IETF nor
   the ITU-T should be in a position to block the work of the other body
   within its areas of authority. In the context of this document, this
   means that the ITU-T must not block IETF work on MPLS-TP against the
   IETF consensus view.

   Part of this process must be the understanding that all IETF
   documentation (including RFCs) can be revised or extended according
   to normal IETF procedures. Therefore, it is not a requirement that
   the first version of any RFC be perfect for all time (we do not need
   to "boil the ocean"); the initial aim of the work is to provide
   documentation of MPLS-TP as it is initially developed and deployed.

   Fundamental to understanding the process described in the rest of
   this document and to participating in the MPLS-TP development process
   is a working knowledge of the procedures of the IETF. Readers needing
   clarification of the IETF procedures are invited to read [RFC2026],
   [RFC4677], and [RFC4929]. Further clarification and guidance can be
   obtained from the MPLS-TP responsible working group chair, the MPLS-
   TP responsible AD, and the IETF liaison to the ITU-T on MPLS.

   The ITU-T may also develop Recommendations to document MPLS-TP. The
   JWT decision recognises that these Recommendations must not contain
   normative definitions of MPLS-TP (these are captured solely in IETF
   RFCs). Recommendations on MPLS-TP will be provided for review by the
   IETF to ensure conformance with the previous point and to verify that
   the material is consistent across MPLS-TP. The process for producing
   and reviewing Recommendations is out of scope for this document.

2. Adaptation of the IETF Working Group Process

   The IETF working group processes as defined in RFC 2026 [RFC2026] are
   adapted as described in this section solely for the purpose of the
   MPLS-TP work. These adaptations do not apply to any other topic or
   work also. within the IETF.

2.1. IETF Consensus and Mailing Lists

   The
   mpls-tp@ietf.org IETF works according to a 'rough consensus' model, where working
   group chairs determine the consensus after discussions on the mailing
   lists. This is also applicable to the MPLS-TP work. The MPLS-TP
   mailing list used exists to find out consensus focus all IETF discussions on MPLS-TP and
   consensus is determined by to
   avoid congesting other relevant working group mailing lists. All
   technical discussion on MPLS-TP SHOULD be directed to the MEAD team chair.  After a document has
   become MPLS-TP
   list, but other working group mailing lists SHOULD be notified when
   appropriate so that individuals can participate in the discussions on
   the MPLS-TP list.

   Consensus activities (such as a working group document last call) MUST be
   started on an working group mailing list, but the consensus is decided by MPLS-TP responsible
   working group chair MAY direct discussions to the WG
   chairs MPLS-TP list and
   MAY direct that consensus will be judged on that list.

2.2. Communications with the MEAD team chair jointly. ITU-T

   A most important part of this process is the information exchange
   between the IETF and ITU-T. This information exchange consists of
   two equally important pieces: pieces.

   o  informal  Informal information exchange

      this

      This is done primarily by E-Mail e-mail to the relevant mailing lists.
      Information sent from IETF, IETF areas and working groups, or from to the IETF MEAD team are ITU-T MUST be sent to and areas and the
      ahmpls-tp@lists.itu.int Ad Hoc MPLS-TP
      mailing list. Information sent from ITU-T to the IETF should e MUST be sent to the MEAD team (mead@ietf.org) and/or
      the mpls-tp@ietf.org
      MPLS-TP mailing list.

   o  formal  Formal information exchange

      In addition to E-Mail, the informal information exchange, a formal
      information exchange is accomplished by liaison correspondence
      between the two organisations. Exchange of liaisons makes it
      possible to follow the request/response exchange between the
      organisations in more
      detail.

2.1.  Adaptation detail, and to obtain an official view of the
      each organisation's position on any topic.

2.3. Adapted IETF working group process Working Group Process

2.3.1. Flow Chart

   The flow chart below describes the adaption of the working group
   process. The flow chart and the process as described in Section 2.3.2
   are equally normative.

          .............                   .............
          : Ind Docs  :------+  :--------+          : JWT docs  :
          .............        |          .............
                |              |                |
                | ind-00 (1) |  ind-00 (2)      | ind-00 (3)
                |(1)           |(2)             |(3)
                |              |                |
                v              |                v
        +-----------+          |      +----------------+  (4)  +-------+
        |
   +--->|  WG proc  |        +------->|          +----->| MEAD team proc |<----->| |------>| ITU-T |
   |    |           |-------+      +--|                |       +-------+
   |    +-----------+       |      |  +----------------+        (5)           |
    +->
   |   ind-00, ind-01, etc  |      |    ^  ind-00, ind-01, etc <-+<-----+     |(5)
   |          | (6)          |(6)          +--+---+       (6)    |       |(6)               |
   +----------+                |(7)            +-------------+     +-------+<-----------------+
      review                   +----+                   |         review
                               v
                       +-----------------+
                       | poll for wg doc -----------------+ |
                       +-----------------+
                               |(8)
                               | (7a)
                                    v
                               v
                        +-------------+       (8)     (9)      +-------+
                +----------> |
           +----------->|   wg doc    |<------------>|    |------------->| ITU-T |
           |            +-------------+              +-------+
           |              | +-> ^ wg-00, wg-01, etc        |
           |              | |      |(11)               |(10)
       (15)|          (12)| +------+<------------------+
           | (9)             | (10)
                |              | +----------+<----------------+
                |         (11)              |  review
           |              v
           |     +-----------------+     (12)    +---------+
          (14b) |     |
           +-----|  wg last call   |<----------->|  ITU-T  |   |
                 +-----------------+             +---------+
                |
                     |   ^       |
                |
                 (13)|     |(14a) | (15)
                |   |(14)   |(16)
                     v   |       |
                |
                  +---------+    |
                +-------|
                  |  ITU-T  |    |
                  +---------+    |
                                      |
                                 v
                            +-----------------+
                        +---------------+
                        |  req for publ pub  |
                            +-----------------+

2.2.
                        +---------------+

2.3.2. The IETF MPLS-TP process Process

   This section gives guidelines describes the development for how MPLS-TP documents. It sets
   out the process that is illustrated by the flow chart above could be
   traversed.

2.2.1.  Developing a MPLS-TP document in Section
   2.3.1. The numbered arrows in the flow chart are described as
   numbered steps in the process in the list below.

   Individual MPLS-TP documents may can take different paths through the
   this process, the numbers in the list below are mapped to the numbers
   in the flow chart above. process. Although the different paths through the flow chart are
   given as
   'options' options, it is always possible for a particular MPLS-TP
   Internet-Draft to be adopted as a working group draft. This is done
   on the MEAD team guidance of the MPLS-TP responsible working group chair and in
   cooperation with the relevant working group chairs and the document
   editors/authors.

   1.  Independent Documents through Working Group Processing

       Internet-Drafts MAY be introduced by their authors to describe
       any aspect of MPLS-TP. This option (compare with step 2) results
       in the document being discussed and take
   over reviewed by the shepherding of appropriate
       IETF working group as determined by the working group chairs. The
       normal IETF process will be applied, and the authors will revise
       the document (step 6) until it is adopted as a particular MPLS-TP Internet working group
       draft (see step 7).

       Any individual or group of individuals can create an Internet-
       Draft .  This through this step.

   2.  Independent Documents through MEAD Team Coordination

       Internet-Drafts MAY be brought to the MEAD team or initiated by
       the MEAD team. The MEAD team is done in cooperation between responsible for discussing,
       reviewing, and revising (step 6) the documents as independent
       drafts. The MEAD team chair, will solicit input from the relevant
   working group chairs ITU-T (step 4)
       and will publicise the document editors/authors.

   1.   They may be intended for and managed by a working group.

        This means that documents on the author, or authors, of such a document have
        chosen MPLS-TP mailing list to send
       encourage input from the IETF community. Normal IETF design team
       process will apply until the document to is adopted as a working
       group instead draft (see step 7).

       Any individual or group of
        running individuals can create an Internet-
       Draft through this step. However, the MEAD team.  Normal IETF process will kick in
        in such cases and working group chairs will agree team MAY decide that
       it is unwilling to which
        working group(s) such a document will be taken.

   2.   They may be coordinated by support the MEAD team.

        This means that document. In this case, the author, or authors, of such a document have
        chosen to send
       authors MAY bring the document to in following step 1.

   3.  Joint Working Team Originated Documents

       The JWT MAY initiate MPLS-TP documents, or request that the MEAD
       team to be coordinated
        with the rest create specific documents. The MEAD team MUST process these
       as independent submissions as described in step 2.

       [RFC5317] includes a list of the MPLS-TP JWT documents that is in the purview of
        the MEAD team.

   3.   They may MUST be originated
       considered by the MEAD team based to be processed on this step, but the JWT
        decision.

        In documentation of the work of the JWT, there is a proposed
        document structure.  The
       MEAD team used MAY vary this structure to decide
        on a set of documents that will, when completed, constitute the
        MPLS-TP standard.  This set of documents may change slightly, if
        - e.g. - list if, for example, it becomes more
       appropriate to split a single document into two or more, or if
       some new aspect of MPLS-TP needs to be specified.

   4.   Everytime  Every time a document is accepted by the MEAD team into the set
       of documents coordinated by the MEAD team a liaison is MUST be sent
       to the ITU-T with a pointer to that document. At the same time a
       note is SHOULD be sent to the Ad Hoc Team on MPLS-TP ad hoc team mailing list
       informing the list that the document has become a MEAD team
       document.

       Each time a document coordinated by the MEAD team is revised a
       note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list,
       and a liaison MAY be sent to the ITU-T to inform them of the
       progress of the document.

       The ITU-T may chose to MAY respond to the liaison these liaisons (step 5), but a response
       is not required to do so, see (see Section 3 and Section 4. 4).

   5.  At any time, it is possible for the ITU-T SG and Question participants to send review
       comments on MEAD team documents.  It
        is also possible for any MPLS-TP document. Such comments SHOULD be sent as
       comments to the MEAD team MPLS-TP mailing list according to ask normal IETF
       process.

       Additionally, this step provides for such reviews and
        comments.

        Any time such input communication from ITU-T
       Study Groups or requests are sent between the two
        organizations it SHALL Questions. These communications may be accompanied by
       unsolicited or in response to a note request from the MPLS-TP
        ad hoc team chair(s) IETF (step 4),
       and MAY be informal information exchanges or formal information
       exchanges (see Section 2.2). Such exchanges (informal or formal)
       SHOULD be accompanied by an email to the MEAD team MPLS-TP mailing list, or list
       from the ahtmplstp chair.

       The MEAD team chair SHOULD give due consideration to the issues raised
       in the communications received ITU-T, and SHOULD attempt to make
       suitable changes to the MPLS-TP ad hoc team mailing list.  This document or MUST otherwise
       explain why no change is done being made.

       Formal information exchanges MUST receive a response if
       requested. The IETF liaison to enhance the efficiency of ITU-T on MPLS and the information exchange.

   6.   A working group or
       addressees of the MEAD team may issue requests liaison are responsible for general ensuring that this
       step is completed.

   6.  Authors of independent documents SHOULD solicit comments on the
       MPLS-TP documents at mailing list and on any time, if it is deemed appropriate to extend these requests to IETF working group
       mailing lists. Comments can also be received from the MPLS-TP ad hoc team
        this is done via a note ITU-T as
       described for step 5.

       The authors SHOULD revise the documents according to entry (5) in this list. comments
       received from all sources, or explain why no changes been made.

   7.  If a an MPLS-TP document seems mature enough to become a working
       group document, a poll is done on the mpls-tp MPLS-TP mailing list and
       the appropriate working group mailing list (7), this request
        will also be sent to determine whether
       there is consensus to adopt the ITU-T document as a liaison (7a) and a note will
        also be sent to the MPLS-TP ad hoc team. working group
       document.

       Which working group a document goes into is decided jointly
        between by
       the MEAD team, MPLS-TP responsible working group chair and the chairs of the potential
       target working groups and the document editors/authors. group.

   8.  If the document is accepted as a working group document the
       working group takes over the revision control of the document.

        The ITU-T is expected to respond to
       Normal IETF working group process SHALL apply. All IETF
       discussions about the liaison within in document MUST now be held on the
        time indicated in MPLS-TP
       mailing list with notifications sent to the liaison, see Section 3 and Section 4.

   8.   Every time relevant IETF working
       group mailing list.

   9.  When a MPLS-TP document is accepted as a working group document by any IETF working group,
       informational notification MUST be sent to the ITU-T as a liaison
       and as an email to the ahtmplstp mailing list. No response to
       this liaison is expected.

       Each time an MPLS-TP document under working group control is
       revised a note SHOULD be sent to the
        ITU-T with Ad Hoc Team on MPLS-TP
       mailing list, and a pointer liaison MAY be sent to the ITU-T to inform
       them of the progress of the document.  At No response to these
       liaisons is expected.

       The IETF working group MAY solicit input from the same ITU-T at any
       time.

   10. At any time, it is possible for ITU-T participants to send review
       comments on any MPLS-TP document. Such comments SHOULD be sent as
       comments to the MPLS-TP mailing list according to normal IETF
       process.

       Additionally, this step provides for communication from ITU-T
       Study Groups or Questions (see Section 3.2). These communications
       may be unsolicited or in response to a note request from the IETF
       (step 8), and MAY be informal information exchanges or formal
       information exchanges (see Section 2.2). Such exchanges (informal
       or formal) SHOULD be accompanied by an email to the MPLS-TP
       mailing list from the ahtmplstp chairs.

       The document editors and the working group SHOULD give due
       consideration to the issues raised in the communications from the
       ITU-T, and SHOULD attempt to make suitable changes to the MPLS-TP
       document or MUST otherwise explain why no change is being made.

       Formal information exchanges MUST receive a response if
       requested. The IETF liaison to the ITU-T on MPLS is sent to responsible
       for ensuring that this step is completed.

   11. Editors working group documents SHOULD solicit comments on the
       MPLS-TP ad hoc team mailing list informing the
        list that the document has become a and on any appropriate IETF working group document.

   9.   Working group documents may
       mailing lists. Comments can also be reviewed in several steps, every
        time such a review is initiated received from the MPLS-TP ad hoc team is
        notified (10). ITU-T as
       described for step 9.

       The authors SHOULD revise the documents according to comments
       received from all sources.

       Note that most comments leading that lead to updates of working group
       documents are a result of spontaneous individual reviews and
       comments from the individual participants in the MPLS-TP effort.

   10.  Every time a review is initiated by a working group the
        appropriate ITU-T SGs and Questions will be notified by E-Mail
        to the MPLS-TP ad hoc team.

        Optionally the request for review may be accompanied by a
        liaison to formalize the request.

        The MPLS-TP ad hoc team is responsible for ensuring that any
        e-mail requests are copied/forwarded effort
       according to the relevant SGs and
        Questions.

   11. normal IETF process.

   12. When a an MPLS-TP document is deemed mature enough, a working group
       last call is initiated.  At this time the action describe under item
        12 in this list MUST be executed.

   12.  Procedures to be followed when initiated following normal IETF process.

   13. When a working group last call is
        initiated. initiated for any MPLS-TP
       document the following actions MUST be taken.

       * A liaison containing a request for participation in the working
         group last call will MUST be sent to the appropriate ITU-T
           SGs Study
         Groups and Questions.

         The ad hoc team on MPLS-TP is expected to verify that all the
         Study Groups and Questions within the ITU-T that need to
         respond to the working group last call are aware that it has
         been issued.

       * A notification that the working group last call is taking place will
         MUST be provided sent to the MPLS-TP ad hoc team via E-Mail
           sent ahtmplstp mailing list and to the MPLS-TP
         mailing list.

        *

   14. The ITU-T is REQUIRED to respond to the liaison in step 13 within
       the time
           indicated.  The MPLS-TP ad hoc team is expected to verify
           that all indicated in the SGs and Questions within liaison (see Section 3.3). This
       deadline will usually be set according to the timeline of the
       working group last call.

       The ITU-T that need to
           respond response MUST either include comments to be taken under
       consideration by the working group along with other last call are aware
       comments, or provide a statement that it the ITU-T has
           been issued.

   13.  When all last call comments are addressed and/or responded to, no comment.
       The latter case SHALL be interpreted as ITU-T approval for the
       publication of the document will be sent as an RFC.

       The working group and document editors MUST fully address any
       comments received from the ITU-T under this step either making
       the requested changes, or discussing the changes with the ITU-T
       to reach a consensus position on the ITU-T, asking MPLS-TP mailing list.

   15. According to normal IETF process, if the last call comments are
       substantial the document
        is ready to MUST be sent returned to the IESG with a request working group
       for publication.
        The response sought from ITU-T is either an acknowledgment that revision and discussion. This MAY necessitate further
       communication with the document is ready ITU-T (step 9) to publish clarify or a response that there is
        further work that needs to be done.

        Note: WG resolve
       issues raised during ITU-T review.

       The working group last call may MAY be re-iterated, repeated multiple times for
       revisions of the entire document
        or limited to only verify document. As is normal IETF process, the updates made because of an earlier working
       group chairs MAY issue subsequent working group last call.

   14.  The ITU-T has one week to respond (yes calls for
       the entire document or no) MAY be limited to only the question
        posed in (13).

        The answer can be either "yes - go ahead" (14a), updated text in which case
       the Working Group will request publication; document. In the latter case, further comments from within
       the IETF or ...

        ... it can from the ITU-T SHOULD be "no - more work is needed" (14b), in which case it
        will go back into limited as instructed by the normal
       working group process chair.

       Note that, according to identify
        what is needed.

   15.  When the ITU-T gives normal IETF process, if the final acknowledgement (14a), a request
        for publication will last call
       comments are minor, they SHOULD be sent to addressed by the IESG (15).

        The document that is sent to the ITU-T
       editors in step (13) coordination with the working group chairs and which
        generates a positivie response from ITU-T (14a) is sent
        unchanged, save for editorial changes, with
       notification to the IESG MPLS-TP mailing list.

   16. When all last call comments have been addressed or responded to
       and all necessary working group last calls have been held, the
       working group chairs of the owning working group with a assistance
       of the MPLS-TP responsible working group chair will request for
       publication (15) of the document as a RFC. an RFC following normal IETF
       process.

       Once this request for publication is sent, the last point in
        this process where it sent there is acceptable to allow no further
       scope for the ITU-T to influence in the development of a document is passed. the document.
       After this point, the document will be handled as any other IETF document.

2.2.1.1.
       document with individual comments made during IETF last call, and
       with IESG review following.

       Note that if these later stages in the publication process cause
       significant changes to the document, it MAY be fully or partially
       returned to the working group, in which case some form of WG last
       call with ITU-T consultation MUST take place following from step
       12 as outlined above.

2.4. Naming conventions Conventions for MPLS-TP Internet Drafts Documents

   To make it easier to search in the IETF Internet Draft repositories
   the Internet-Draft repositories,
   the following guidelines should rules MUST be followed for naming the MPLS-TP
   Internet Draft filenames. Internet-
   Draft.

   o  All MPLS-TP Internet Draft should Internet-Draft MUST include the sequence "mpls-tp"
      in the filename.

   o  Individual MPLS-TP Internet Draft should Internet-Draft MUST be named according to
      this format:

      draft-name-mpls-tp-topic-??.txt

      "name" is the last name of the main editor, or an acronym
      indicating the last names of the set of editors.

      "topic" indicates the content of the draft, e.g. "oam-framework".

      "??" indictes indicates a two digit version number, starting with "00".

   o  MPLS working group documents should MUST be named according to this
      format: as follows:

      draft-ietf-mpls-tp-topic-??.txt

      "topic" indicates the content of the draft, e.g. "oam-framework".

      "??" indicates a two digit version number, starting with "00".

   o  MPLS-TP documents from other working groups shouldbe MUST be named
      according to this format:

      draft-ietf-wg-name-mpls-tp-topic-??.txt

      "wg-name"

      draft-ietf-wgname-mpls-tp-topic-??.txt

      "wgname" is the acronym for any working group chartered to do
      MPLS-TP work, e.g. pwe3 or ccamp.

      "topic" indicates the content of the draft, e.g. "oam-framework".

      "??" indicates a two digit version number, starting with "00".

3. Expectations on ITU-T participation Participation in the process Process

   The IETF and ITU-T processes looks for input from the development of the MPLS-TP
   standards interconnect ITU-T at the following point three key points in the flow chart
   above: (4), (5), (7a), (8), (10)
   process described in Section 2.

   o  Steps 4 and 5 : Review of MEAD Team Documents
   o  Steps 9 and 10 : Review of Working Group Documents

   o  Steps 13 and 14 : Working Group Last Call and (12). Document Approval

   This section briefly describes what is expected the IETF expects to happen on the
   ITU-T side at the these interaction points.

3.1.  Becoming a MEAD team document

   (4) is a point at which the MEAD team communicates to the Team Document Review

   The ITU-T that
   a document is considered may provide input to be accepted for coordination documents that are being developed by
   the MEAD team. These documents are individual Internet-Drafts (that
   is, they have not been adopted by a working group), but they form
   part of the formal IETF MPLS-TP effort and are open for informal and
   formal comment by the ITU-T and its participants.

   As shown by step 4 in the process described in Section 2, the IETF
   will notify the ITU-T of the existence of such documents and will
   normally inform the ITU-T of new revisions. The ITU-T is expected not
   required to respond to the communication with a simple
   ACK these communications.

   The IETF may also request review or NAK, however a non-response is counted as an ACK.

   An ACK means that ITU-T accepts that the document has become a discussion of MEAD team document, a NAK means that
   documents. The ITU-T has issues that needs to be
   resolved before the document is allowed required to progress.

3.2.  Comments on MEAD team documents respond to this type of
   communication if it is a formal liaison (step 5) within the deadline
   set by participants in the ITU-T

   (5) liaison (see Section 3.4). In this case, it should either
   send a liaison response with comments and (10) offer possibilities for ITU-T, questions, or people active in it should
   acknowledge the
   ITU-T, liaison from the IETF saying that there are no
   questions or comments at this time. The latter type of response will
   not be taken by the IETF to imply any form of support for the
   document unless it is explicitly expressed.

   Additionally, the ITU-T may send un-triggered comments unsolicited communications on a MEAD
   team document as either informal or working group
   documents.  Such formal communications (step 5).
   Formal communications may request a response from the IETF.

   However, ITU-T participants are encouraged to bring their comments shall be sent
   and questions to the mpls-tp MPLS-TP mailing list directly, because this will
   be more efficient and for
   working group documents also conforms to the appropriate working group mailing
   list. normal IETF process. Comments
   received in this way will be treated in the same way
   any as other individual comments received on the IETF documents.

3.3.  Poll for working group documents

   (7a) is given full consideration by the point at which an IETF working group informs MEAD
   team and the ITU-T
   that a poll to progress a document authors.

3.2. Working Group Document Review

   The ITU-T may provide input to an documents that are being developed by
   IETF working group document
   has been started.

   It is not necessary, or required, groups. They are open for informal and formal comment by
   the ITU-T to respond to this
   message.  If and its participants.

   As shown by step 9 in the ITU-T has serious concerns these should be provided
   via a liaison statement.  If process described in Section 2, the IETF
   will notify the ITU-T has no serious concerns it is
   allowed and encouraged that individual participants provide comments.
   Such responses shall be sent to of the appropriate working group and
   mpls-tp mailing lists existence of such documents and represent will
   normally inform the view ITU-T of the person sending
   the mail.

   An Internet Draft new revisions. The ITU-T is ready not
   required to become a respond to these communications.

   The IETF may also request review or discussion of working group draft
   documents. The ITU-T is required to respond to this type of
   communication if it
   meets at least the three criteria below.

   o  it is a formal liaison (step 10) within the charter of deadline
   set by the working group

   o liaison (see Section 3.4). In this case, it addresses should either
   send a problem that needs to be solved

   o liaison response with comments and questions, or it is a good enough start toward solving should
   acknowledge the liaison from the IETF saying that there are no
   questions or comments at this problem

   Responses time. The latter type of response will
   not be taken by the IETF to polls checking if a imply any form of support for the
   document unless it is ready to become explicitly expressed.

   Additionally, the ITU-T may send unsolicited communications on a
   working group document should be limited as either informal or formal communications
   (step 5). Formal communications may request a response from the IETF.

   However, ITU-T participants are encouraged to bring their comments
   and questions to considering if the
   document meets those three criteria.

3.4.  Responding MPLS-TP mailing list directly, because this will
   be more efficient and conforms to an the normal IETF process. Comments
   received in this way will be treated in the same way any as other
   individual comments received on IETF documents.

3.3. Working Group Last Call

   (12) is the point in the process where ITU-T is made aware of that an
   IETF working group last call has been started.  The and Document Approval

   A working group last call is issued when a working group document is getting
   close to being ready for publication. publication as an RFC. The intention is to
   make sure that there are no important pieces missing and missing, that technical
   details are
   correct. correct, and that there is consensus within the working
   group for moving forward. Consensus for MPLS-TP documents is judged
   on the designated mailing list (normally the MPLS-TP mailing list) by
   the chairs of the working group that has developed the document in
   association with the MPLS-TP responsible working group chair.

   During working group last call for all MPLS-TP documents the ITU-T
   will always be consulted about the content of the documents. The
   purpose of this step (step 13) is to ensure that the documents
   address the needs and requirements of the ITU-T participants.

   A formal communication will be made to the ITU-T to make it aware
   that an IETF working group last call has been started and requesting
   review and comment. According to the JWT decision decision, the ITU-T is
   required to respond to a liaison about a working group last call
   within the time set in announcing the working group last call. ITU-T
   participants need to be aware that this step in the process
   represents their last chance to influence the document from within
   the ITU-T, and the liaison response needs to contain all issues and
   comments - there will not be any scope to raise further concerns at a
   later date.

   The chair of an IETF working group that starts a working group last
   call will send a liaison to the ITU-T announcing the working group
   last call. A message will also be sent to the MPLS-TP ad hoc team.

   The IETF will make a best effort attempt to target the SGs ITU-T Study
   Groups and Questions that should be involved in responding to the
   working group last call. However, the ITU-T has to must make sure that the
   appropriate entities within the ITU-T participate in responding responding to
   the working group last call. The ITU-T ad hoc team on MPLS-TP
   coordinates the development of the ITU-T response to the working
   group last call.

   The response to a working group last call should be unambiguous and
   as detailed as possible. The liaison response is not intended to
   start a conversation for clarification. It is intended to make clear
   statements of technical issues to be addressed and to propose
   resolutions for those issues. Acceptable responses include:

   o  No issues found. The ITU-T approves publication of the Internet-
      Draft as an RFC in its current form.

   o  Minor issues found or questions raised. Please consider fixes to
      these issues or respond to these questions before publication of
      the Internet-Draft as an RFC.

   o  Major issues found. Please address these issues and allow the
      ITU-T to review the resolution (possibly during a further working
      group last call) before proceeding to publication of the Internet-
      Draft as an RFC.

   Note that, as described in Section 1.2, the cooperation process is
   designed to ensure constructive consideration and resolution of all
   issues raised by the ITU-T without being blocking on the progress of
   the IETF's work on MPLS-TP. It is expected that discussion of major
   issues raised at this stage of the process will be conducted on the
   MPLS-TP mailing list and through appropriate communication with the
   ITU-T. It is further expected that such issues will be resolved
   through technical evaluation and rough consensus judged as normal for
   the IETF process. In the event that agreement between the IETF and
   ITU-T cannot be reached on some technical point, the JWT will be
   convened to seek a resolution.

3.4. Non-Response to Liaisons

   The liaison relationship between the IETF and the ITU-T is founded on
   the understanding that each party will respond in a timely and
   appropriate manner to the other party's liaisons so long as
   reasonable notice is given.

   Failure to respond by a deadline properly expressed in a liaison must
   not be used to cause deadlock or to block advancement of work. Such
   failures shall be assumed to represent accidental errors or
   oversights and shall be brought to the working
   group last call.  The ITU-T MPLS-TP ad hoc team coordinates attention of the
   development management of
   the ITU-T response body that has failed to respond.

   In extreme cases, the working group last call.

4.  Specific guidelines that apply JWT is empowered to work on convene to resolve issues
   of failed communications.

4. Guidelines For MPLS-TP work in the ITU-T

   These guidelines apply to progressing work on MPLS-TP in the ITU-T.

   Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T
   Study Group or Question.

   Before the ITU-T initiates any new work (i.e. items not previously
   identified by the JWT) based on such contributions the ITU-T shall
   send a liaison to the IETF. The message will go to the MEAD team, IETF
   liaison to the ITU-T on MPLS, the MPLS-TP responsible working
   group chair and the team is MPLS-TP responsible AD. They are responsible
   for creating sending a consolidated IETF response from the IETF, but may
   delegate the work of writing the response.

   The IETF is expected to must respond to such liaisons according to the information deadline
   in the liaison. Acceptable responses include:

   o  Acknowledgement of receipt and agreement that a new the ITU-T is
      clear to proceed with the work described.

   o  Request that the work described be transferred from the ITU-T to
      the IETF in the form of an Internet-Draft to form part of the
      MPLS-TP work item has in the IETF.

   o  Request that the work be put on hold until specific issues have
      been proposed with an ACK or NAK.

      If resolved. In the event that this response is seen as
      blocking of ITU-T work, the JWT may be convened to seek a NAK
      resolution.

   Note that work item is held until the issues process described in this section is resolved. conformant to the
   Change Process for Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929].

5. IANA considerations Considerations

   There are no requests for IANA allocation of code points in this
   document.

6. Security considerations Considerations

   This document defines a process adaptation for the cooperation
   between IETF and ITU-T and thus does not introduce any new security
   considerations.

   The successful development of MPLS-TP standards that are consistent
   across the industry is an essential component to ensuring the
   security and stability of MPLS networks.

7. Acknowledgments

   Thanks to Eric Gray who helped with grammar and useful comments.
   Thanks to Tom Petch who spent time trying to sort out what I wanted
   to say the
   document said, and has who sent comments that helped clarify the
   document.

8. References

8.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.

8.2. Informative References

   [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.

   [RFC4677]  Hoffman, P. and Harris, S., "The Tao of IETF: A Novice's
              Guide to the Internet Engineering Task Force", RFC 4677,
              September 2006.

   [RFC4929]  Andersson, L. and Farrel, A., "Change Process for
              Multiprotocol Label Switching (MPLS) and Generalized MPLS
              (GMPLS) Protocols and Procedures", BCP 129, RFC4929, June
              2007.

   [RFC5317]  Bryant, S. and L. Andersson, "Joint Working Team (JWT)
              Report on MPLS Architectural Considerations for a
              Transport Profile", RFC 5317, February 2009.

Authors' Addresses

   Loa Andersson
   Ericsson Inc

   Email: loa.andersson@ericsson.com

   David Ward
   Cisco Systems

   Email: dward@cisco.com

   Malcolm Betts
   Huaweil
   Huawei

   Email: malcolm.betts@huawei.com

   Adrian Farrel
   Huawei

   Email: adrian.farrel@huawei.com

</div>