[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-andersson-mpls-tp-process) 00 01 02 03 04 05

Network Working Group                                    A. Farrel (Ed.)
Internet-Draft                                       Huawei Technologies
Intended status: BCP                                        L. Andersson
Expires: July 24, 2010                                     Ericsson Inc.
                                                                 D. Ward
                                                        Juniper Networks
                                                                M. Betts

                                                        January 24, 2010


               IETF Multi-Protocol Label Switching (MPLS)
              Transport Profile (MPLS-TP) Document Process

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

Status of this Memo

   This Internet-Draft is submitted 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.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Andersson, et al.        Expires July 24, 2010                  [Page 1]


Internet-Draft          MPLS-TP Document Process            January 2010


Abstract

   The decision to develop a Multiprotocol Label Switching (MPLS)
   Transport Profile (MPLS-TP) in cooperation between the IETF and the
   ITU-T is document in RFC 5317 as the decision of the Joint Working
   Team on MPLS-TP.

   This document provides additional detail of the processes for the
   development of IETF RFCs on MPLS-TP. It provides an adaptation of the
   IETF working group process; identifies the expected participation in
   the process by the ITU-T; and clarifies the rules and conventions
   regarding MPLS-TP documents.

   This document does not specify any ITU-T process; ITU-T activities
   will be done according to ITU-T process/rules.

   This document does not specify or modify the normal IETF working
   group process. It is limited to the specific adaptations of that
   process to facilitate the cooperation agreement between the IETF and
   the ITU-T on MPLS-TP, and to ensure a good and consistent document
   review across the two organizations.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network.























Andersson, et al.        Expires July 24, 2010                  [Page 2]


Internet-Draft          MPLS-TP Document Process            January 2010


Table of Contents

   1. Introduction ................................................... 4
     1.1. Terminology ................................................ 4
       1.1.1. IETF Terms and Abbreviations ........................... 5
       1.1.2. ITU-T Terms and Abbreviations .......................... 6
     1.2. Purpose, Intent, and Procedures for Cooperation on MPLS-TP . 6
     1.3. A Note on the MPLS-TP Interoperability Design Team ......... 8
   2. Adaptation of the IETF Working Group Process ................... 8
     2.1. IETF Consensus and Mailing Lists ........................... 9
     2.2. Communications with the ITU-T .............................. 9
     2.3. Adapted IETF Working Group Process ........................ 10
       2.3.1. Flow Chart ............................................ 10
       2.3.2. The IETF MPLS-TP Process .............................. 12
     2.4. Naming Conventions for MPLS-TP Documents .................. 16
     2.5. Boilerplate Text For Inclusion in MPLS-TP Documents ....... 16
       2.5.1. Abstract .............................................. 17
       2.5.2. Introduction .......................................... 17
       2.5.3. Recognition of IETF Consensus for Informational RFCs .. 17
   3. Expectations on ITU-T Participation in the Process ............ 17
     3.1. Working Group Document Review ............................. 18
     3.2. Working Group Last Call and Document Approval ............. 18
     3.3. Non-Response to Liaisons .................................. 21
   4. Guidelines For MPLS-TP work in the ITU-T ...................... 21
   5. IANA Considerations ........................................... 22
   6. Security Considerations ....................................... 22
   7. Acknowledgments ............................................... 22
   8. References .................................................... 22
     8.1. Normative References ...................................... 22
     8.2. Informative References .................................... 22
   Authors' Addresses ............................................... 23



















Andersson, et al.        Expires July 24, 2010                  [Page 3]


Internet-Draft          MPLS-TP Document Process            January 2010


