draft-ietf-mpls-tp-process-00.txt   draft-ietf-mpls-tp-process-01.txt 
<div class="moz-text-flowed" style="font-family: -moz-fixed"> <div class="moz-text-flowed" style="font-family: -moz-fixed">
Network Working Group L. Andersson Network Working Group L. Andersson
Internet-Draft Ericsson Inc Internet-Draft Ericsson Inc
Intended status: Standards Track D. Ward Intended status: BCP D. Ward
Expires: March 8, 2010 Cisco Systems Expires: March 9, 2010 Cisco Systems
M. Betts M. Betts
Huaweil A. Farrel
September 8, 2009 Huawei
September 9, 2009
Joint IETF and ITU-T Multi-Protocol Label Switching (MPLS) Transport IETF Multi-Protocol Label Switching (MPLS)
Profile process Transport Profile (MPLS-TP) Document Process
draft-ietf-mpls-tp-process-00.txt draft-ietf-mpls-tp-process-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
The decision to develop a Multiprotocol Label Switching (MPLS) The decision to develop a Multiprotocol Label Switching (MPLS)
Transport Profile in cooperation between IETF and ITU-T does not Transport Profile (MPLS-TP) in cooperation between the IETF and the
fully define and document processes for development of the required ITU-T is document in RFC 5317 as the decision of the Joint Working
RFCs. Team on MPLS-TP.
This document complements the processes documented in the JWT
decision with a few separate elements; it:
o provides an adaptation of the IETF working group process,
o identifies the expected participation in the process by the ITU-T,
o clarifies the decision rules regarding MPLS-TP documents. 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 is not intended to specify any ITU-T process; to the This document doe not specify any ITU-T process; ITU-T activities
extent necessary ITU-T activities will be done according to ITU-T will be done according to ITU-T process/rules.
process/rules.
Nor is this document is intended to specify the IETF working group This document does not specify or modify the normal IETF working
process, it is limited to the temporary adaptations of that process group process. It is limited to the specific adaptations of that
that is the result of that IETF and ITU-T accepted the proposal in process to facilitate the cooperation agreement between the IETF and
the JWT report to jointly develop the MPLS Transport Profile. In the ITU-T on MPLS-TP, and to ensure a good and consistent document
general it may be said that these adaptations are introduced to review across the two organizations.
ensure a good and consistent document review across the two
organizations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction .................................................. 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology ............................................... 4
1.1.1. IETF terms and abbreviations . . . . . . . . . . . . . 5 1.1.1. IETF Terms and Abbreviations .......................... 4
1.1.2. ITU-T terms and abbreviations . . . . . . . . . . . . 5 1.1.2. ITU-T Terms and Abbreviations ......................... 6
2. Adaptation of the IETF working group process . . . . . . . . . 7 1.2. Purpose and Intent of Cooperation on MPLS-TP .............. 6
2.1. Adaptation of the IETF working group process . . . . . . . 7 2. Adaptation of the IETF Working Group Process .................. 8
2.2. The IETF MPLS-TP process . . . . . . . . . . . . . . . . . 8 2.1. IETF Consensus and Mailing Lists .......................... 8
2.2.1. Developing a MPLS-TP document . . . . . . . . . . . . 9 2.2. Communications with the ITU-T ............................. 8
3. Expectations on ITU-T participation in the process . . . . . . 14 2.3. Adapted IETF Working Group Process ........................ 9
3.1. Becoming a MEAD team document . . . . . . . . . . . . . . 14 2.3.1. Flow Chart ............................................ 9
3.2. Comments on MEAD team documents by participants in the 2.3.2. The IETF MPLS-TP Process ............................. 11
ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Naming Conventions for MPLS-TP Documents ................. 15
3.3. Poll for working group documents . . . . . . . . . . . . . 14 3. Expectations on ITU-T Participation in the Process ........... 16
3.4. Responding to an IETF Working Group Last Call . . . . . . 15 3.1. MEAD Team Document Review ................................ 17
4. Specific guidelines that apply to work on MPLS-TP in the 3.2. Working Group Document Review ............................ 17
ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Working Group Last Call and Document Approval ............ 18
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 3.4. Non-Response to Liaisons ................................. 19
6. Security considerations . . . . . . . . . . . . . . . . . . . 18 4. Guidelines For MPLS-TP work in the ITU-T ..................... 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations .......................................... 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations ...................................... 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments .............................................. 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8. References ................................................... 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References ..................................... 21
8.2. Informative References ................................... 21
Authors' Addresses .............................................. 22
1. Introduction 1. Introduction
When IETF and ITU-T entered into the agreement to develop MPLS-TP, The IETF and ITU-T have entered into an agreement to develop the
the JWT agreement included the decision that the MPLS-TP documents Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP).
should be developed "according to IETF processes". It was also This agreement is known as the Joint Working Team on MPLS-TP (JWT)
assumed that there would be close cooperation in reviewing these IETF Agreement and is documented in [RFC5317]. The agreement states that
documents. The JWT decision is documented in RFC 5317 [RFC5317]. MPLS-TP will be documented in IETF RFCs, and assumes that there will
be close cooperation with the ITU-T in reviewing these RFCs.
However, the process for this close cooperative review was mostly
left to be decided as the documents evolved. The ITU-T committed to
responding promptly to IETF working group last calls, this may
require the development of the response via correspondence.
Nor is this document is intended to specify the IETF working group This document provides additional detail of the processes for the
process, it is limited to the temporary adaptations of that process development of IETF RFCs on MPLS-TP as follows.
that is 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 to
ensure a good and consistent document review across the two
organizations.
This document complements the process as documented in the JWT o It Provides an adaptation of the IETF working group process, with
decision with a few separate elements; it: respect to the how the IETF will take input from the ITU-T on
MPLS-TP topics.
o Provides an adaptation of the IETF working group process, with o It identifies the expected participation by the ITU-T in the
respect to the role of the teams (MPLS Interoperability Design document development process, noting that the ITU-T has committed
Team (MEAD Team), the Joint Working Team (JWT) and the ITU-T to responding promptly to IETF working group last calls in a way
MPLS-TP ad hoc team) that has been set up to facilitate the that may require the ITU-T to develop responses via
development of MPLS-TP; see Section 2. correspondence.
o Identifies the expected participation by the ITU-T in the document o It clarifies the rules regarding MPLS-TP documents.
development process; see Section 3.
o Clarifies decision rules regarding MPLS-TP documents; see This document does not specify or modify the normal IETF working
Section 4. 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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 1.1. Terminology
This section includes a number of terms and abbreviations that are This section includes a number of terms and abbreviations that are
used in this document. The section is split into two subsection; used in this document. The section is split into two subsection:
IETF terms and ITU-T terms. IETF terms and ITU-T terms.
1.1.1. IETF terms and abbreviations 1.1.1. IETF Terms and Abbreviations
o JWT - Joint Working Team, a team with participants with experience o JWT - Joint Working Team, a team with participants with experience
from standards development in the IETF and the ITU-T. 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 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 that has been set up to facilitate cooperation on MPLS-TP between
the two organizations. the two organizations.
o JWT documents - the set of documents envisioned in the o JWT decision - A set of recommendations on the procedural approach
documentation of the JWT decision, see RFC 5317 [RFC5317]. 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 MEAD team - MPLS Interoperability Design Team, a temporary team o MEAD team - MPLS Interoperability Design Team, a temporary team
with participants with experience from standards development for with participants with experience from standards development for
MPLS and transport networks. The MEAD team is chartered to MPLS and transport networks. The MEAD team is chartered to
coordinate the development of MPLS-TP within the IETF and to coordinate the development of MPLS-TP within the IETF and to
coordinate the on MPLS-TP cooperation with the ITU-T. coordinate the MPLS-TP cooperation with the ITU-T.
o MPLS-TP documents - the following sets of documents are counted as o MPLS-TP documents - The following sets of documents are counted as
MPLS-TP documents: MPLS-TP documents:
* Internet Drafts that are coordinated by the MEAD team. * Internet-Drafts that are coordinated by the MEAD team.
* Individual Internet Drafts that addresses the MPLS-TP problem * Individual Internet-Drafts that addresses the MPLS-TP problem
space. space.
* Working group Internet Drafts that addresses the MPLS-TP * Working group Internet-Drafts that addresses the MPLS-TP
problem space. problem space.
* Internet Drafts that are considered for publication by the IESG * Internet-Drafts that are considered for publication as RFCs by
and that addresses the MPLS-TP problem space. the IESG and that addresses the MPLS-TP problem space.
* Internet Drafts that are approved for publication by the IESG * Internet-Drafts that are approved for publication as RFCs by
and that addresses the MPLS-TP problem space. the IESG and that addresses the MPLS-TP problem space.
* Published RFCs that addresses the MPLS-TP problem space. * Published RFCs that addresses the MPLS-TP problem space.
* ITU-T Recommendations and draft Recommendations in various * ITU-T Recommendations and draft Recommendations in various
stages of development that addresses the MPLS-TP problem space. stages of development that address the MPLS-TP problem space.
Documents that originates from the IRTF RFC stream is NOT considered Documents that originate from the IRTF RFC stream are NOT
as MPLS-TP documents. considered as MPLS-TP documents.
1.1.2. ITU-T terms and abbreviations 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 Ad Hoc on MPLS-TP - A team established by SG 15 of ITU-T to o MPLS-TP responsible working group chair - An IETF MPLS working
coordinate the work on MPLS-TP within the ITU-T and to act as a group chair assigned responsibility for the IETF MPLS-TP effort
focal point for communication with the IETF. by the IETF Routing Area Directors.
o Contribution - a contribution is a document that is submitted to 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 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 - A contribution is a document that is submitted to
the ITU-T to advance work on the development of a Recommendation the ITU-T to advance work on the development of a Recommendation
or to propose the development of a new Recommendation. or to propose the development of a new Recommendation.
o Recommendation - a Recommendation is the ITU-T standards document. o Recommendation - A Recommendation is an ITU-T standards document.
2. Adaptation of the IETF working group process 1.2. Purpose and Intent of 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.
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 The IETF working group processes as defined in RFC 2026 [RFC2026] are
for the purpose of the MPLS-TP updated as follows. 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 The IETF works according to a 'rough consensus' model, where working
group chairs determine the consensus after discussions on the mailing group chairs determine the consensus after discussions on the mailing
lists. This is applicable to the MPLS-TP work also. The lists. This is also applicable to the MPLS-TP work. The MPLS-TP
mpls-tp@ietf.org is the mailing list used to find out consensus and mailing list exists to focus all IETF discussions on MPLS-TP and to
consensus is determined by the MEAD team chair. After a document has avoid congesting other relevant working group mailing lists. All
become a working group document the consensus is decided by the WG technical discussion on MPLS-TP SHOULD be directed to the MPLS-TP
chairs and the MEAD team chair jointly. 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 MAY direct discussions to the MPLS-TP list and
MAY direct that consensus will be judged on that list.
2.2. Communications with the ITU-T
A most important part of this process is the information exchange A most important part of this process is the information exchange
between the IETF and ITU-T. This information exchange consists of between the IETF and ITU-T. This information exchange consists of
two equally important pieces: two equally important pieces.
o informal information exchange o Informal information exchange
this is done primarily by E-Mail to the relevant mailing lists. This is done primarily by e-mail to the relevant mailing lists.
Information sent from IETF, IETF areas and working groups, or from Information sent to the ITU-T MUST be sent to the Ad Hoc MPLS-TP
the IETF MEAD team are sent to and areas and the mailing list. Information sent to the IETF MUST be sent to the
ahmpls-tp@lists.itu.int mailing list. Information sent from ITU-T MPLS-TP mailing list.
to the IETF should e sent to the MEAD team (mead@ietf.org) and/or
the mpls-tp@ietf.org mailing list.
o formal information exchange o Formal information exchange
In addition to E-Mail, a formal information exchange is In addition to the informal information exchange, a formal
accomplished by liaison correspondence between the two information exchange is accomplished by liaison correspondence
organisations. Exchange of liaisons makes it possible to follow between the two organisations. Exchange of liaisons makes it
the request/response exchange between the organisations in more possible to follow the request/response exchange between the
detail. organisations in more detail, and to obtain an official view of
each organisation's position on any topic.
2.1. Adaptation of the IETF working group process 2.3. Adapted IETF Working Group Process
2.3.1. Flow Chart
The flow chart below describes the adaption of the working group The flow chart below describes the adaption of the working group
process process. The flow chart and the process as described in Section 2.3.2
are equally normative.
............. ............. ............. .............
: Ind Docs :------+ : JWT docs : : Ind Docs :--------+ : JWT docs :
............. | ............. ............. | .............
| | | | | |
| ind-00 (1) | ind-00 (2) | ind-00 (3) |(1) |(2) |(3)
| | | | | |
v | v v | v
+-----------+ | +----------------+ (4) +-------+ +-----------+ | +----------------+ (4) +-------+
| WG proc | +------->| MEAD team proc |<----->| ITU-T | +--->| WG proc | +----->| MEAD team proc |------>| ITU-T |
| |-------+ +--| | +-------+ | | |-------+ +--| | +-------+
+-----------+ | | +----------------+ (5) | | +-----------+ | | +----------------+ |
+-> ind-00, ind-01, etc | | ind-00, ind-01, etc <-+<-----+ | ind-00, ind-01, etc | | ^ ind-00, ind-01, etc |(5)
| | (6) +--+---+ (6) | | | |(6) +--+---+ | |(6) |
+----------+ |(7) +-------------+ +----------+ |(7) +-------+<-----------------+
review +----+ review review | review
v
+-----------------+
| poll for wg doc |
+-----------------+
|(8)
| |
poll for wg doc -----------------+ v
| | (7a) +-------------+ (9) +-------+
v v +----------->| wg doc |------------->| ITU-T |
+-------------+ (8) +-------+
+----------> | wg doc |<------------>| ITU-T |
| +-------------+ +-------+ | +-------------+ +-------+
| | +-> wg-00, wg-01, etc | | | ^ wg-00, wg-01, etc |
| | | | (9) | (10) | | | |(11) |(10)
| | +----------+<----------------+ (15)| (12)| +------+<------------------+
| (11) | review | | review
| v | v
| +-----------------+ (12) +---------+ | +-----------------+
(14b) | | wg last call |<----------->| ITU-T | +-----| wg last call |
| +-----------------+ +---------+ +-----------------+
| | ^ | | ^ |
| (13)| |(14a) | (15) (13)| |(14) |(16)
| v | | v | |
| +---------+ | +---------+ |
+-------| ITU-T | | | ITU-T | |
+---------+ | +---------+ |
|
v v
+-----------------+ +---------------+
| req for publ | | req for pub |
+-----------------+ +---------------+
2.2. The IETF MPLS-TP process 2.3.2. The IETF MPLS-TP Process
This section gives guidelines for how the flow chart above could be This section describes the development for MPLS-TP documents. It sets
traversed. 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.
2.2.1. Developing a MPLS-TP document 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 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.
Individual MPLS-TP documents may take different paths through the 1. Independent Documents through Working Group Processing
this process, the numbers in the list below are mapped to the numbers
in the flow chart above.
Although the different paths through the flow chart are given as Internet-Drafts MAY be introduced by their authors to describe
'options' it is always possible for the MEAD team to step in and take any aspect of MPLS-TP. This option (compare with step 2) results
over the shepherding of a particular MPLS-TP Internet Draft . This in the document being discussed and reviewed by the appropriate
is done in cooperation between the MEAD team chair, the relevant IETF working group as determined by the working group chairs. The
working group chairs and the document editors/authors. normal IETF process will be applied, and the authors will revise
the document (step 6) until it is adopted as a working group
draft (see step 7).
1. They may be intended for and managed by a working group. Any individual or group of individuals can create an Internet-
Draft through this step.
This means that the author, or authors, of such a document have 2. Independent Documents through MEAD Team Coordination
chosen to send the document to a working group instead of
running through the MEAD team. Normal IETF process will kick in
in such cases and working group chairs will agree to which
working group(s) such a document will be taken.
2. They may be coordinated by the MEAD team. Internet-Drafts MAY be brought to the MEAD team or initiated by
the MEAD team. The MEAD team is responsible for discussing,
reviewing, and revising (step 6) the documents as independent
drafts. The MEAD team will solicit input from the ITU-T (step 4)
and will publicise the documents on the MPLS-TP mailing list to
encourage input from the IETF community. Normal IETF design team
process will apply until the document is adopted as a working
group draft (see step 7).
This means that the author, or authors, of such a document have Any individual or group of individuals can create an Internet-
chosen to send the document to the MEAD team to be coordinated Draft through this step. However, the MEAD team MAY decide that
with the rest of the MPLS-TP documents that is in the purview of it is unwilling to support the document. In this case, the
the MEAD team. authors MAY bring the document in following step 1.
3. They may be originated by the MEAD team based on the JWT 3. Joint Working Team Originated Documents
decision.
In documentation of the work of the JWT, there is a proposed The JWT MAY initiate MPLS-TP documents, or request that the MEAD
document structure. The MEAD team used this structure to decide team create specific documents. The MEAD team MUST process these
on a set of documents that will, when completed, constitute the as independent submissions as described in step 2.
MPLS-TP standard. This set of documents may change slightly, if
- e.g. - it becomes more appropriate to split a single document [RFC5317] includes a list of JWT documents that MUST be
into two or more, or if some new aspect of MPLS-TP needs to be considered by the MEAD team to be processed on this step, but the
specified. MEAD team MAY vary this 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 a document is accepted by the MEAD team into the set 4. Everytime a document is accepted by the MEAD team into the set
of documents coordinated by the MEAD team a liaison is sent to of documents coordinated by the MEAD team a liaison MUST be sent
the ITU-T with a pointer to that document. At the same time a to the ITU-T with a pointer to that document. At the same time a
note is sent to the MPLS-TP ad hoc team mailing list informing note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list
the list that the document has become a MEAD team document. informing the list that the document has become a MEAD team
document.
The ITU-T may chose to respond to the liaison but is not Each time a document coordinated by the MEAD team is revised a
required to do so, see Section 3 and Section 4. 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.
5. At any time, it is possible for the ITU-T SG and Question The ITU-T MAY respond to these liaisons (step 5), but a response
participants to send review comments on MEAD team documents. It is not required (see Section 3 and Section 4).
is also possible for the MEAD team to ask for such reviews and
comments.
Any time such input or requests are sent between the two 5. At any time, it is possible for ITU-T participants to send review
organizations it SHALL be accompanied by a note from the MPLS-TP comments on any MPLS-TP document. Such comments SHOULD be sent as
ad hoc team chair(s) to the MEAD team mailing list, or from the comments to the MPLS-TP mailing list according to normal IETF
MEAD team chair to the MPLS-TP ad hoc team mailing list. This process.
is done to enhance the efficiency of the information exchange.
6. A working group or the MEAD team may issue requests for general Additionally, this step provides for communication from ITU-T
comments on MPLS-TP documents at any time, if it is deemed Study Groups or Questions. These communications may be
appropriate to extend these requests to the MPLS-TP ad hoc team unsolicited or in response to a request from the IETF (step 4),
this is done via a note according to entry (5) in this list. 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 chair.
7. If a MPLS-TP document seems mature enough to become a working The MEAD team SHOULD give due consideration to the issues raised
group document, a poll is done on the mpls-tp mailing list and in the communications received ITU-T, and SHOULD attempt to make
the appropriate working group mailing list (7), this request suitable changes to the MPLS-TP document or MUST otherwise
will also be sent to the ITU-T as a liaison (7a) and a note will explain why no change is being made.
also be sent to the MPLS-TP ad hoc team.
Which working group a document goes into is decided jointly Formal information exchanges MUST receive a response if
between the MEAD team, working group chairs of the potential requested. The IETF liaison to the ITU-T on MPLS and the
working groups and the document editors/authors. addressees of the liaison are responsible for ensuring that this
step is completed.
If the document is accepted as a working group document the 6. Authors of independent documents SHOULD solicit comments on the
MPLS-TP mailing list and on any appropriate IETF working group
mailing lists. Comments can also be received from the ITU-T as
described for step 5.
The authors SHOULD revise the documents according to comments
received from all sources, or explain why no changes been made.
7. 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.
8. If the document is accepted as a working group document the
working group takes over the revision control of the document. 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
mailing list with notifications sent to the relevant IETF working
group mailing list.
The ITU-T is expected to respond to the liaison within in the 9. When a document is accepted as a working group document
time indicated in the liaison, see Section 3 and Section 4. 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.
8. Every time a MPLS-TP document is accepted as a working group Each time an MPLS-TP document under working group control is
document by any IETF working group, a liaison is sent to the revised a note SHOULD be sent to the Ad Hoc Team on MPLS-TP
ITU-T with a pointer to the document. At the same time, a note mailing list, and a liaison MAY be sent to the ITU-T to inform
is sent to the MPLS-TP ad hoc team mailing list informing the them of the progress of the document. No response to these
list that the document has become a working group document. liaisons is expected.
9. Working group documents may be reviewed in several steps, every The IETF working group MAY solicit input from the ITU-T at any
time such a review is initiated the MPLS-TP ad hoc team is time.
notified (10).
Note that most comments leading to updates of working group 10. At any time, it is possible for ITU-T participants to send review
documents are a result of spontaneous individual reviews and comments on any MPLS-TP document. Such comments SHOULD be sent as
comments from the individual participants in the MPLS-TP effort. comments to the MPLS-TP mailing list according to normal IETF
process.
10. Every time a review is initiated by a working group the Additionally, this step provides for communication from ITU-T
appropriate ITU-T SGs and Questions will be notified by E-Mail Study Groups or Questions (see Section 3.2). These communications
to the MPLS-TP ad hoc team. may be unsolicited or in response to a 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.
Optionally the request for review may be accompanied by a The document editors and the working group SHOULD give due
liaison to formalize the request. 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.
The MPLS-TP ad hoc team is responsible for ensuring that any Formal information exchanges MUST receive a response if
e-mail requests are copied/forwarded to the relevant SGs and requested. The IETF liaison to the ITU-T on MPLS is responsible
Questions. for ensuring that this step is completed.
11. When a document is deemed mature enough, a working group last 11. Editors working group documents SHOULD solicit comments on the
call is initiated. At this time the action describe under item MPLS-TP mailing list and on any appropriate IETF working group
12 in this list MUST be executed. mailing lists. Comments can also be received from the ITU-T as
described for step 9.
12. Procedures to be followed when a working group last call is The authors SHOULD revise the documents according to comments
initiated. received from all sources.
* A liaison containing a request for participation in the Note that most comments that lead to updates of working group
working group last call will be sent to the appropriate ITU-T documents are a result of spontaneous individual reviews and
SGs and Questions. comments from the individual participants in the MPLS-TP effort
according to normal IETF process.
* A notification that the working group last call is taking 12. When an MPLS-TP document is deemed mature enough, a working group
place will be provided to the MPLS-TP ad hoc team via E-Mail last call is initiated following normal IETF process.
sent to the MPLS-TP mailing list.
* ITU-T is REQUIRED to respond to the liaison within the time 13. When a working group last call is initiated for any MPLS-TP
indicated. The MPLS-TP ad hoc team is expected to verify document the following actions MUST be taken.
that all the SGs and Questions within the ITU-T that need to
* A liaison 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 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 respond to the working group last call are aware that it has
been issued. been issued.
13. When all last call comments are addressed and/or responded to, * A notification that the working group last call is taking place
the document will be sent to the ITU-T, asking if the document MUST be sent to the ahtmplstp mailing list and to the MPLS-TP
is ready to be sent to the IESG with a request for publication. mailing list.
The response sought from ITU-T is either an acknowledgment that
the document is ready to publish or a response that there is
further work that needs to be done.
Note: WG last call may be re-iterated, for the entire document 14. The ITU-T is REQUIRED to respond to the liaison in step 13 within
or limited to only verify the updates made because of an earlier the time indicated in the liaison (see Section 3.3). This
deadline will usually be set according to the timeline of the
working group last call. working group last call.
14. The ITU-T has one week to respond (yes or no) to the question The ITU-T response MUST either include comments to be taken under
posed in (13). 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 approval for the
publication of the document as an RFC.
The answer can be either "yes - go ahead" (14a), in which case The working group and document editors MUST fully address any
the Working Group will request publication; or ... 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 MPLS-TP mailing list.
... it can be "no - more work is needed" (14b), in which case it 15. According to normal IETF process, if the last call comments are
will go back into the normal working group process to identify substantial the document MUST be returned to the working group
what is needed. for revision and discussion. This MAY necessitate further
communication with the ITU-T (step 9) to clarify or resolve
issues raised during ITU-T review.
15. When the ITU-T gives the final acknowledgement (14a), a request The working group last call MAY be repeated multiple times for
for publication will be sent to the IESG (15). 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 be limited to only the updated text in
the document. 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.
The document that is sent to the ITU-T in step (13) and which Note that, according to normal IETF process, if the last call
generates a positivie response from ITU-T (14a) is sent comments are minor, they SHOULD be addressed by the document
unchanged, save for editorial changes, to the IESG with a editors in coordination with the working group chairs and with
request for publication (15) as a RFC. notification to the MPLS-TP mailing list.
Once this request for publication is sent, the last point in 16. When all last call comments have been addressed or responded to
this process where it is acceptable to allow ITU-T influence in and all necessary working group last calls have been held, the
the development of a document is passed. After this point, the working group chairs of the owning working group with assistance
document will be handled as any other IETF document. of the MPLS-TP responsible working group chair will request
publication of the document as an RFC following normal IETF
process.
2.2.1.1. Naming conventions for MPLS-TP Internet Drafts Once this request for publication is sent there is no further
scope for the ITU-T to influence the development of the document.
After this point, the document will be handled as any other IETF
document with individual comments made during IETF last call, and
with IESG review following.
To make it easier to search in the IETF Internet Draft repositories Note that if these later stages in the publication process cause
the the following guidelines should be followed for the MPLS-TP significant changes to the document, it MAY be fully or partially
Internet Draft filenames. 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.
o All MPLS-TP Internet Draft should include the sequence "mpls-tp" 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. in the filename.
o Individual MPLS-TP Internet Draft should be named according to o Individual MPLS-TP Internet-Draft MUST be named according to
this format: this format:
draft-name-mpls-tp-topic-??.txt draft-name-mpls-tp-topic-??.txt
"name" is the last name of the main editor, or an acronym "name" is the last name of the main editor, or an acronym
indicating the last names of the set of editors. indicating the last names of the set of editors.
"topic" indicates the content of the draft, e.g. "oam-framework". "topic" indicates the content of the draft, e.g. "oam-framework".
"??" indictes a two digit version number, starting with "00". "??" indicates a two digit version number, starting with "00".
o MPLS working group documents should be named according to this o MPLS working group documents MUST be named as follows:
format:
draft-ietf-mpls-tp-topic-??.txt draft-ietf-mpls-tp-topic-??.txt
o MPLS-TP documents from other working groups shouldbe named "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: according to this format:
draft-ietf-wg-name-mpls-tp-topic-??.txt draft-ietf-wgname-mpls-tp-topic-??.txt
"wg-name" is the acronym for any working group chartered to do "wgname" is the acronym for any working group chartered to do
MPLS-TP work, e.g. pwe3 or ccamp. MPLS-TP work, e.g. pwe3 or ccamp.
3. Expectations on ITU-T participation in the process "topic" indicates the content of the draft, e.g. "oam-framework".
The IETF and ITU-T processes for the development of the MPLS-TP "??" indicates a two digit version number, starting with "00".
standards interconnect at the following point in the flow chart
above: (4), (5), (7a), (8), (10) and (12). This section briefly
describes what is expected to happen on the ITU-T side at the
interaction points.
3.1. Becoming a MEAD team document 3. Expectations on ITU-T Participation in the Process
(4) is a point at which the MEAD team communicates to the ITU-T that The IETF looks for input from the ITU-T at three key points in the
a document is considered to be accepted for coordination by the MEAD process described in Section 2.
team.
The ITU-T is expected to respond to the communication with a simple o Steps 4 and 5 : Review of MEAD Team Documents
ACK or NAK, however a non-response is counted as an ACK. o Steps 9 and 10 : Review of Working Group Documents
An ACK means that ITU-T accepts that the document has become a MEAD o Steps 13 and 14 : Working Group Last Call and Document Approval
team document, a NAK means that ITU-T has issues that needs to be
resolved before the document is allowed to progress.
3.2. Comments on MEAD team documents by participants in the ITU-T This section briefly describes what the IETF expects to happen on the
ITU-T side at these interaction points.
(5) and (10) offer possibilities for ITU-T, or people active in the 3.1. MEAD Team Document Review
ITU-T, to send un-triggered comments on MEAD team or working group
documents. Such comments shall be sent to the mpls-tp list and for
working group documents also to the appropriate working group mailing
list. 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 The ITU-T may provide input to 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.
(7a) is the point at which an IETF working group informs the ITU-T As shown by step 4 in the process described in Section 2, the IETF
that a poll to progress a document to an IETF working group document will notify the ITU-T of the existence of such documents and will
has been started. normally inform the ITU-T of new revisions. The ITU-T is not
required to respond to these communications.
It is not necessary, or required, for the ITU-T to respond to this The IETF may also request review or discussion of MEAD team
message. If the ITU-T has serious concerns these should be provided documents. The ITU-T is required to respond to this type of
via a liaison statement. If the ITU-T has no serious concerns it is communication if it is a formal liaison (step 5) within the deadline
allowed and encouraged that individual participants provide comments. set by the liaison (see Section 3.4). In this case, it should either
Such responses shall be sent to the appropriate working group and send a liaison response with comments and questions, or it should
mpls-tp mailing lists and represent the view of the person sending acknowledge the liaison from the IETF saying that there are no
the mail. 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.
An Internet Draft is ready to become a working group draft if it Additionally, the ITU-T may send unsolicited communications on a MEAD
meets at least the three criteria below. team document as either informal or formal communications (step 5).
Formal communications may request a response from the IETF.
o it is within the charter of the working group 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 given full consideration by the MEAD
team and the document authors.
o it addresses a problem that needs to be solved 3.2. Working Group Document Review
o it is a good enough start toward solving this problem 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.
Responses to polls checking if a document is ready to become a As shown by step 9 in the process described in Section 2, the IETF
working group document should be limited to considering if the will notify the ITU-T of the existence of such documents and will
document meets those three criteria. normally inform the ITU-T of new revisions. The ITU-T is not
required to respond to these communications.
3.4. Responding to an IETF Working Group Last Call 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 10) within the deadline
set by the liaison (see Section 3.4). 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.
(12) is the point in the process where ITU-T is made aware of that an Additionally, the ITU-T may send unsolicited communications on a
IETF working group last call has been started. The working group working group document as either informal or formal communications
last call is issued when a working group document is getting close to (step 5). Formal communications may request a response from the IETF.
being ready for publication. The intention is to make sure that
there are no important pieces missing and that technical details are
correct.
According to the JWT decision ITU-T is required to respond to a However, ITU-T participants are encouraged to bring their comments
working group last call within the time set in announcing the working and questions to the MPLS-TP mailing list directly, because this will
group last call. 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.3. 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.
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, 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 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 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. 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 and
Questions that should be involved in responding to the working group
last call. However, the ITU-T has to make sure that the appropriate
entities within the ITU-T participate in responding to the working
group last call. The ITU-T MPLS-TP ad hoc team coordinates the
development of the ITU-T response to the working group last call.
4. Specific guidelines that apply to work on MPLS-TP in the ITU-T 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 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 attention of the management of
the body that has failed to respond.
In extreme cases, the JWT is empowered to 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. 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 Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T
Study Group or Question. Study Group or Question.
Before the ITU-T initiates any new work (i.e. items not previously 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 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, send a liaison to the IETF. The message will go to the IETF
and the team is responsible for creating a consolidated IETF liaison to the ITU-T on MPLS, the MPLS-TP responsible working
response. 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 is expected to respond to the information that a new The IETF must respond to such liaisons according to the deadline
MPLS-TP work item has been proposed with an ACK or NAK. in the liaison. Acceptable responses include:
If the response is a NAK that work item is held until the issues o Acknowledgement of receipt and agreement that the ITU-T is
is resolved. clear to proceed with the work described.
5. IANA considerations 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
Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929].
5. IANA Considerations
There are no requests for IANA allocation of code points in this There are no requests for IANA allocation of code points in this
document. document.
6. Security considerations 6. Security Considerations
This document defines a process adaptation for the cooperation This document defines a process adaptation for the cooperation
between IETF and ITU-T and thus does not introduce any new security between IETF and ITU-T and thus does not introduce any new security
considerations. 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 7. Acknowledgments
Thanks to Eric Gray who helped with grammar and useful comments. 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 Thanks to Tom Petch who spent time trying to sort out what the
to say and has sent comments that helped clarify the document. document said, and who sent comments that helped clarify the
document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 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) [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
Report on MPLS Architectural Considerations for a Report on MPLS Architectural Considerations for a
Transport Profile", RFC 5317, February 2009. Transport Profile", RFC 5317, February 2009.
Authors' Addresses Authors' Addresses
Loa Andersson Loa Andersson
Ericsson Inc Ericsson Inc
Email: loa.andersson@ericsson.com Email: loa.andersson@ericsson.com
David Ward David Ward
Cisco Systems Cisco Systems
Email: dward@cisco.com Email: dward@cisco.com
Malcolm Betts Malcolm Betts
Huaweil Huawei
Email: malcolm.betts@huawei.com Email: malcolm.betts@huawei.com
Adrian Farrel
Huawei
Email: adrian.farrel@huawei.com
</div> </div>
 End of changes. 131 change blocks. 
358 lines changed or deleted 683 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/