draft-ietf-mpls-tp-process-02.txt   draft-ietf-mpls-tp-process-03.txt 
Network Working Group L. Andersson Network Working Group L. Andersson
Internet-Draft Ericsson Inc Internet-Draft Ericsson Inc
Intended status: BCP D. Ward Intended status: BCP D. Ward
Expires: March 19, 2010 Cisco Systems Expires: April 16, 2010 Cisco Systems
M. Betts M. Betts
A. Farrel A. Farrel
Huawei Huawei
September 19, 2009 October 16, 2009
IETF Multi-Protocol Label Switching (MPLS) IETF Multi-Protocol Label Switching (MPLS)
Transport Profile (MPLS-TP) Document Process Transport Profile (MPLS-TP) Document Process
draft-ietf-mpls-tp-process-02.txt draft-ietf-mpls-tp-process-03.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 2, line 18 skipping to change at page 2, line 18
Transport Profile (MPLS-TP) in cooperation between the IETF and the 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 ITU-T is document in RFC 5317 as the decision of the Joint Working
Team on MPLS-TP. Team on MPLS-TP.
This document provides additional detail of the processes for the This document provides additional detail of the processes for the
development of IETF RFCs on MPLS-TP. It provides an adaptation of the development of IETF RFCs on MPLS-TP. It provides an adaptation of the
IETF working group process; identifies the expected participation in IETF working group process; identifies the expected participation in
the process by the ITU-T; and clarifies the rules and conventions the process by the ITU-T; and clarifies the rules and conventions
regarding MPLS-TP documents. regarding MPLS-TP documents.
This document doe not specify any ITU-T process; ITU-T activities This document does not specify any ITU-T process; ITU-T activities
will be done according to ITU-T process/rules. will be done according to ITU-T process/rules.
This document does not specify or modify the normal IETF working This document does not specify or modify the normal IETF working
group process. It is limited to the specific adaptations of that group process. It is limited to the specific adaptations of that
process to facilitate the cooperation agreement between the IETF and process to facilitate the cooperation agreement between the IETF and
the ITU-T on MPLS-TP, and to ensure a good and consistent document the ITU-T on MPLS-TP, and to ensure a good and consistent document
review across the two organizations. 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 .......................... 4 1.1.1. IETF Terms and Abbreviations .......................... 4
1.1.2. ITU-T Terms and Abbreviations ......................... 6 1.1.2. ITU-T Terms and Abbreviations ......................... 6
1.2. Purpose and Intent of Cooperation on MPLS-TP .............. 6 1.2. Purpose and Intent of 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. Adaptation of the IETF Working Group Process .................. 8
2.1. IETF Consensus and Mailing Lists .......................... 8 2.1. IETF Consensus and Mailing Lists .......................... 8
2.2. Communications with the ITU-T ............................. 9 2.2. Communications with the ITU-T ............................. 9
2.3. Adapted IETF Working Group Process ........................ 9 2.3. Adapted IETF Working Group Process ........................ 9
2.3.1. Flow Chart ............................................ 9 2.3.1. Flow Chart ............................................ 9
2.3.2. The IETF MPLS-TP Process ............................. 11 2.3.2. The IETF MPLS-TP Process ............................. 11
2.4. Naming Conventions for MPLS-TP Documents ................. 16 2.4. Naming Conventions for MPLS-TP Documents ................. 15
3. Expectations on ITU-T Participation in the Process ........... 16 3. Expectations on ITU-T Participation in the Process ........... 15
3.1. MEAD Team Document Review ................................ 17 3.1. Working Group Document Review ............................ 16
3.2. Working Group Document Review ............................ 17 3.2. Working Group Last Call and Document Approval ............ 16
3.3. Working Group Last Call and Document Approval ............ 18 3.3. Non-Response to Liaisons ................................. 19
3.4. Non-Response to Liaisons ................................. 19 4. Guidelines For MPLS-TP work in the ITU-T ..................... 19
4. Guidelines For MPLS-TP work in the ITU-T ..................... 20 5. IANA Considerations .......................................... 20
5. IANA Considerations .......................................... 21 6. Security Considerations ...................................... 20
6. Security Considerations ...................................... 21 7. Acknowledgments .............................................. 20
7. Acknowledgments .............................................. 21 8. References ................................................... 20
8. References ................................................... 21 8.1. Normative References ..................................... 20
8.1. Normative References ..................................... 21 8.2. Informative References ................................... 20
8.2. Informative References ................................... 21 Authors' Addresses .............................................. 21
Authors' Addresses .............................................. 22
1. Introduction 1. Introduction
The IETF and ITU-T have entered into an agreement to develop the The IETF and ITU-T have entered into an agreement to develop the
Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP). Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP).
This agreement is known as the Joint Working Team on MPLS-TP (JWT) This agreement is known as the Joint Working Team on MPLS-TP (JWT)
Agreement and is documented in [RFC5317]. The agreement states that Agreement and is documented in [RFC5317]. The agreement states that
MPLS-TP will be documented in IETF RFCs, and assumes that there will MPLS-TP will be documented in IETF RFCs, and assumes that there will
be close cooperation with the ITU-T in reviewing these RFCs. 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 This document provides additional detail of the processes for the
development of IETF RFCs on MPLS-TP as follows. development of IETF RFCs on MPLS-TP as follows.
o It Provides an adaptation of the IETF working group process, with o It Provides an adaptation of the IETF working group process, with
respect to the how the IETF will take input from the ITU-T on respect to how the IETF will take input from the ITU-T on MPLS-TP
MPLS-TP topics. topics.
o It identifies the expected participation by the ITU-T in the o It identifies the expected participation by the ITU-T in the
document development process, noting that the ITU-T has committed document development process, noting that the ITU-T has committed
to responding promptly to IETF working group last calls in a way to responding promptly to IETF working group last calls in a way
that may require the ITU-T to develop responses via that may require the ITU-T to develop responses via
correspondence. correspondence.
o It clarifies the rules regarding MPLS-TP documents. o It clarifies the rules regarding MPLS-TP documents.
This document does not specify or modify the normal IETF working This document does not specify or modify the normal IETF working
skipping to change at page 5, line 17 skipping to change at page 5, line 19
o JWT decision - A set of recommendations on the procedural approach o JWT decision - A set of recommendations on the procedural approach
to the development of MPLS-TP made by the JWT and documented in to the development of MPLS-TP made by the JWT and documented in
[RFC5317]. [RFC5317].
o JWT agreement - The agreement between IETF and ITU-T based on the o JWT agreement - The agreement between IETF and ITU-T based on the
JWT decision to jointly develop MPLS-TP according IETF processes. JWT decision to jointly develop MPLS-TP according IETF processes.
o JWT documents - The set of documents envisioned in the JWT o JWT documents - The set of documents envisioned in the JWT
decision [RFC5317]. decision [RFC5317].
o MEAD team - MPLS Interoperability Design Team, a temporary team
with participants with experience from standards development for
MPLS and transport networks. The MEAD team is chartered to
coordinate the development of MPLS-TP within the IETF and to
coordinate the 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. * Individual Internet-Drafts that address 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 address the MPLS-TP problem
problem space. space.
* Internet-Drafts that are considered for publication as RFCs by * Internet-Drafts that are considered for publication as RFCs by
the IESG and that addresses the MPLS-TP problem space. the IESG and that address the MPLS-TP problem space.
* Internet-Drafts that are approved for publication as RFCs by * Internet-Drafts that are approved for publication as RFCs by
the IESG and that addresses the MPLS-TP problem space. the IESG and that address the MPLS-TP problem space.
* Published RFCs that addresses the MPLS-TP problem space. * Published RFCs that address 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 address the MPLS-TP problem space. stages of development that address the MPLS-TP problem space.
Documents that originate from the IRTF RFC stream are NOT Documents that originate from the IRTF RFC stream or the
considered as MPLS-TP documents. Independent Submission Stream are not considered as MPLS-TP
documents.
o MPLS-TP mailing list - An IETF mailing list (mpls-tp@ietf.org) o MPLS-TP mailing list - An IETF mailing list (mpls-tp@ietf.org)
established specifically for the discussion of MPLS-TP issues established specifically for the discussion of MPLS-TP issues
within the IETF. The MPLS-TP list is the mailing list that is used within the IETF. The MPLS-TP list is the mailing list that is
decide consensus on MPLS-TP issues. This is an open mailing list usually used to decide consensus on MPLS-TP issues (although other
with publicly available archives. 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 o MPLS-TP responsible working group chair - An IETF MPLS working
group chair assigned responsibility for the IETF MPLS-TP effort group chair assigned responsibility for the IETF MPLS-TP effort
by the IETF Routing Area Directors. by the IETF Routing Area Directors.
o MPLS-TP responsible AD - An IETF Routing Area Director with o MPLS-TP responsible AD - An IETF Routing Area Director with
management responsibility for the MPLS-TP effort. management responsibility for the MPLS-TP effort.
o IETF liaison to the ITU-T on MPLS - An individual assigned o IETF liaison to the ITU-T on MPLS - An individual assigned
responsibility by the IAB for managing the liaison relationship responsibility by the IAB for managing the liaison relationship
skipping to change at page 7, line 31 skipping to change at page 7, line 27
o Informal communication. o Informal communication.
It is recognised that discussions about MPLS-TP will take place It is recognised that discussions about MPLS-TP will take place
within the Questions and Study Groups of the ITU-T. In order to within the Questions and Study Groups of the ITU-T. In order to
speed up the development process and ensure smooth communications, speed up the development process and ensure smooth communications,
the ITU-T is requested to make informal (i.e., email) the ITU-T is requested to make informal (i.e., email)
communications to the IETF whenever any issues or questions communications to the IETF whenever any issues or questions
arise. Informal communication can be sent by any individual or arise. Informal communication can be sent by any individual or
rapporteur of a Question as an email to the MPLS-TP mailing list. rapporteur of a Question as an email to the MPLS-TP mailing list.
The chairs of the ahtmplstp may also summarise discussions within The chairs of the Ad Hoc Team on MPLS-TP may also summarise
the ITU-T (especially those on the ahtmplstp mailing list) and discussions within the ITU-T (especially those on the Ad Hoc Team
communicate them to the IETF via email. on MPLS-TP mailing list) and communicate them to the IETF via
email.
o Formal communication. o Formal communication.
The formal liaison process with the IETF is described in [RFC4052] The formal liaison process with the IETF is described in [RFC4052]
and [RFC4053]. The process will be used for ensuring that specific and [RFC4053]. The process will be used for ensuring that specific
progress steps are check-pointed and recorded, and for making sure progress steps are check-pointed and recorded, and for making sure
that appropriate responses are generated in a timely manner. that appropriate responses are generated in a timely manner.
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 The objective of cooperation between the IETF and ITU-T is to ensure
full participation of interested parties to make sure that all full participation of interested parties to make sure that all
opinions are heard with the intention of producing sound and stable opinions are heard with the intention of producing sound and stable
MPLS-TP documentation. It is understood that the neither the IETF nor 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 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 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 means that the ITU-T cannot block IETF work on MPLS-TP against the
IETF consensus view. IETF consensus view.
Part of this process must be the understanding that all IETF Part of this process must be the understanding that all IETF
documentation (including RFCs) can be revised or extended according documentation (including RFCs) can be revised or extended according
to normal IETF procedures. Therefore, it is not a requirement that 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 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 to "boil the ocean"); the initial aim of the work is to provide
documentation of MPLS-TP as it is initially developed and deployed. documentation of MPLS-TP as it is initially developed and deployed.
Fundamental to understanding the process described in the rest of Fundamental to understanding the process described in the rest of
skipping to change at page 8, line 26 skipping to change at page 8, line 28
TP responsible AD, and the IETF liaison to the ITU-T on 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 The ITU-T may also develop Recommendations to document MPLS-TP. The
JWT decision recognises that these Recommendations must not contain JWT decision recognises that these Recommendations must not contain
normative definitions of MPLS-TP (these are captured solely in IETF normative definitions of MPLS-TP (these are captured solely in IETF
RFCs). Recommendations on MPLS-TP will be provided for review by the RFCs). Recommendations on MPLS-TP will be provided for review by the
IETF to ensure conformance with the previous point and to verify that IETF to ensure conformance with the previous point and to verify that
the material is consistent across MPLS-TP. The process for producing the material is consistent across MPLS-TP. The process for producing
and reviewing Recommendations is out of scope for this document. 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
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 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
adapted as described in this section solely for the purpose of the 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 MPLS-TP work. These adaptations do not apply to any other topic or
work within the IETF. work within the IETF.
2.1. IETF Consensus and Mailing Lists 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
skipping to change at page 8, line 47 skipping to change at page 9, line 14
lists. This is also applicable to the MPLS-TP work. The MPLS-TP 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 mailing list exists to focus all IETF discussions on MPLS-TP and to
avoid congesting other relevant working group mailing lists. All avoid congesting other relevant working group mailing lists. All
technical discussion on MPLS-TP SHOULD be directed to the MPLS-TP technical discussion on MPLS-TP SHOULD be directed to the MPLS-TP
list, but other working group mailing lists SHOULD be notified when list, but other working group mailing lists SHOULD be notified when
appropriate so that individuals can participate in the discussions on appropriate so that individuals can participate in the discussions on
the MPLS-TP list. the MPLS-TP list.
Consensus activities (such as a working group last call) MUST be Consensus activities (such as a working group last call) MUST be
started on an working group mailing list, but the MPLS-TP responsible started on an working group mailing list, but the MPLS-TP responsible
working group chair MAY direct discussions to the MPLS-TP list and working group chair SHOULD direct discussions to the MPLS-TP list and
MAY direct that consensus will be judged on that list. 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 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 to the ITU-T MUST be sent to the Ad Hoc MPLS-TP Information sent to the ITU-T MUST be sent to the Ad Hoc Team on
mailing list. Information sent to the IETF MUST be sent to the MPLS-TP mailing list. Information sent to the IETF MUST be sent to
MPLS-TP mailing list. the MPLS-TP mailing list.
o Formal information exchange o Formal information exchange
In addition to the informal information exchange, a formal In addition to the informal information exchange, a formal
information exchange is accomplished by liaison correspondence information exchange is accomplished by liaison correspondence
between the two organisations. Exchange of liaisons makes it between the two organisations. Exchange of liaisons makes it
possible to follow the request/response exchange between the possible to follow the request/response exchange between the
organisations in more detail, and to obtain an official view of organisations in more detail, and to obtain an official view of
each organisation's position on any topic. 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. Adapted IETF Working Group Process
2.3.1. Flow Chart 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. The flow chart and the process as described in Section 2.3.2 process. The flow chart and the process as described in Section 2.3.2
are equally normative. are equally normative.
............. ............. .............
: Ind Docs :--------+ : JWT docs : : Ind Docs :
............. | ............. .............
| | | |
|(1) |(2) |(3) |(1)
| | |
v | v
+-----------+ | +----------------+ (4) +-------+
+--->| WG proc | +----->| MEAD team proc |------>| ITU-T |
| | |-------+ +--| | +-------+
| +-----------+ | | +----------------+ |
| ind-00, ind-01, etc | | ^ ind-00, ind-01, etc |(5)
| |(6) +--+---+ | |(6) |
+----------+ |(7) +-------+<-----------------+
review | review
v v
+-----------------+ +---------------+
| poll for wg doc | | WG Process |
+-----------------+ +---------------+
|(8) | ^ ind-00, ind-01, etc
| | |
| | |(2)
| | |
| +-------+
(3)| review
|
v
+-----------------+
| Poll for WG Doc |
+-----------------+
| |
|(4)
v v
+-------------+ (9) +-------+ +-------------+ (5) +-------+
+----------->| wg doc |------------->| ITU-T | +---------->| WG Doc |---------->| ITU-T |
| +-------------+ +-------+ | +-------------+ +-------+
| | ^ wg-00, wg-01, etc | | | ^ wg-00, wg-01, etc |
| | | |(11) |(10) | | | | |
(15)| (12)| +------+<------------------+ | | | |(7) |(6)
| | review | | | | |
| v (11)| (8)| +------+-<--------------+
| +-----------------+ | | review
+-----| wg last call | | v
| +-----------------+
+----| WG Last Call |
+-----------------+ +-----------------+
| ^ | | ^ |
(13)| |(14) |(16) (9)| |(10) |(12)
v | | v | |
+---------+ | +---------+ |
| ITU-T | | | ITU-T | |
+---------+ | +---------+ |
v v
+---------------+ +---------------+
| req for pub | | Req for Pub |
+---------------+ +---------------+
2.3.2. The IETF MPLS-TP Process 2.3.2. The IETF MPLS-TP Process
This section describes the development for MPLS-TP documents. It sets This section describes the development for MPLS-TP documents. It sets
out the process that is illustrated by the flow chart in Section 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 2.3.1. The numbered arrows in the flow chart are described as
numbered steps in the process in the list below. numbered steps in the process in the list below.
Individual MPLS-TP documents can take different paths through the Individual MPLS-TP documents can take different paths through the
this process. Although the different paths through the flow chart are this process. Although the different paths through the flow chart are
given as options, it is always possible a particular MPLS-TP 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 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 on the guidance of the MPLS-TP responsible working group chair and in
cooperation with the relevant working group chairs and the document cooperation with the relevant working group chairs and the document
editors/authors. editors/authors.
1. Independent Documents through Working Group Processing 1. Independent Documents through Working Group Processing
Internet-Drafts MAY be introduced by their authors to describe Internet-Drafts MAY be introduced by their authors to describe
any aspect of MPLS-TP. This option (compare with step 2) results any aspect of MPLS-TP. This option results in the document being
in the document being discussed and reviewed by the appropriate discussed and reviewed by the appropriate IETF working group as
IETF working group as determined by the working group chairs. The determined by the working group chairs. The normal IETF process
normal IETF process will be applied, and the authors will revise will be applied, and the authors will revise the document (step
the document (step 6) until it is adopted as a working group 2) until it is adopted as a working group draft (see step 3).
draft (see step 7).
Any individual or group of individuals can create an Internet- Any individual or group of individuals can create an Internet-
Draft through this step. Draft through this step.
2. Independent Documents through MEAD Team Coordination 2. Authors of independent documents SHOULD solicit comments on the
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).
Any individual or group of individuals can create an Internet-
Draft through this step. However, the MEAD team MAY decide that
it is unwilling to support the document. In this case, the
authors MAY bring the document in following step 1.
3. Joint Working Team Originated Documents
The JWT MAY initiate MPLS-TP documents, or request that the MEAD
team create specific documents. The MEAD team MUST process these
as independent submissions as described in step 2.
[RFC5317] includes a list of JWT documents that MUST be
considered by the MEAD team to be processed on this step, but the
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. Every time a document is accepted by the MEAD team into the set
of documents coordinated by the MEAD team a liaison MUST be sent
to the ITU-T with a pointer to that document. At the same time a
note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list
informing the list that the document has become a MEAD team
document.
Each time a document coordinated by the MEAD team is revised a
note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list,
and a liaison MAY be sent to the ITU-T to inform them of the
progress of the document.
The ITU-T MAY respond to these liaisons (step 5), but a response
is not required (see Section 3 and Section 4).
5. 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. These communications may be
unsolicited or in response to a request from the IETF (step 4),
and MAY be informal information exchanges or formal information
exchanges (see Section 2.2). Such exchanges (informal or formal)
SHOULD be accompanied by an email to the MPLS-TP mailing list
from the ahtmplstp chair.
The MEAD team SHOULD give due consideration to the issues raised
in the communications received ITU-T, and SHOULD attempt to make
suitable changes to the MPLS-TP 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 and the
addressees of the liaison are responsible for ensuring that this
step is completed.
6. Authors of independent documents SHOULD solicit comments on the
MPLS-TP mailing list and on any appropriate IETF working group MPLS-TP mailing list and on any appropriate IETF working group
mailing lists. Comments can also be received from the ITU-T as mailing lists.
described for step 5.
The authors SHOULD revise the documents according to comments The authors SHOULD revise the documents according to comments
received from all sources, or explain why no changes been made. received from all sources, or explain why no changes been made.
7. If an MPLS-TP document seems mature enough to become a working 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 group document, a poll is done on the MPLS-TP mailing list and
the appropriate working group mailing list to determine whether the appropriate working group mailing list to determine whether
there is consensus to adopt the document as a working group there is consensus to adopt the document as a working group
document. document.
Which working group a document goes into is decided jointly by Which working group a document goes into is decided jointly by
the MPLS-TP responsible working group chair and the chairs of the the MPLS-TP responsible working group chair and the chairs of the
target working group. target working group.
8. If the document is accepted as a working group document the 4. 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 Normal IETF working group process SHALL apply. All IETF
discussions about the document MUST now be held on the MPLS-TP discussions about the document MUST now be held on the MPLS-TP
mailing list with notifications sent to the relevant IETF working mailing list with notifications sent to the relevant IETF working
group mailing list. group mailing list.
9. When a document is accepted as a working group document 5. When a document is accepted as a working group document, a
informational notification MUST be sent to the ITU-T as a liaison liaison MUST be sent to the ITU-T to inform them of the progress.
and as an email to the ahtmplstp mailing list. No response to This liaison SHOULD be "for comment", but if the document is not
this liaison is expected. 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 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 revised a note SHOULD be sent to the Ad Hoc Team on MPLS-TP
mailing list, and a liaison MAY be sent to the ITU-T to inform mailing list, and a liaison SHOULD be sent to the ITU-T to inform
them of the progress of the document. No response to these them of the progress of the document. This liaison SHOULD be "for
liaisons is expected. 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 The IETF working group MAY solicit input from the ITU-T at any
time. time by sending a liaison for comment.
10. At any time, it is possible for ITU-T participants to send review 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 on any MPLS-TP document. Such comments SHOULD be sent as
comments to the MPLS-TP mailing list according to normal IETF comments to the MPLS-TP mailing list according to normal IETF
process. process.
Additionally, this step provides for communication from ITU-T Additionally, this step provides for communication from ITU-T
Study Groups or Questions (see Section 3.2). These communications Study Groups or Questions (see Section 3.2). These communications
may be unsolicited or in response to a request from the IETF may be unsolicited or in response to a request from the IETF
(step 8), and MAY be informal information exchanges or formal (step 5), and MAY be informal information exchanges or formal
information exchanges (see Section 2.2). Such exchanges (informal information exchanges (see Section 2.2). Such exchanges (informal
or formal) SHOULD be accompanied by an email to the MPLS-TP or formal) SHOULD be accompanied by an email to the MPLS-TP
mailing list from the ahtmplstp chairs. mailing list from the Ad Hoc Team on MPLS-TP chairs.
The document editors and the working group SHOULD give due The document editors and the working group MUST give due
consideration to the issues raised in the communications from the consideration to the issues raised in the communications from the
ITU-T, and SHOULD attempt to make suitable changes to the MPLS-TP ITU-T, and SHOULD attempt to make suitable changes to the MPLS-TP
document or MUST otherwise explain why no change is being made. document or MUST otherwise explain why no change is being made.
Formal information exchanges MUST receive a response if Formal information exchanges MUST receive a response if
requested. The IETF liaison to the ITU-T on MPLS is responsible requested. The IETF liaison to the ITU-T on MPLS is responsible
for ensuring that this step is completed. for ensuring that this step is completed.
11. Editors working group documents SHOULD solicit comments on the 7. Editors of working group documents SHOULD solicit comments on the
MPLS-TP mailing list and on any appropriate IETF working group MPLS-TP mailing list and on any appropriate IETF working group
mailing lists. Comments can also be received from the ITU-T as mailing lists. Comments SHOULD also be solicited from the ITU-T
described for step 9. 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 The authors SHOULD revise the documents according to comments
received from all sources. received from all sources.
Note that most comments that lead to updates of working group Note that most comments that lead to updates of working group
documents are a result of spontaneous individual reviews and documents are a result of spontaneous individual reviews and
comments from the individual participants in the MPLS-TP effort comments from the individual participants in the MPLS-TP effort
according to normal IETF process. according to normal IETF process.
12. When an MPLS-TP document is deemed mature enough, a working group 8. When an MPLS-TP document is deemed mature enough, a working group
last call is initiated following normal IETF process. last call is initiated following normal IETF process. The working
group chairs are responsible for judging when to initiate this
last call.
13. When a working group last call is initiated for any MPLS-TP 9. When a working group last call is initiated for any MPLS-TP
document the following actions MUST be taken. document the following actions MUST be taken.
* A liaison containing a request for participation in the working * A liaison for action containing a request for participation in
group last call MUST be sent to the appropriate ITU-T Study the working group last call MUST be sent to the appropriate
Groups and Questions. ITU-T Study Groups and Questions.
The ad hoc team on MPLS-TP is expected to verify that all the The Ad Hoc Team on MPLS-TP chairs are expected to verify that
Study Groups and Questions within the ITU-T that need to all the Study Groups and Questions within the ITU-T that need
respond to the working group last call are aware that it has to respond to the working group last call are aware that it has
been issued. been issued.
* A notification that the working group last call is taking place * A notification that the working group last call is taking place
MUST be sent to the ahtmplstp mailing list and to the MPLS-TP MUST be sent to the Ad Hoc Team on MPLS-TP mailing list and to
mailing list. the MPLS-TP mailing list.
14. The ITU-T is REQUIRED to respond to the liaison in step 13 within
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.
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 The ITU-T response MUST either include comments to be taken under
consideration by the working group along with other last call consideration by the working group along with other last call
comments, or provide a statement that the ITU-T has no comment. comments, or provide a statement that the ITU-T has no comment.
The latter case SHALL be interpreted as ITU-T approval for the The latter case SHALL be interpreted as ITU-T support for the
publication of the document as an RFC. publication of the document as an RFC.
The working group and document editors MUST fully address any The working group and document editors MUST fully address any
comments received from the ITU-T under this step either making comments received from the ITU-T via liaison under this step
the requested changes, or discussing the changes with the ITU-T either making the requested changes, or discuss the changes with
to reach a consensus position on the MPLS-TP mailing list. 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.
15. According to normal IETF process, if the last call comments are 11. According to normal IETF process, if the last call comments are
substantial the document MUST be returned to the working group substantial the document MUST be returned to the working group
for revision and discussion. This MAY necessitate further for revision and discussion. This MUST involve further
communication with the ITU-T (step 9) to clarify or resolve communication with the ITU-T (step 5) to clarify or resolve
issues raised during ITU-T review. issues raised during ITU-T review if they are handled other than
as requested by the ITU-T.
The working group last call MAY be repeated multiple times for The working group last call (step 8) MAY be repeated multiple
revisions of the document. As is normal IETF process, the working times for revisions of the document. As is normal IETF process,
group chairs MAY issue subsequent working group last calls for the working group chairs MAY issue subsequent working group last
the entire document or MAY be limited to only the updated text in calls for the entire document or MAY limit them to only the
the document. In the latter case, further comments from within updated text. In the latter case, further comments from within
the IETF or from the ITU-T SHOULD be limited as instructed by the the IETF or from the ITU-T SHOULD be limited as instructed by the
working group chair. working group chair.
Note that, according to normal IETF process, if the last call Note that, according to normal IETF process, if the last call
comments are minor, they SHOULD be addressed by the document comments are minor, they SHOULD be addressed by the document
editors in coordination with the working group chairs and with editors in coordination with the working group chairs and with
notification to the MPLS-TP mailing list. notification to the MPLS-TP mailing list.
16. When all last call comments have been addressed or responded to 12. When all last call comments have been addressed or responded to
and all necessary working group last calls have been held, the and all necessary working group last calls have been held, the
working group chairs of the owning working group with assistance working group chairs of the owning working group with assistance
of the MPLS-TP responsible working group chair will request of the MPLS-TP responsible working group chair will request
publication of the document as an RFC following normal IETF publication of the document as an RFC following normal IETF
process. process.
Once this request for publication is sent there is no further Once this request for publication is sent, the document will be
scope for the ITU-T to influence the development of the document. handled as any other IETF document with individual comments made
After this point, the document will be handled as any other IETF during IETF last call, and with IESG review following. Therefore,
document with individual comments made during IETF last call, and after this point there is no further scope for ITU-T experts to
with IESG review following. influence the development of the document other than as
individual contributors.
Note that if these later stages in the publication process cause Note that if these later stages in the publication process cause
significant changes to the document, it MAY be fully or partially significant changes to the document, it MAY be fully or partially
returned to the working group, in which case some form of WG last returned to the working group, in which case some form of WG last
call with ITU-T consultation MUST take place following from step call with ITU-T consultation MUST take place following from step
12 as outlined above. 8 as outlined above.
2.4. Naming Conventions for MPLS-TP Documents 2.4. Naming Conventions for MPLS-TP Documents
To make it easier to search in the IETF Internet-Draft repositories, To make it easier to search in the IETF Internet-Draft repositories,
the following rules MUST be followed for naming the MPLS-TP Internet- the following rules MUST be followed for naming the MPLS-TP Internet-
Draft. Draft.
o All MPLS-TP Internet-Draft MUST include the sequence "mpls-tp" o All MPLS-TP Internet-Draft MUST include the sequence "mpls-tp"
in the filename. in the filename.
skipping to change at page 16, line 48 skipping to change at page 15, line 50
"wgname" 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.
"topic" indicates the content of the draft, e.g. "oam-framework". "topic" indicates the content of the draft, e.g. "oam-framework".
"??" indicates a two digit version number, starting with "00". "??" indicates a two digit version number, starting with "00".
3. Expectations on ITU-T Participation in the Process 3. Expectations on ITU-T Participation in the Process
The IETF looks for input from the ITU-T at three key points in the The IETF looks for input from the ITU-T at two key points in the
process described in Section 2. process described in Section 2.
o Steps 4 and 5 : Review of MEAD Team Documents o Steps 5 and 6 : Review of Working Group Documents
o Steps 9 and 10 : Review of Working Group Documents
o Steps 13 and 14 : Working Group Last Call and Document Approval o Steps 9 and 10 : Working Group Last Call and Document Approval
This section briefly describes what the IETF expects to happen on the This section briefly describes what the IETF expects to happen on the
ITU-T side at these interaction points. ITU-T side at these interaction points.
3.1. MEAD Team Document Review 3.1. Working Group Document Review
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.
As shown by step 4 in the process described in Section 2, the IETF
will notify the ITU-T of the existence of such documents and will
normally inform the ITU-T of new revisions. The ITU-T is not
required to respond to these communications.
The IETF may also request review or discussion of MEAD team
documents. The ITU-T is required to respond to this type of
communication if it is a formal liaison (step 5) 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.
Additionally, the ITU-T may send unsolicited communications on a MEAD
team document as either informal or formal communications (step 5).
Formal communications may request a response from the IETF.
However, ITU-T participants are encouraged to bring their comments
and questions to 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.
3.2. Working Group Document Review
The ITU-T may provide input to documents that are being developed by 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 IETF working groups. They are open for informal and formal comment by
the ITU-T and its participants. the ITU-T and its participants.
As shown by step 9 in the process described in Section 2, the IETF 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 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 normally inform the ITU-T of new revisions. The ITU-T is not
required to respond to these communications. required to respond to these communications.
The IETF may also request review or discussion of working group The IETF may also request review or discussion of working group
documents. The ITU-T is required to respond to this type of documents. The ITU-T is required to respond to this type of
communication if it is a formal liaison (step 10) within the deadline communication if it is a formal liaison (step 6) within the deadline
set by the liaison (see Section 3.4). In this case, it should either 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 send a liaison response with comments and questions, or it should
acknowledge the liaison from the IETF saying that there are no acknowledge the liaison from the IETF saying that there are no
questions or comments at this time. The latter type of response will 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 not be taken by the IETF to imply any form of support for the
document unless it is explicitly expressed. document unless it is explicitly expressed.
Additionally, the ITU-T may send unsolicited communications on a Additionally, the ITU-T may send unsolicited communications on a
working group document as either informal or formal communications working group document as either informal or formal communications
(step 5). Formal communications may request a response from the IETF. (step 6). Formal communications may request a response from the IETF.
However, ITU-T participants are encouraged to bring their comments However, ITU-T participants are encouraged to bring their comments
and questions to the MPLS-TP mailing list directly, because this will and questions to the MPLS-TP mailing list directly, because this will
be more efficient and conforms to the normal IETF process. Comments 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 received in this way will be treated in the same way any as other
individual comments received on IETF documents. individual comments received on IETF documents.
3.3. Working Group Last Call and Document Approval 3.2. Working Group Last Call and Document Approval
A working group last call is issued when a working group document is 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 close to being ready for publication as an RFC. The intention is to
make sure that there are no important pieces missing, that technical make sure that there are no important pieces missing, that technical
details are correct, and that there is consensus within the working details are correct, and that there is consensus within the working
group for moving forward. Consensus for MPLS-TP documents is judged group for moving forward. Consensus for MPLS-TP documents is judged
on the designated mailing list (normally the MPLS-TP mailing list) by on the designated mailing list (normally the MPLS-TP mailing list) by
the chairs of the working group that has developed the document in the chairs of the working group that has developed the document in
association with the MPLS-TP responsible working group chair. association with the MPLS-TP responsible working group chair.
During working group last call for all MPLS-TP documents the ITU-T During working group last call for all MPLS-TP documents the ITU-T
will always be consulted about the content of the documents. The will always be consulted about the content of the documents. The
purpose of this step (step 13) is to ensure that the documents purpose of this step (step 9) is to ensure that the documents
address the needs and requirements of the ITU-T participants. address the needs and requirements of the ITU-T participants.
A formal communication will be made to the ITU-T to make it aware 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 that an IETF working group last call has been started and requesting
review and comment. According to the JWT decision, the ITU-T is review and comment. According to the JWT decision, the ITU-T is
required to respond to a liaison about a working group last call 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 within the time set in announcing the working group last call. ITU-T
participants need to be aware that this step in the process participants need to be aware that this step in the process
represents their last chance to influence the document from within represents their last chance to influence the document from within
the ITU-T, and the liaison response needs to contain all issues and 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 comments - there will not be any scope to raise further concerns at a
later date. 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 Ad Hoc Team on MPLS-TP
mailing list.
The IETF will make a best effort attempt to target the ITU-T Study 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 Groups and Questions that should be involved in responding to the
working group last call. However, the ITU-T must make sure that the working group last call. However, the ITU-T must make sure that the
appropriate entities within the ITU-T participate in responding to appropriate entities within the ITU-T participate in responding to
the working group last call. The ITU-T ad hoc team on MPLS-TP 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 coordinates the development of the ITU-T response to the working
group last call. group last call.
The response to a working group last call should be unambiguous and The response to a working group last call should be unambiguous and
as detailed as possible. The liaison response is not intended to as detailed as possible. The liaison response is not intended to
start a conversation for clarification. It is intended to make clear start a conversation for clarification. It is intended to make clear
statements of technical issues to be addressed and to propose statements of technical issues to be addressed and to propose
resolutions for those issues. Acceptable responses include: resolutions for those issues. Acceptable responses include:
o No issues found. The ITU-T approves publication of the Internet- o No issues found. The ITU-T supports publication of the Internet-
Draft as an RFC in its current form. Draft as an RFC in its current form.
o Minor issues found or questions raised. Please consider fixes to o Minor issues found or questions raised. Please consider fixes to
these issues or respond to these questions before publication of these issues or respond to these questions before publication of
the Internet-Draft as an RFC. the Internet-Draft as an RFC.
o Major issues found. Please address these issues and allow the o Major issues found. Please address these issues and allow the
ITU-T to review the resolution (possibly during a further working ITU-T to review the resolution (possibly during a further working
group last call) before proceeding to publication of the Internet- group last call) before proceeding to publication of the Internet-
Draft as an RFC. Draft as an RFC.
For the avoidance of doubt, the following guidance has been provided
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 Note that, as described in Section 1.2, the cooperation process is
designed to ensure constructive consideration and resolution of all designed to ensure constructive consideration and resolution of all
issues raised by the ITU-T without being blocking on the progress of issues raised by the ITU-T without blocking the progress of the
the IETF's work on MPLS-TP. It is expected that discussion of major 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 issues raised at this stage of the process will be conducted on the
MPLS-TP mailing list and through appropriate communication with the MPLS-TP mailing list and through appropriate communication with the
ITU-T. It is further expected that such issues will be resolved ITU-T. It is further expected that such issues will be resolved
through technical evaluation and rough consensus judged as normal for through technical evaluation and rough consensus judged as normal for
the IETF process. In the event that agreement between the IETF and 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 ITU-T cannot be reached on some technical point, the JWT will be
convened to seek a resolution. convened to seek a resolution.
3.4. Non-Response to Liaisons 3.3. Non-Response to Liaisons
The liaison relationship between the IETF and the ITU-T is founded on The liaison relationship between the IETF and the ITU-T is founded on
the understanding that each party will respond in a timely and the understanding that each party will respond in a timely and
appropriate manner to the other party's liaisons so long as appropriate manner to the other party's liaisons so long as
reasonable notice is given. reasonable notice is given.
Failure to respond by a deadline properly expressed in a liaison must 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 not be used to cause deadlock or to block advancement of work. Such
failures shall be assumed to represent accidental errors or failures shall be assumed to represent accidental errors or
oversights and shall be brought to the attention of the management of oversights and shall be brought to the attention of the management of
the body that has failed to respond. the body that has failed to respond.
In extreme cases, the JWT is empowered to convene to resolve issues In extreme cases, the JWT is empowered to convene itself to resolve
of failed communications. issues of failed communications.
4. Guidelines For MPLS-TP work in the ITU-T 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 an 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 IETF 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 liaison to the ITU-T on MPLS, the MPLS-TP responsible working
group chair and the MPLS-TP responsible AD. They are responsible group chair, and the MPLS-TP responsible AD. They are responsible
for sending a consolidated response from the IETF, but may for sending a consolidated response from the IETF, but may
delegate the work of writing the response. delegate the work of writing the response.
The IETF must respond to such liaisons according to the deadline The IETF must respond to such liaisons according to the deadline
in the liaison. Acceptable responses include: in the liaison. Acceptable responses include:
o Acknowledgement of receipt and agreement that the ITU-T is o Acknowledgement of receipt and agreement that the ITU-T is
clear to proceed with the work described. clear to proceed with the work described.
o Request that the work described be transferred from the ITU-T to o Request that the work described be transferred from the ITU-T to
skipping to change at page 21, line 7 skipping to change at page 20, line 8
been resolved. In the event that this response is seen as been resolved. In the event that this response is seen as
blocking of ITU-T work, the JWT may be convened to seek a blocking of ITU-T work, the JWT may be convened to seek a
resolution. resolution.
Note that the process described in this section is conformant to the Note that the process described in this section is conformant to the
Change Process for Multiprotocol Label Switching (MPLS) and Change Process for Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929]. Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929].
5. IANA Considerations 5. IANA Considerations
There are no requests for IANA allocation of code points in this There are no requests for IANA action 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 the IETF and the ITU-T and thus does not introduce any new
considerations. security considerations.
The successful development of MPLS-TP standards that are consistent The successful development of MPLS-TP standards that are consistent
across the industry is an essential component to ensuring the across the industry is an essential component to ensuring the
security and stability of MPLS networks. 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 the Thanks to Tom Petch who spent time trying to sort out what the
document said, and who sent comments that helped clarify the document said, and who sent comments that helped clarify the
document. document. Thanks to the participants of ITU-T Study Group 15 who
provided review and comments on an early version of this text.
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.
 End of changes. 81 change blocks. 
270 lines changed or deleted 250 lines changed or added

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