1. Introduction

   The IETF and ITU-T have entered into an agreement to develop the
   Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP).
   This agreement is known as the Joint Working Team on MPLS-TP (JWT)
   Agreement and is documented in [RFC5317]. The agreement states that
   MPLS-TP will be documented in IETF RFCs, and assumes that there will
   be close cooperation with the ITU-T in reviewing these RFCs. This
   cooperation will include review of the work at all stages of
   drafting.

   This document provides additional detail of the processes for the
   development of IETF RFCs on MPLS-TP as follows.

   o  It Provides an adaptation of the IETF working group process, with
      respect to 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 ITU-T has committed
      to responding promptly to IETF working group last calls in a way
      that may require the ITU-T to develop responses via
      correspondence.

   o  It clarifies the rules regarding MPLS-TP documents.

   This document does not specify or modify the normal IETF working
   group process. It is limited to the specific adaptations of that
   process to facilitate the cooperation agreement between the IETF and
   the ITU-T on MPLS-TP, and to ensure a good and consistent document
   review across the two organizations.

   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.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunication Union Telecommunication
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network.

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:


Andersson, et al.        Expires July 24, 2010                  [Page 4]


Internet-Draft          MPLS-TP Document Process            January 2010


   IETF terms and ITU-T terms.

1.1.1. IETF Terms and 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 decision - A set of 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
      JWT decision to jointly develop MPLS-TP according IETF processes.

   o  JWT documents - The set of documents envisioned in the JWT
      decision [RFC5317].

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

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

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

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

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

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

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

      Documents that originate from the IRTF RFC stream or the
      Independent Submission Stream 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


Andersson, et al.        Expires July 24, 2010                  [Page 5]


Internet-Draft          MPLS-TP Document Process            January 2010


      usually used to decide consensus on MPLS-TP issues (although other
      IETF mailing lists, such as WG lists, may be used). 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.

   o  Contribution - Within the IETF, a contribution is any submission
      to the IETF intended by the Contributor for publication as all or
      part of an Internet-Draft or RFC, and any statement made within
      the context of an IETF activity. Such statements include oral
      statements in IETF sessions as well as written and electronic
      communications. For more information on the IETF definition of a
      contribution see [RFC5378].

1.1.2. ITU-T Terms and Abbreviations

   o  Ad Hoc Team on MPLS-TP (ahtmplstp) - A team established by 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
      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 - Within the ITU-T, 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 Recommendation is an ITU-T standards document.

1.2. Purpose, Intent, and Procedures for Cooperation on MPLS-TP

   The purpose and objectives of the development activity on MPLS-TP is
   described in [RFC5317]. The JWT decision includes the recognition
   that the design authority for MPLS (including MPLS-TP) is the IETF.


Andersson, et al.        Expires July 24, 2010                  [Page 6]


Internet-Draft          MPLS-TP Document Process            January 2010


   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.

   It should be noted that other related technologies (espeically those
   for core MPLS and pseudowire deployments) do not fall within this
   cooperation agreement. The IETF will continue to develop Internet
   technologies as before and welcomes particpation from all
   individuals. Where such developments overlap with MPLS-TP such that
   they are important to the work on MPLS-TP, they will form part of the
   cooperation project.

   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 Ad Hoc Team on MPLS-TP may also summarise
      discussions within the ITU-T (especially those on the Ad Hoc Team
      on MPLS-TP 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.


Andersson, et al.        Expires July 24, 2010                  [Page 7]


Internet-Draft          MPLS-TP Document Process            January 2010


      Formal liaison communications may be marked as "For Action," "For
      Comment," or "For Information" depending on the level of feedback
      that is required. Where formal liaison communication is indicated
      in this document, the type of liaison that is advised in each
      instance is also indicated.

   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 can 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 cannot 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.

1.3. A Note on the MPLS-TP Interoperability Design Team

   The MPLS Interoperability Design Team (the MEAD team) was a design
   team established within the IETF with participants with experience
   from standards development for MPLS and transport networks. The MEAD
   team was chartered to coordinate the development of MPLS-TP within
   the IETF and to create the initial document set before the work was
   taken to the IETF working groups in the usual way.

   The MEAD team was also responsible for coordinating cooperation with


Andersson, et al.        Expires July 24, 2010                  [Page 8]


Internet-Draft          MPLS-TP Document Process            January 2010


   the ITU-T on the Internet-Drafts it was working on.

   The MEAD team completed its work and was closed in October 2009.

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 within the IETF.

2.1. IETF Consensus and Mailing Lists

   The 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 exists to focus all IETF discussions on MPLS-TP and to
   avoid congesting other relevant working group mailing lists. All
   technical discussion on MPLS-TP SHOULD be directed to the 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 last call) MUST be
   started on an working group mailing list, but the MPLS-TP responsible
   working group chair SHOULD direct discussions to the MPLS-TP list and
   SHOULD direct that consensus will be judged on that list. The working
   group chair MAY direct discussion and consensus to a specific working
   group mailing list.

