idnits 2.17.1
draft-ietf-mpls-tp-process-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** The document seems to lack a License Notice according IETF Trust
Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009
Section 6.b -- however, there's a paragraph with a matching beginning.
Boilerplate error?
(You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Feb 2009 rather than one of the newer Notices. See
https://trustee.ietf.org/license-info/.)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 8, 2009) is 5341 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1
3 Network Working Group L. Andersson
4 Internet-Draft Ericsson Inc
5 Intended status: Standards Track D. Ward
6 Expires: March 8, 2010 Cisco Systems
7 M. Betts
8 Huaweil
9 September 8, 2009
11 Joint IETF and ITU-T Multi-Protocol Label Switching (MPLS) Transport
12 Profile process
14 draft-ietf-mpls-tp-process-00.txt
16 Status of this Memo
18 This Internet-Draft is submitted to IETF in full conformance with the
19 provisions of BCP 78 and BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
24 Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on January 1, 2010.
39 Copyright Notice
41 Copyright (c) 2009 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents in effect on the date of
46 publication of this document (http://trustee.ietf.org/license-info).
47 Please review these documents carefully, as they describe your rights
48 and restrictions with respect to this document.
50 Abstract
52 The decision to develop a Multiprotocol Label Switching (MPLS)
53 Transport Profile in cooperation between IETF and ITU-T does not
54 fully define and document processes for development of the required
55 RFCs.
57 This document complements the processes documented in the JWT
58 decision with a few separate elements; it:
60 o provides an adaptation of the IETF working group process,
62 o identifies the expected participation in the process by the ITU-T,
64 o clarifies the decision rules regarding MPLS-TP documents.
66 This document is not intended to specify any ITU-T process; to the
67 extent necessary ITU-T activities will be done according to ITU-T
68 process/rules.
70 Nor is this document is intended to specify the IETF working group
71 process, it is limited to the temporary adaptations of that process
72 that is the result of that IETF and ITU-T accepted the proposal in
73 the JWT report to jointly develop the MPLS Transport Profile. In
74 general it may be said that these adaptations are introduced to
75 ensure a good and consistent document review across the two
76 organizations.
78 Table of Contents
80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
82 1.1.1. IETF terms and abbreviations . . . . . . . . . . . . . 5
83 1.1.2. ITU-T terms and abbreviations . . . . . . . . . . . . 5
84 2. Adaptation of the IETF working group process . . . . . . . . . 7
85 2.1. Adaptation of the IETF working group process . . . . . . . 7
86 2.2. The IETF MPLS-TP process . . . . . . . . . . . . . . . . . 8
87 2.2.1. Developing a MPLS-TP document . . . . . . . . . . . . 9
88 3. Expectations on ITU-T participation in the process . . . . . . 14
89 3.1. Becoming a MEAD team document . . . . . . . . . . . . . . 14
90 3.2. Comments on MEAD team documents by participants in the
91 ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . 14
92 3.3. Poll for working group documents . . . . . . . . . . . . . 14
93 3.4. Responding to an IETF Working Group Last Call . . . . . . 15
94 4. Specific guidelines that apply to work on MPLS-TP in the
95 ITU-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
96 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17
97 6. Security considerations . . . . . . . . . . . . . . . . . . . 18
98 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
100 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
101 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
104 1. Introduction
106 When IETF and ITU-T entered into the agreement to develop MPLS-TP,
107 the JWT agreement included the decision that the MPLS-TP documents
108 should be developed "according to IETF processes". It was also
109 assumed that there would be close cooperation in reviewing these IETF
110 documents. The JWT decision is documented in RFC 5317 [RFC5317].
112 However, the process for this close cooperative review was mostly
113 left to be decided as the documents evolved. The ITU-T committed to
114 responding promptly to IETF working group last calls, this may
115 require the development of the response via correspondence.
117 Nor is this document is intended to specify the IETF working group
118 process, it is limited to the temporary adaptations of that process
119 that is the result of that IETF and ITU-T accepted the proposal in
120 the JWT report to jointly develop the MPLS Transport Profile. In
121 general it may be said that these adaptations are introduced to
122 ensure a good and consistent document review across the two
123 organizations.
125 This document complements the process as documented in the JWT
126 decision with a few separate elements; it:
128 o Provides an adaptation of the IETF working group process, with
129 respect to the role of the teams (MPLS Interoperability Design
130 Team (MEAD Team), the Joint Working Team (JWT) and the ITU-T
131 MPLS-TP ad hoc team) that has been set up to facilitate the
132 development of MPLS-TP; see Section 2.
134 o Identifies the expected participation by the ITU-T in the document
135 development process; see Section 3.
137 o Clarifies decision rules regarding MPLS-TP documents; see
138 Section 4.
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
142 document are to be interpreted as described in RFC 2119 [RFC2119].
144 1.1. Terminology
146 This section includes a number of terms and abbreviations that are
147 used in this document. The section is split into two subsection;
148 IETF terms and ITU-T terms.
150 1.1.1. IETF terms and abbreviations
152 o JWT - Joint Working Team, a team with participants with experience
153 from standards development in the IETF and the ITU-T.
155 Note: The JWT is not part of either the IETF or ITU-T, but a group
156 that has been set up to facilitate cooperation on MPLS-TP between
157 the two organizations.
159 o JWT documents - the set of documents envisioned in the
160 documentation of the JWT decision, see RFC 5317 [RFC5317].
162 o MEAD team - MPLS Interoperability Design Team, a temporary team
163 with participants with experience from standards development for
164 MPLS and transport networks. The MEAD team is chartered to
165 coordinate the development of MPLS-TP within the IETF and to
166 coordinate the on MPLS-TP cooperation with the ITU-T.
168 o MPLS-TP documents - the following sets of documents are counted as
169 MPLS-TP documents:
171 * Internet Drafts that are coordinated by the MEAD team.
173 * Individual Internet Drafts that addresses the MPLS-TP problem
174 space.
176 * Working group Internet Drafts that addresses the MPLS-TP
177 problem space.
179 * Internet Drafts that are considered for publication by the IESG
180 and that addresses the MPLS-TP problem space.
182 * Internet Drafts that are approved for publication by the IESG
183 and that addresses the MPLS-TP problem space.
185 * Published RFCs that addresses the MPLS-TP problem space.
187 * ITU-T Recommendations and draft Recommendations in various
188 stages of development that addresses the MPLS-TP problem space.
190 Documents that originates from the IRTF RFC stream is NOT considered
191 as MPLS-TP documents.
193 1.1.2. ITU-T terms and abbreviations
195 o Ad Hoc on MPLS-TP - A team established by SG 15 of ITU-T to
196 coordinate the work on MPLS-TP within the ITU-T and to act as a
197 focal point for communication with the IETF.
199 o Contribution - a contribution is a document that is submitted to
200 the ITU-T to advance work on the development of a Recommendation
201 or to propose the development of a new Recommendation.
203 o Recommendation - a Recommendation is the ITU-T standards document.
205 2. Adaptation of the IETF working group process
207 The IETF working group processes as defined in RFC 2026 [RFC2026] are
208 for the purpose of the MPLS-TP updated as follows.
210 The IETF works according to a 'rough consensus' model, where working
211 group chairs determine the consensus after discussions on the mailing
212 lists. This is applicable to the MPLS-TP work also. The
213 mpls-tp@ietf.org is the mailing list used to find out consensus and
214 consensus is determined by the MEAD team chair. After a document has
215 become a working group document the consensus is decided by the WG
216 chairs and the MEAD team chair jointly.
218 A most important part of this process is the information exchange
219 between the IETF and ITU-T. This information exchange consists of
220 two equally important pieces:
222 o informal information exchange
224 this is done primarily by E-Mail to the relevant mailing lists.
225 Information sent from IETF, IETF areas and working groups, or from
226 the IETF MEAD team are sent to and areas and the
227 ahmpls-tp@lists.itu.int mailing list. Information sent from ITU-T
228 to the IETF should e sent to the MEAD team (mead@ietf.org) and/or
229 the mpls-tp@ietf.org mailing list.
231 o formal information exchange
233 In addition to E-Mail, a formal information exchange is
234 accomplished by liaison correspondence between the two
235 organisations. Exchange of liaisons makes it possible to follow
236 the request/response exchange between the organisations in more
237 detail.
239 2.1. Adaptation of the IETF working group process
241 The flow chart below describes the adaption of the working group
242 process
243 ............. .............
244 : Ind Docs :------+ : JWT docs :
245 ............. | .............
246 | | |
247 | ind-00 (1) | ind-00 (2) | ind-00 (3)
248 | | |
249 v | v
250 +-----------+ | +----------------+ (4) +-------+
251 | WG proc | +------->| MEAD team proc |<----->| ITU-T |
252 | |-------+ +--| | +-------+
253 +-----------+ | | +----------------+ (5) |
254 +-> ind-00, ind-01, etc | | ind-00, ind-01, etc <-+<-----+
255 | | (6) +--+---+ (6) | |
256 +----------+ |(7) +-------------+
257 review +----+ review
258 |
259 poll for wg doc -----------------+
260 | | (7a)
261 v v
262 +-------------+ (8) +-------+
263 +----------> | wg doc |<------------>| ITU-T |
264 | +-------------+ +-------+
265 | | +-> wg-00, wg-01, etc |
266 | | | | (9) | (10)
267 | | +----------+<----------------+
268 | (11) | review
269 | v
270 | +-----------------+ (12) +---------+
271 (14b) | | wg last call |<----------->| ITU-T |
272 | +-----------------+ +---------+
273 | | ^ |
274 | (13)| |(14a) | (15)
275 | v | |
276 | +---------+ |
277 +-------| ITU-T | |
278 +---------+ |
279 |
280 v
281 +-----------------+
282 | req for publ |
283 +-----------------+
285 2.2. The IETF MPLS-TP process
287 This section gives guidelines for how the flow chart above could be
288 traversed.
290 2.2.1. Developing a MPLS-TP document
292 Individual MPLS-TP documents may take different paths through the
293 this process, the numbers in the list below are mapped to the numbers
294 in the flow chart above.
296 Although the different paths through the flow chart are given as
297 'options' it is always possible for the MEAD team to step in and take
298 over the shepherding of a particular MPLS-TP Internet Draft . This
299 is done in cooperation between the MEAD team chair, the relevant
300 working group chairs and the document editors/authors.
302 1. They may be intended for and managed by a working group.
304 This means that the author, or authors, of such a document have
305 chosen to send the document to a working group instead of
306 running through the MEAD team. Normal IETF process will kick in
307 in such cases and working group chairs will agree to which
308 working group(s) such a document will be taken.
310 2. They may be coordinated by the MEAD team.
312 This means that the author, or authors, of such a document have
313 chosen to send the document to the MEAD team to be coordinated
314 with the rest of the MPLS-TP documents that is in the purview of
315 the MEAD team.
317 3. They may be originated by the MEAD team based on the JWT
318 decision.
320 In documentation of the work of the JWT, there is a proposed
321 document structure. The MEAD team used this structure to decide
322 on a set of documents that will, when completed, constitute the
323 MPLS-TP standard. This set of documents may change slightly, if
324 - e.g. - it becomes more appropriate to split a single document
325 into two or more, or if some new aspect of MPLS-TP needs to be
326 specified.
328 4. Everytime a document is accepted by the MEAD team into the set
329 of documents coordinated by the MEAD team a liaison is sent to
330 the ITU-T with a pointer to that document. At the same time a
331 note is sent to the MPLS-TP ad hoc team mailing list informing
332 the list that the document has become a MEAD team document.
334 The ITU-T may chose to respond to the liaison but is not
335 required to do so, see Section 3 and Section 4.
337 5. At any time, it is possible for the ITU-T SG and Question
338 participants to send review comments on MEAD team documents. It
339 is also possible for the MEAD team to ask for such reviews and
340 comments.
342 Any time such input or requests are sent between the two
343 organizations it SHALL be accompanied by a note from the MPLS-TP
344 ad hoc team chair(s) to the MEAD team mailing list, or from the
345 MEAD team chair to the MPLS-TP ad hoc team mailing list. This
346 is done to enhance the efficiency of the information exchange.
348 6. A working group or the MEAD team may issue requests for general
349 comments on MPLS-TP documents at any time, if it is deemed
350 appropriate to extend these requests to the MPLS-TP ad hoc team
351 this is done via a note according to entry (5) in this list.
353 7. If a MPLS-TP document seems mature enough to become a working
354 group document, a poll is done on the mpls-tp mailing list and
355 the appropriate working group mailing list (7), this request
356 will also be sent to the ITU-T as a liaison (7a) and a note will
357 also be sent to the MPLS-TP ad hoc team.
359 Which working group a document goes into is decided jointly
360 between the MEAD team, working group chairs of the potential
361 working groups and the document editors/authors.
363 If the document is accepted as a working group document the
364 working group takes over the revision control of the document.
366 The ITU-T is expected to respond to the liaison within in the
367 time indicated in the liaison, see Section 3 and Section 4.
369 8. Every time a MPLS-TP document is accepted as a working group
370 document by any IETF working group, a liaison is sent to the
371 ITU-T with a pointer to the document. At the same time, a note
372 is sent to the MPLS-TP ad hoc team mailing list informing the
373 list that the document has become a working group document.
375 9. Working group documents may be reviewed in several steps, every
376 time such a review is initiated the MPLS-TP ad hoc team is
377 notified (10).
379 Note that most comments leading to updates of working group
380 documents are a result of spontaneous individual reviews and
381 comments from the individual participants in the MPLS-TP effort.
383 10. Every time a review is initiated by a working group the
384 appropriate ITU-T SGs and Questions will be notified by E-Mail
385 to the MPLS-TP ad hoc team.
387 Optionally the request for review may be accompanied by a
388 liaison to formalize the request.
390 The MPLS-TP ad hoc team is responsible for ensuring that any
391 e-mail requests are copied/forwarded to the relevant SGs and
392 Questions.
394 11. When a document is deemed mature enough, a working group last
395 call is initiated. At this time the action describe under item
396 12 in this list MUST be executed.
398 12. Procedures to be followed when a working group last call is
399 initiated.
401 * A liaison containing a request for participation in the
402 working group last call will be sent to the appropriate ITU-T
403 SGs and Questions.
405 * A notification that the working group last call is taking
406 place will be provided to the MPLS-TP ad hoc team via E-Mail
407 sent to the MPLS-TP mailing list.
409 * ITU-T is REQUIRED to respond to the liaison within the time
410 indicated. The MPLS-TP ad hoc team is expected to verify
411 that all the SGs and Questions within the ITU-T that need to
412 respond to the working group last call are aware that it has
413 been issued.
415 13. When all last call comments are addressed and/or responded to,
416 the document will be sent to the ITU-T, asking if the document
417 is ready to be sent to the IESG with a request for publication.
418 The response sought from ITU-T is either an acknowledgment that
419 the document is ready to publish or a response that there is
420 further work that needs to be done.
422 Note: WG last call may be re-iterated, for the entire document
423 or limited to only verify the updates made because of an earlier
424 working group last call.
426 14. The ITU-T has one week to respond (yes or no) to the question
427 posed in (13).
429 The answer can be either "yes - go ahead" (14a), in which case
430 the Working Group will request publication; or ...
432 ... it can be "no - more work is needed" (14b), in which case it
433 will go back into the normal working group process to identify
434 what is needed.
436 15. When the ITU-T gives the final acknowledgement (14a), a request
437 for publication will be sent to the IESG (15).
439 The document that is sent to the ITU-T in step (13) and which
440 generates a positivie response from ITU-T (14a) is sent
441 unchanged, save for editorial changes, to the IESG with a
442 request for publication (15) as a RFC.
444 Once this request for publication is sent, the last point in
445 this process where it is acceptable to allow ITU-T influence in
446 the development of a document is passed. After this point, the
447 document will be handled as any other IETF document.
449 2.2.1.1. Naming conventions for MPLS-TP Internet Drafts
451 To make it easier to search in the IETF Internet Draft repositories
452 the the following guidelines should be followed for the MPLS-TP
453 Internet Draft filenames.
455 o All MPLS-TP Internet Draft should include the sequence "mpls-tp"
456 in the filename.
458 o Individual MPLS-TP Internet Draft should be named according to
459 this format:
461 draft-name-mpls-tp-topic-??.txt
463 "name" is the last name of the main editor, or an acronym
464 indicating the last names of the set of editors.
466 "topic" indicates the content of the draft, e.g. "oam-framework".
468 "??" indictes a two digit version number, starting with "00".
470 o MPLS working group documents should be named according to this
471 format:
473 draft-ietf-mpls-tp-topic-??.txt
475 o MPLS-TP documents from other working groups shouldbe named
476 according to this format:
478 draft-ietf-wg-name-mpls-tp-topic-??.txt
480 "wg-name" is the acronym for any working group chartered to do
481 MPLS-TP work, e.g. pwe3 or ccamp.
483 3. Expectations on ITU-T participation in the process
485 The IETF and ITU-T processes for the development of the MPLS-TP
486 standards interconnect at the following point in the flow chart
487 above: (4), (5), (7a), (8), (10) and (12). This section briefly
488 describes what is expected to happen on the ITU-T side at the
489 interaction points.
491 3.1. Becoming a MEAD team document
493 (4) is a point at which the MEAD team communicates to the ITU-T that
494 a document is considered to be accepted for coordination by the MEAD
495 team.
497 The ITU-T is expected to respond to the communication with a simple
498 ACK or NAK, however a non-response is counted as an ACK.
500 An ACK means that ITU-T accepts that the document has become a MEAD
501 team document, a NAK means that ITU-T has issues that needs to be
502 resolved before the document is allowed to progress.
504 3.2. Comments on MEAD team documents by participants in the ITU-T
506 (5) and (10) offer possibilities for ITU-T, or people active in the
507 ITU-T, to send un-triggered comments on MEAD team or working group
508 documents. Such comments shall be sent to the mpls-tp list and for
509 working group documents also to the appropriate working group mailing
510 list. Comments received in this way will be treated in the same way
511 any as other individual comments received on the IETF documents.
513 3.3. Poll for working group documents
515 (7a) is the point at which an IETF working group informs the ITU-T
516 that a poll to progress a document to an IETF working group document
517 has been started.
519 It is not necessary, or required, for the ITU-T to respond to this
520 message. If the ITU-T has serious concerns these should be provided
521 via a liaison statement. If the ITU-T has no serious concerns it is
522 allowed and encouraged that individual participants provide comments.
523 Such responses shall be sent to the appropriate working group and
524 mpls-tp mailing lists and represent the view of the person sending
525 the mail.
527 An Internet Draft is ready to become a working group draft if it
528 meets at least the three criteria below.
530 o it is within the charter of the working group
532 o it addresses a problem that needs to be solved
534 o it is a good enough start toward solving this problem
536 Responses to polls checking if a document is ready to become a
537 working group document should be limited to considering if the
538 document meets those three criteria.
540 3.4. Responding to an IETF Working Group Last Call
542 (12) is the point in the process where ITU-T is made aware of that an
543 IETF working group last call has been started. The working group
544 last call is issued when a working group document is getting close to
545 being ready for publication. The intention is to make sure that
546 there are no important pieces missing and that technical details are
547 correct.
549 According to the JWT decision ITU-T is required to respond to a
550 working group last call within the time set in announcing the working
551 group last call.
553 The chair of an IETF working group that starts a working group last
554 call will send a liaison to the ITU-T announcing the working group
555 last call. A message will also be sent to the MPLS-TP ad hoc team.
556 The IETF will make a best effort attempt to target the SGs and
557 Questions that should be involved in responding to the working group
558 last call. However, the ITU-T has to make sure that the appropriate
559 entities within the ITU-T participate in responding to the working
560 group last call. The ITU-T MPLS-TP ad hoc team coordinates the
561 development of the ITU-T response to the working group last call.
563 4. Specific guidelines that apply to work on MPLS-TP in the ITU-T
565 These guidelines apply to progressing work on MPLS-TP in the ITU-T.
567 Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T
568 Study Group or Question.
570 Before the ITU-T initiates any new work (i.e. items not previously
571 identified by the JWT) based on such contributions the ITU-T shall
572 send a liaison to the IETF. The message will go to the MEAD team,
573 and the team is responsible for creating a consolidated IETF
574 response.
576 The IETF is expected to respond to the information that a new
577 MPLS-TP work item has been proposed with an ACK or NAK.
579 If the response is a NAK that work item is held until the issues
580 is resolved.
582 5. IANA considerations
584 There are no requests for IANA allocation of code points in this
585 document.
587 6. Security considerations
589 This document defines a process adaptation for the cooperation
590 between IETF and ITU-T and thus does not introduce any new security
591 considerations.
593 7. Acknowledgments
595 Thanks to Eric Gray who helped with grammar and useful comments.
596 Thanks to Tom Petch who spent time trying to sort out what I wanted
597 to say and has sent comments that helped clarify the document.
599 8. References
601 8.1. Normative References
603 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
604 3", BCP 9, RFC 2026, October 1996.
606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
607 Requirement Levels", BCP 14, RFC 2119, March 1997.
609 8.2. Informative References
611 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT)
612 Report on MPLS Architectural Considerations for a
613 Transport Profile", RFC 5317, February 2009.
615 Authors' Addresses
617 Loa Andersson
618 Ericsson Inc
620 Email: loa.andersson@ericsson.com
622 David Ward
623 Cisco Systems
625 Email: dward@cisco.com
627 Malcolm Betts
628 Huaweil
630 Email: malcolm.betts@huawei.com
632