2.2. Communications with the 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.

   o  Informal information exchange

      This is done primarily by e-mail to the relevant mailing lists.
      Information sent to the ITU-T MUST be sent to the Ad Hoc Team on
      MPLS-TP mailing list. Information sent to the IETF MUST be sent to
      the MPLS-TP mailing list.

   o  Formal information exchange

      In addition to the informal information exchange, a formal
      information exchange is accomplished by liaison correspondence
      between the two organisations. Exchange of liaisons makes it


Andersson, et al.        Expires July 24, 2010                  [Page 9]


Internet-Draft          MPLS-TP Document Process            January 2010


      possible to follow the request/response exchange between the
      organisations in more detail, and to obtain an official view of
      each organisation's position on any topic.

      Formal liaisons SHOULD include tracking numbers in their subject
      lines to facilitate easy coordination of responses with the
      requests to which they are associated.

2.3. Adapted IETF 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.



































Andersson, et al.        Expires July 24, 2010                 [Page 10]


Internet-Draft          MPLS-TP Document Process            January 2010


                         .............
                         : Ind Docs  :
                         .............
                               |
                               |(1)
                               v
                       +---------------+
                       |   WG Process  |
                       +---------------+
                        |  ^ ind-00, ind-01, etc
                        |  |       |
                        |  |       |(2)
                        |  |       |
                        |  +-------+
                     (3)|   review
                        |
                        v
                      +-----------------+
                      | Poll for WG Doc |
                      +-----------------+
                               |
                               |(4)
                               v
                        +-------------+     (5)   +-------+
            +---------->|   WG Doc    |---------->| ITU-T |
            |           +-------------+           +-------+
            |             | ^ wg-00, wg-01, etc     |
            |             | |      |                |
            |             | |      |(7)             |(6)
            |             | |      |                |
        (11)|          (8)| +------+-<--------------+
            |             |  review
            |             v
            |    +-----------------+
            +----|  WG Last Call   |
                 +-----------------+
                     |   ^       |
                  (9)|   |(10)   |(12)
                     v   |       |
                  +---------+    |
                  |  ITU-T  |    |
                  +---------+    |
                                 v
                        +---------------+
                        |  Req for Pub  |
                        +---------------+




Andersson, et al.        Expires July 24, 2010                 [Page 11]


Internet-Draft          MPLS-TP Document Process            January 2010


2.3.2. The IETF MPLS-TP Process

   This section describes the development for MPLS-TP documents. It sets
   out the process that is illustrated by the flow chart 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 can take different paths through the
   this process. Although the different paths through the flow chart are
   given as 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 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 results in the document being
       discussed and reviewed by the 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
       2) until it is adopted as a working group draft (see step 3).

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

   2.  Authors of independent documents SHOULD solicit comments on the
       MPLS-TP mailing list and on any appropriate IETF working group
       mailing lists.

       The authors SHOULD revise the documents according to comments
       received from all sources, or explain why no changes been made.

   3.  If an MPLS-TP document seems mature enough to become a working
       group document, a poll is done on the MPLS-TP mailing list and
       the appropriate working group mailing list to determine whether
       there is consensus to adopt the document as a working group
       document.

       Which working group a document goes into is decided jointly by
       the MPLS-TP responsible working group chair and the chairs of the
       target working group.

   4.  If the document is accepted as a working group document the
       working group takes over the revision control of the document.
       Normal IETF working group process SHALL apply. All IETF
       discussions about the document MUST now be held on the MPLS-TP


Andersson, et al.        Expires July 24, 2010                 [Page 12]


Internet-Draft          MPLS-TP Document Process            January 2010


       mailing list with notifications sent to the relevant IETF working
       group mailing list.

   5.  When a document is accepted as a working group document, a
       liaison MUST be sent to the ITU-T to inform them of the progress.
       This liaison SHOULD be "for comment", but if the document is not
       yet in a fit state for review the liaison MAY be "for
       information". No response to this liaison is required.

       An email to the Ad Hoc Team on MPLS-TP mailing list MUST be sent
       in parallel with the liaison.

       Each time an MPLS-TP document under working group control is
       revised a note SHOULD be sent to the Ad Hoc Team on MPLS-TP
       mailing list, and a liaison SHOULD be sent to the ITU-T to inform
       them of the progress of the document. This liaison SHOULD be "for
       comment" to allow for further review by the ITU-T, but MAY be
       "for information" if the document is not in a fit state for
       review or if there is no change in substance of the document
       since the previous liaison. No response to these liaisons is
       required.

       The IETF working group MAY solicit input from the ITU-T at any
       time by sending a liaison for comment.

   6.  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 request from the IETF
       (step 5), 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 Ad Hoc Team on MPLS-TP chairs.

       The document editors and the working group MUST 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 responsible
       for ensuring that this step is completed.




Andersson, et al.        Expires July 24, 2010                 [Page 13]


Internet-Draft          MPLS-TP Document Process            January 2010


   7.  Editors of working group documents SHOULD solicit comments on the
       MPLS-TP mailing list and on any appropriate IETF working group
       mailing lists. Comments SHOULD also be solicited from the ITU-T
       as "early review" using a liaison for comment (step 5). Comments
       from the ITU-T may, therefore, be solicited or unsolicited and
       are handled as described for step 6.

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

       Note that most comments 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
       according to normal IETF process.

   8.  When an MPLS-TP document is deemed mature enough, a working group
       last call is initiated following normal IETF process. The working
       group chairs are responsible for judging when to initiate this
       last call.

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

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

         The Ad Hoc Team on MPLS-TP chairs are 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
         MUST be sent to the Ad Hoc Team on MPLS-TP mailing list and to
         the MPLS-TP mailing list.

   10. The ITU-T is REQUIRED to respond to the liaison in step 9 using a
       liaison within the time indicated in the liaison (see Section
       3.2). This deadline will usually be set according to the timeline
       of the working group last call.
       The ITU-T response MUST either include comments to be taken under
       consideration by the working group along with other last call
       comments, or provide a statement that the ITU-T has no comment.
       The latter case SHALL be interpreted as ITU-T support for the
       publication of the document as an RFC.

       The working group and document editors MUST fully address any
       comments received from the ITU-T via liaison under this step


Andersson, et al.        Expires July 24, 2010                 [Page 14]


Internet-Draft          MPLS-TP Document Process            January 2010


       either making the requested changes, or discuss the changes with
       the ITU-T to reach a consensus position on the MPLS-TP mailing
       list. The Rapporteur of the question that generated the liaison
       statement is responsible for ensuring that the ITU participants
       have visibility and input to the IETF WG comment resolution
       process. If the changes are not as requested by the ITU liaison
       the Rapporteur who was responsible for the generation of the
       original liaison should generate another liaison statement
       indicating if the resolution of the comments is acceptable to the
       ITU-T.

   11. According to normal IETF process, if the last call comments are
       substantial the document MUST be returned to the working group
       for revision and discussion. This MUST involve further
       communication with the ITU-T (step 5) to clarify or resolve
       issues raised during ITU-T review if they are handled other than
       as requested by the ITU-T.

       The working group last call (step 8) MAY be repeated multiple
       times for revisions of the document. As is normal IETF process,
       the working group chairs MAY issue subsequent working group last
       calls for the entire document or MAY limit them to only the
       updated text. In the latter case, further comments from within
       the IETF or from the ITU-T SHOULD be limited as instructed by the
       working group chair.

       Note that, according to normal IETF process, if the last call
       comments are minor, they SHOULD be addressed by the document
       editors in coordination with the working group chairs and with
       notification to the MPLS-TP mailing list.

   12. 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 assistance
       of the MPLS-TP responsible working group chair will request
       publication of the document as an RFC following normal IETF
       process.

       Once this request for publication is sent, the document will be
       handled as any other IETF document with individual comments made
       during IETF last call, and with IESG review following. Therefore,
       after this point there is no further scope for ITU-T experts to
       influence the development of the document other than as
       individual contributors.

       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


Andersson, et al.        Expires July 24, 2010                 [Page 15]


Internet-Draft          MPLS-TP Document Process            January 2010


       call with ITU-T consultation MUST take place following from step
       8 as outlined above.

2.4. Naming Conventions for MPLS-TP Documents

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

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

   o  Individual MPLS-TP 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".

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

   o  MPLS working group documents MUST be named 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 MUST be named
      according to this format:

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

2.5. Boilerplate Text For Inclusion in MPLS-TP Documents

   In order to clarify the status of MPLS-TP documents within the IETF,
   the following boilerplate text is included in Internet-Drafts.


Andersson, et al.        Expires July 24, 2010                 [Page 16]


Internet-Draft          MPLS-TP Document Process            January 2010


2.5.1. Abstract

   In the Abstract of each MPLS-TP Internet-Draft, as the final
   paragraph, the following text is included:

     This document is a product of a joint Internet Engineering Task
     Force (IETF) / International Telecommunication Union
     Telecommunication Standardization Sector (ITU-T) effort to include
     an MPLS Transport Profile within the IETF MPLS and PWE3
     architectures to support the capabilities and functionalities of a
     packet transport network.

2.5.2. Introduction

   Somewhere within the Introduction section of each MPLS-TP Internet-
   Draft, the following text is included:

     This document is a product of a joint Internet Engineering Task
     Force (IETF) / International Telecommunication Union
     Telecommunication Standardization Sector (ITU-T) effort to include
     an MPLS Transport Profile within the IETF MPLS and PWE3
     architectures to support the capabilities and functionalities of a
     packet transport network.

2.5.3. Recognition of IETF Consensus for Informational RFCs

   In order to allow the ITU-T to make normative references to
   Informational RFCs, the documents need to progress through IETF last
   call and have the weight of IETF consensus. This will be recorded in
   the published RFC using text added by the RFC Editor.

   To make sure that the RFC Editor is reminded to do this, the
   following two paragraphs are included before the Introduction section
   of an Informational MPLS-TP Internet-Draft.

     This Informational Internet-Draft is aimed at achieving IETF
     Consensus before publication as an RFC and will be subject to an
     IETF Last Call.

     [RFC Editor, please remove this note before publication as an RFC
     and insert the correct Streams Boilerplate to indicate that the
     published RFC has IETF Consensus.]

3. Expectations on ITU-T Participation in the Process

   The IETF looks for input from the ITU-T at two key points in the
   process described in Section 2.



Andersson, et al.        Expires July 24, 2010                 [Page 17]


Internet-Draft          MPLS-TP Document Process            January 2010


   o  Steps 5 and 6 : Review of Working Group Documents

   o  Steps 9 and 10 : Working Group Last Call and Document Approval

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

3.1. Working Group Document Review

   The ITU-T may provide input to documents that are being developed by
   IETF working groups. They are open for informal and formal comment by
   the ITU-T and its participants.

   As shown by step 5 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 not
   required to respond to these communications.

   The IETF may also request review or discussion of working group
   documents. The ITU-T is required to respond to this type of
   communication if it is a formal liaison (step 6) within the deadline
   set by the liaison (see Section 3.3). In this case, it should either
   send a liaison response with comments and questions, or it should
   acknowledge the 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 unsolicited communications on a
   working group document as either informal or formal communications
   (step 6). Formal communications may request a response from the IETF.

   However, ITU-T participants are encouraged to bring their comments
   and questions to the MPLS-TP mailing list directly, because this will
   be more efficient and conforms to 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.2. Working Group Last Call and Document Approval

   A working group last call is issued when a working group document is
   close to being ready for publication as an RFC. The intention is to
   make sure that there are no important pieces missing, that technical
   details are 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.


Andersson, et al.        Expires July 24, 2010                 [Page 18]


Internet-Draft          MPLS-TP Document Process            January 2010


   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 9) 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, 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 Ad Hoc Team on MPLS-TP
   mailing list.

   The IETF will make a best effort attempt to target the ITU-T Study
   Groups and Questions that should be involved in responding to the
   working group last call. However, the ITU-T must make sure that the
   appropriate entities within the ITU-T participate in 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 supports 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.

   For the avoidance of doubt, the following guidance has been provided


Andersson, et al.        Expires July 24, 2010                 [Page 19]


Internet-Draft          MPLS-TP Document Process            January 2010


   by the ITU-T to its Rapporteurs:

      During the final stages of development (e.g., Working Group last
      call) the IETF will send a liaison to ITU-T for action.

      At this stage the experts of the ITU-T must make a judgement if
      the draft being reviewed is a suitable basis for a normative
      reference from an ITU-T Recommendation. The group must reach a
      consensus on this opinion.

      A liaison to indicate support for the IETF to approve the draft
      should contain the following text:

        The experts of Qx have reviewed draft-xxxx by correspondence and
        either:

        - Have no concerns with the IETF proceeding with approval;

        or

        - Request that the following changes are made before the IETF
          approves the draft.

      Exceptionally, if consensus to support approval of the draft
      cannot be reached, a response liaison must be sent indicating
      that consensus could not be reached by correspondence and that
      the matter will be addressed at the next SG (or interim)
      meeting.

   If the ITU-T is unable to reach consensus, the working group may
   proceed to reach its own consensus on the document on the
   understanding that it may be necessary to revise the document later
   when ITU-T consensus is reached.

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





Andersson, et al.        Expires July 24, 2010                 [Page 20]


Internet-Draft          MPLS-TP Document Process            January 2010


3.3. 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 attention of the management of
   the body that has failed to respond.

   In extreme cases, the JWT is empowered to convene itself 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 an 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 IETF
   liaison to the ITU-T on MPLS, the MPLS-TP responsible working
   group chair, and the MPLS-TP responsible AD. They are responsible
   for sending a consolidated response from the IETF, but may
   delegate the work of writing the response.

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

   o  Acknowledgement of receipt and agreement that 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 in the IETF.

   o  Request that the work be put on hold until specific issues have
      been resolved. In the event that this response is seen as
      blocking of ITU-T work, the JWT may be convened to seek a
      resolution.

   Note that the process described in this section is conformant to the
   Change Process for Multiprotocol Label Switching (MPLS) and


Andersson, et al.        Expires July 24, 2010                 [Page 21]


Internet-Draft          MPLS-TP Document Process            January 2010


   Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929].

5. IANA Considerations

   There are no requests for IANA action in this document.

6. Security Considerations

   This document defines a process adaptation for the cooperation
   between the IETF and the 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 the
   document said, and who sent comments that helped clarify the
   document. Thanks to the participants of ITU-T Study Group 15 who
   provided review and comments on an early version of this text.
   Thanks to Ben Niven-Jenkins for discussions.

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.


Andersson, et al.        Expires July 24, 2010                 [Page 22]


Internet-Draft          MPLS-TP Document Process            January 2010


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

   [RFC5378]  Bradner, S., and Contreras, J., "Rights Contributors
              Provide to the IETF Trust", BCP 78, RFC 5378, November
              2008.

Authors' Addresses

   Loa Andersson
   Ericsson Inc

   Email: loa.andersson@ericsson.com


   David Ward
   Juniper Networks

   Email: dward@juniper.net


   Malcolm Betts

   Email: malcolm.betts@rogers.com


   Adrian Farrel
   Huawei Technologies

   Email: adrian.farrel@huawei.com














Andersson, et al.        Expires July 24, 2010                 [Page 23]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/