3 Network Working Group L. Andersson 4 Internet-Draft Ericsson Inc 5 Intended status: BCP D. Ward 6 Expires: March 9, 2010 Cisco Systems 7 M. Betts 8 A. Farrel 9 Huawei 10 September 9, 2009 12 IETF Multi-Protocol Label Switching (MPLS) 13 Transport Profile (MPLS-TP) Document Process 15 draft-ietf-mpls-tp-process-01.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 The decision to develop a Multiprotocol Label Switching (MPLS) 52 Transport Profile (MPLS-TP) in cooperation between the IETF and the 53 ITU-T is document in RFC 5317 as the decision of the Joint Working 54 Team on MPLS-TP. 56 This document provides additional detail of the processes for the 57 development of IETF RFCs on MPLS-TP. It provides an adaptation of the 58 IETF working group process; identifies the expected participation in 59 the process by the ITU-T; and clarifies the rules and conventions 60 regarding MPLS-TP documents. 62 This document doe not specify any ITU-T process; ITU-T activities 63 will be done according to ITU-T process/rules. 65 This document does not specify or modify the normal IETF working 66 group process. It is limited to the specific adaptations of that 67 process to facilitate the cooperation agreement between the IETF and 68 the ITU-T on MPLS-TP, and to ensure a good and consistent document 69 review across the two organizations. 71 Table of Contents 73 1. Introduction .................................................. 4 74 1.1. Terminology ............................................... 4 75 1.1.1. IETF Terms and Abbreviations .......................... 4 76 1.1.2. ITU-T Terms and Abbreviations ......................... 6 77 1.2. Purpose and Intent of Cooperation on MPLS-TP .............. 6 78 2. Adaptation of the IETF Working Group Process .................. 8 79 2.1. IETF Consensus and Mailing Lists .......................... 8 80 2.2. Communications with the ITU-T ............................. 8 81 2.3. Adapted IETF Working Group Process ........................ 9 82 2.3.1. Flow Chart ............................................ 9 83 2.3.2. The IETF MPLS-TP Process ............................. 11 84 2.4. Naming Conventions for MPLS-TP Documents ................. 15 85 3. Expectations on ITU-T Participation in the Process ........... 16 86 3.1. MEAD Team Document Review ................................ 17 87 3.2. Working Group Document Review ............................ 17 88 3.3. Working Group Last Call and Document Approval ............ 18 89 3.4. Non-Response to Liaisons ................................. 19 90 4. Guidelines For MPLS-TP work in the ITU-T ..................... 20 91 5. IANA Considerations .......................................... 20 92 6. Security Considerations ...................................... 20 93 7. Acknowledgments .............................................. 21 94 8. References ................................................... 21 95 8.1. Normative References ..................................... 21 96 8.2. Informative References ................................... 21 97 Authors' Addresses .............................................. 22 99 1. Introduction 101 The IETF and ITU-T have entered into an agreement to develop the 102 Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP). 103 This agreement is known as the Joint Working Team on MPLS-TP (JWT) 104 Agreement and is documented in [RFC5317]. The agreement states that 105 MPLS-TP will be documented in IETF RFCs, and assumes that there will 106 be close cooperation with the ITU-T in reviewing these RFCs. 108 This document provides additional detail of the processes for the 109 development of IETF RFCs on MPLS-TP as follows. 111 o It Provides an adaptation of the IETF working group process, with 112 respect to the how the IETF will take input from the ITU-T on 113 MPLS-TP topics. 115 o It identifies the expected participation by the ITU-T in the 116 document development process, noting that the ITU-T has committed 117 to responding promptly to IETF working group last calls in a way 118 that may require the ITU-T to develop responses via 119 correspondence. 121 o It clarifies the rules regarding MPLS-TP documents. 123 This document does not specify or modify the normal IETF working 124 group process. It is limited to the specific adaptations of that 125 process to facilitate the cooperation agreement between the IETF and 126 the ITU-T on MPLS-TP, and to ensure a good and consistent document 127 review across the two organizations. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 Although this document is not a protocol specification, this language 133 is used for clarity and decisiveness. 135 1.1. Terminology 137 This section includes a number of terms and abbreviations that are 138 used in this document. The section is split into two subsection: 139 IETF terms and ITU-T terms. 141 1.1.1. IETF Terms and Abbreviations 143 o JWT - Joint Working Team, a team with participants with experience 144 from standards development in the IETF and the ITU-T. 146 Note: The JWT is not part of either the IETF or ITU-T, but a group 147 that has been set up to facilitate cooperation on MPLS-TP between 148 the two organizations. 150 o JWT decision - A set of recommendations on the procedural approach 151 to the development of MPLS-TP made by the JWT and documented in 152 [RFC5317]. 154 o JWT agreement - The agreement between IETF and ITU-T based on the 155 JWT decision to jointly develop MPLS-TP according IETF processes. 157 o JWT documents - The set of documents envisioned in the JWT 158 decision [RFC5317]. 160 o MEAD team - MPLS Interoperability Design Team, a temporary team 161 with participants with experience from standards development for 162 MPLS and transport networks. The MEAD team is chartered to 163 coordinate the development of MPLS-TP within the IETF and to 164 coordinate the MPLS-TP cooperation with the ITU-T. 166 o MPLS-TP documents - The following sets of documents are counted as 167 MPLS-TP documents: 169 * Internet-Drafts that are coordinated by the MEAD team. 171 * Individual Internet-Drafts that addresses the MPLS-TP problem 172 space. 174 * Working group Internet-Drafts that addresses the MPLS-TP 175 problem space. 177 * Internet-Drafts that are considered for publication as RFCs by 178 the IESG and that addresses the MPLS-TP problem space. 180 * Internet-Drafts that are approved for publication as RFCs by 181 the IESG and that addresses the MPLS-TP problem space. 183 * Published RFCs that addresses the MPLS-TP problem space. 185 * ITU-T Recommendations and draft Recommendations in various 186 stages of development that address the MPLS-TP problem space. 188 Documents that originate from the IRTF RFC stream are NOT 189 considered as MPLS-TP documents. 191 o MPLS-TP mailing list - An IETF mailing list (mpls-tp@ietf.org) 192 established specifically for the discussion of MPLS-TP issues 193 within the IETF. The MPLS-TP list is the mailing list that is used 194 decide consensus on MPLS-TP issues. This is an open mailing list 195 with publicly available archives. 197 o MPLS-TP responsible working group chair - An IETF MPLS working 198 group chair assigned responsibility for the IETF MPLS-TP effort 199 by the IETF Routing Area Directors. 201 o MPLS-TP responsible AD - An IETF Routing Area Director with 202 management responsibility for the MPLS-TP effort. 204 o IETF liaison to the ITU-T on MPLS - An individual assigned 205 responsibility by the IAB for managing the liaison relationship 206 to the ITU-T in regard of all issues concerning MPLS, including 207 MPLS-TP. 209 1.1.2. ITU-T Terms and Abbreviations 211 o Ad Hoc Team on MPLS-TP (ahtmplstp) - A team established by Study 212 Group 15 of the ITU-T to coordinate the work on MPLS-TP within the 213 ITU-T and to act as a focal point for communication with the IETF 214 about MPLS-TP. 216 o Ad Hoc Team on MPLS-TP mailing list - An ITU-T mail exploder 217 (ahmpls-tp@lists.itu.int) established specifically for the 218 discussion and coordination of the MPLS-TP effort within the 219 ITU-T. 221 o Contribution - A contribution is a document that is submitted to 222 the ITU-T to advance work on the development of a Recommendation 223 or to propose the development of a new Recommendation. 225 o Recommendation - A Recommendation is an ITU-T standards document. 227 1.2. Purpose and Intent of Cooperation on MPLS-TP 229 The purpose and objectives of the development activity on MPLS-TP is 230 described in [RFC5317]. The JWT decision includes the recognition 231 that the design authority for MPLS (including MPLS-TP) is the IETF. 232 At the same time, the JWT decision recognises the role of the ITU-T 233 in providing input (especially input to the requirements statements) 234 to the development process for MPLS-TP. There is also a clear 235 statement of expectation that the ITU-T's opinions will be heard 236 within the IETF and must be properly considered during the 237 development of MPLS-TP documents. 239 The development of standards for MPLS-TP is, therefore, carried out 240 within the IETF according to IETF process and with strong input from 241 the ITU-T. This input takes three forms (see also Section 2.2): 243 o Active participation. 245 All interested parties are encouraged to participate in the 246 development of MPLS-TP standards within the IETF through the 247 normal IETF process. In short, this involves the generation and 248 documentation of new ideas as Internet-Drafts, and the discussion 249 of work in progress through the IETF mailing lists. The IETF is 250 not a membership organisation, and the mailing lists are open. 252 o Informal communication. 254 It is recognised that discussions about MPLS-TP will take place 255 within the Questions and Study Groups of the ITU-T. In order to 256 speed up the development process and ensure smooth communications, 257 the ITU-T is requested to make informal (i.e., email) 258 communications to the IETF whenever any issues or questions 259 arise. Informal communication can be sent by any individual or 260 rapporteur of a Question as an email to the MPLS-TP mailing list. 261 The chairs of the ahtmplstp may also summarise discussions within 262 the ITU-T (especially those on the ahtmplstp mailing list) and 263 communicate them to the IETF via email. 265 o Formal communication. 267 The formal liaison process with the IETF is described in [RFC4052] 268 and [RFC4053]. The process will be used for ensuring that specific 269 progress steps are check-pointed and recorded, and for making sure 270 that appropriate responses are generated in a timely manner. 272 The objective of cooperation between the IETF and ITU-T is to ensure 273 full participation of interested parties to make sure that all 274 opinions are heard with the intention of producing sound and stable 275 MPLS-TP documentation. It is understood that the neither the IETF nor 276 the ITU-T should be in a position to block the work of the other body 277 within its areas of authority. In the context of this document, this 278 means that the ITU-T must not block IETF work on MPLS-TP against the 279 IETF consensus view. 281 Part of this process must be the understanding that all IETF 282 documentation (including RFCs) can be revised or extended according 283 to normal IETF procedures. Therefore, it is not a requirement that 284 the first version of any RFC be perfect for all time (we do not need 285 to "boil the ocean"); the initial aim of the work is to provide 286 documentation of MPLS-TP as it is initially developed and deployed. 288 Fundamental to understanding the process described in the rest of 289 this document and to participating in the MPLS-TP development process 290 is a working knowledge of the procedures of the IETF. Readers needing 291 clarification of the IETF procedures are invited to read [RFC2026], 292 [RFC4677], and [RFC4929]. Further clarification and guidance can be 293 obtained from the MPLS-TP responsible working group chair, the MPLS- 294 TP responsible AD, and the IETF liaison to the ITU-T on MPLS. 296 The ITU-T may also develop Recommendations to document MPLS-TP. The 297 JWT decision recognises that these Recommendations must not contain 298 normative definitions of MPLS-TP (these are captured solely in IETF 299 RFCs). Recommendations on MPLS-TP will be provided for review by the 300 IETF to ensure conformance with the previous point and to verify that 301 the material is consistent across MPLS-TP. The process for producing 302 and reviewing Recommendations is out of scope for this document. 304 2. Adaptation of the IETF Working Group Process 306 The IETF working group processes as defined in RFC 2026 [RFC2026] are 307 adapted as described in this section solely for the purpose of the 308 MPLS-TP work. These adaptations do not apply to any other topic or 309 work within the IETF. 311 2.1. IETF Consensus and Mailing Lists 313 The IETF works according to a 'rough consensus' model, where working 314 group chairs determine the consensus after discussions on the mailing 315 lists. This is also applicable to the MPLS-TP work. The MPLS-TP 316 mailing list exists to focus all IETF discussions on MPLS-TP and to 317 avoid congesting other relevant working group mailing lists. All 318 technical discussion on MPLS-TP SHOULD be directed to the MPLS-TP 319 list, but other working group mailing lists SHOULD be notified when 320 appropriate so that individuals can participate in the discussions on 321 the MPLS-TP list. 323 Consensus activities (such as a working group last call) MUST be 324 started on an working group mailing list, but the MPLS-TP responsible 325 working group chair MAY direct discussions to the MPLS-TP list and 326 MAY direct that consensus will be judged on that list. 328 2.2. Communications with the ITU-T 330 A most important part of this process is the information exchange 331 between the IETF and ITU-T. This information exchange consists of 332 two equally important pieces. 334 o Informal information exchange 336 This is done primarily by e-mail to the relevant mailing lists. 337 Information sent to the ITU-T MUST be sent to the Ad Hoc MPLS-TP 338 mailing list. Information sent to the IETF MUST be sent to the 339 MPLS-TP mailing list. 341 o Formal information exchange 343 In addition to the informal information exchange, a formal 344 information exchange is accomplished by liaison correspondence 345 between the two organisations. Exchange of liaisons makes it 346 possible to follow the request/response exchange between the 347 organisations in more detail, and to obtain an official view of 348 each organisation's position on any topic. 350 2.3. Adapted IETF Working Group Process 352 2.3.1. Flow Chart 354 The flow chart below describes the adaption of the working group 355 process. The flow chart and the process as described in Section 2.3.2 356 are equally normative. 358 ............. ............. 359 : Ind Docs :--------+ : JWT docs : 360 ............. | ............. 361 | | | 362 |(1) |(2) |(3) 363 | | | 364 v | v 365 +-----------+ | +----------------+ (4) +-------+ 366 +--->| WG proc | +----->| MEAD team proc |------>| ITU-T | 367 | | |-------+ +--| | +-------+ 368 | +-----------+ | | +----------------+ | 369 | ind-00, ind-01, etc | | ^ ind-00, ind-01, etc |(5) 370 | |(6) +--+---+ | |(6) | 371 +----------+ |(7) +-------+<-----------------+ 372 review | review 373 v 374 +-----------------+ 375 | poll for wg doc | 376 +-----------------+ 377 |(8) 378 | 379 v 380 +-------------+ (9) +-------+ 381 +----------->| wg doc |------------->| ITU-T | 382 | +-------------+ +-------+ 383 | | ^ wg-00, wg-01, etc | 384 | | | |(11) |(10) 385 (15)| (12)| +------+<------------------+ 386 | | review 387 | v 388 | +-----------------+ 389 +-----| wg last call | 390 +-----------------+ 391 | ^ | 392 (13)| |(14) |(16) 393 v | | 394 +---------+ | 395 | ITU-T | | 396 +---------+ | 397 v 398 +---------------+ 399 | req for pub | 400 +---------------+ 402 2.3.2. The IETF MPLS-TP Process 404 This section describes the development for MPLS-TP documents. It sets 405 out the process that is illustrated by the flow chart in Section 406 2.3.1. The numbered arrows in the flow chart are described as 407 numbered steps in the process in the list below. 409 Individual MPLS-TP documents can take different paths through the 410 this process. Although the different paths through the flow chart are 411 given as options, it is always possible a particular MPLS-TP 412 Internet-Draft to be adopted as a working group draft. This is done 413 on the guidance of the MPLS-TP responsible working group chair and in 414 cooperation with the relevant working group chairs and the document 415 editors/authors. 417 1. Independent Documents through Working Group Processing 419 Internet-Drafts MAY be introduced by their authors to describe 420 any aspect of MPLS-TP. This option (compare with step 2) results 421 in the document being discussed and reviewed by the appropriate 422 IETF working group as determined by the working group chairs. The 423 normal IETF process will be applied, and the authors will revise 424 the document (step 6) until it is adopted as a working group 425 draft (see step 7). 427 Any individual or group of individuals can create an Internet- 428 Draft through this step. 430 2. Independent Documents through MEAD Team Coordination 432 Internet-Drafts MAY be brought to the MEAD team or initiated by 433 the MEAD team. The MEAD team is responsible for discussing, 434 reviewing, and revising (step 6) the documents as independent 435 drafts. The MEAD team will solicit input from the ITU-T (step 4) 436 and will publicise the documents on the MPLS-TP mailing list to 437 encourage input from the IETF community. Normal IETF design team 438 process will apply until the document is adopted as a working 439 group draft (see step 7). 441 Any individual or group of individuals can create an Internet- 442 Draft through this step. However, the MEAD team MAY decide that 443 it is unwilling to support the document. In this case, the 444 authors MAY bring the document in following step 1. 446 3. Joint Working Team Originated Documents 448 The JWT MAY initiate MPLS-TP documents, or request that the MEAD 449 team create specific documents. The MEAD team MUST process these 450 as independent submissions as described in step 2. 452 [RFC5317] includes a list of JWT documents that MUST be 453 considered by the MEAD team to be processed on this step, but the 454 MEAD team MAY vary this list if, for example, it becomes more 455 appropriate to split a single document into two or more, or if 456 some new aspect of MPLS-TP needs to be specified. 458 4. Every time a document is accepted by the MEAD team into the set 459 of documents coordinated by the MEAD team a liaison MUST be sent 460 to the ITU-T with a pointer to that document. At the same time a 461 note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list 462 informing the list that the document has become a MEAD team 463 document. 465 Each time a document coordinated by the MEAD team is revised a 466 note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list, 467 and a liaison MAY be sent to the ITU-T to inform them of the 468 progress of the document. 470 The ITU-T MAY respond to these liaisons (step 5), but a response 471 is not required (see Section 3 and Section 4). 473 5. At any time, it is possible for ITU-T participants to send review 474 comments on any MPLS-TP document. Such comments SHOULD be sent as 475 comments to the MPLS-TP mailing list according to normal IETF 476 process. 478 Additionally, this step provides for communication from ITU-T 479 Study Groups or Questions. These communications may be 480 unsolicited or in response to a request from the IETF (step 4), 481 and MAY be informal information exchanges or formal information 482 exchanges (see Section 2.2). Such exchanges (informal or formal) 483 SHOULD be accompanied by an email to the MPLS-TP mailing list 484 from the ahtmplstp chair. 486 The MEAD team SHOULD give due consideration to the issues raised 487 in the communications received ITU-T, and SHOULD attempt to make 488 suitable changes to the MPLS-TP document or MUST otherwise 489 explain why no change is being made. 491 Formal information exchanges MUST receive a response if 492 requested. The IETF liaison to the ITU-T on MPLS and the 493 addressees of the liaison are responsible for ensuring that this 494 step is completed. 496 6. Authors of independent documents SHOULD solicit comments on the 497 MPLS-TP mailing list and on any appropriate IETF working group 498 mailing lists. Comments can also be received from the ITU-T as 499 described for step 5. 501 The authors SHOULD revise the documents according to comments 502 received from all sources, or explain why no changes been made. 504 7. If an MPLS-TP document seems mature enough to become a working 505 group document, a poll is done on the MPLS-TP mailing list and 506 the appropriate working group mailing list to determine whether 507 there is consensus to adopt the document as a working group 508 document. 510 Which working group a document goes into is decided jointly by 511 the MPLS-TP responsible working group chair and the chairs of the 512 target working group. 514 8. If the document is accepted as a working group document the 515 working group takes over the revision control of the document. 516 Normal IETF working group process SHALL apply. All IETF 517 discussions about the document MUST now be held on the MPLS-TP 518 mailing list with notifications sent to the relevant IETF working 519 group mailing list. 521 9. When a document is accepted as a working group document 522 informational notification MUST be sent to the ITU-T as a liaison 523 and as an email to the ahtmplstp mailing list. No response to 524 this liaison is expected. 526 Each time an MPLS-TP document under working group control is 527 revised a note SHOULD be sent to the Ad Hoc Team on MPLS-TP 528 mailing list, and a liaison MAY be sent to the ITU-T to inform 529 them of the progress of the document. No response to these 530 liaisons is expected. 532 The IETF working group MAY solicit input from the ITU-T at any 533 time. 535 10. At any time, it is possible for ITU-T participants to send review 536 comments on any MPLS-TP document. Such comments SHOULD be sent as 537 comments to the MPLS-TP mailing list according to normal IETF 538 process. 540 Additionally, this step provides for communication from ITU-T 541 Study Groups or Questions (see Section 3.2). These communications 542 may be unsolicited or in response to a request from the IETF 543 (step 8), and MAY be informal information exchanges or formal 544 information exchanges (see Section 2.2). Such exchanges (informal 545 or formal) SHOULD be accompanied by an email to the MPLS-TP 546 mailing list from the ahtmplstp chairs. 548 The document editors and the working group SHOULD give due 549 consideration to the issues raised in the communications from the 550 ITU-T, and SHOULD attempt to make suitable changes to the MPLS-TP 551 document or MUST otherwise explain why no change is being made. 553 Formal information exchanges MUST receive a response if 554 requested. The IETF liaison to the ITU-T on MPLS is responsible 555 for ensuring that this step is completed. 557 11. Editors working group documents SHOULD solicit comments on the 558 MPLS-TP mailing list and on any appropriate IETF working group 559 mailing lists. Comments can also be received from the ITU-T as 560 described for step 9. 562 The authors SHOULD revise the documents according to comments 563 received from all sources. 565 Note that most comments that lead to updates of working group 566 documents are a result of spontaneous individual reviews and 567 comments from the individual participants in the MPLS-TP effort 568 according to normal IETF process. 570 12. When an MPLS-TP document is deemed mature enough, a working group 571 last call is initiated following normal IETF process. 573 13. When a working group last call is initiated for any MPLS-TP 574 document the following actions MUST be taken. 576 * A liaison containing a request for participation in the working 577 group last call MUST be sent to the appropriate ITU-T Study 578 Groups and Questions. 580 The ad hoc team on MPLS-TP is expected to verify that all the 581 Study Groups and Questions within the ITU-T that need to 582 respond to the working group last call are aware that it has 583 been issued. 585 * A notification that the working group last call is taking place 586 MUST be sent to the ahtmplstp mailing list and to the MPLS-TP 587 mailing list. 589 14. The ITU-T is REQUIRED to respond to the liaison in step 13 within 590 the time indicated in the liaison (see Section 3.3). This 591 deadline will usually be set according to the timeline of the 592 working group last call. 594 The ITU-T response MUST either include comments to be taken under 595 consideration by the working group along with other last call 596 comments, or provide a statement that the ITU-T has no comment. 597 The latter case SHALL be interpreted as ITU-T approval for the 598 publication of the document as an RFC. 600 The working group and document editors MUST fully address any 601 comments received from the ITU-T under this step either making 602 the requested changes, or discussing the changes with the ITU-T 603 to reach a consensus position on the MPLS-TP mailing list. 605 15. According to normal IETF process, if the last call comments are 606 substantial the document MUST be returned to the working group 607 for revision and discussion. This MAY necessitate further 608 communication with the ITU-T (step 9) to clarify or resolve 609 issues raised during ITU-T review. 611 The working group last call MAY be repeated multiple times for 612 revisions of the document. As is normal IETF process, the working 613 group chairs MAY issue subsequent working group last calls for 614 the entire document or MAY be limited to only the updated text in 615 the document. In the latter case, further comments from within 616 the IETF or from the ITU-T SHOULD be limited as instructed by the 617 working group chair. 619 Note that, according to normal IETF process, if the last call 620 comments are minor, they SHOULD be addressed by the document 621 editors in coordination with the working group chairs and with 622 notification to the MPLS-TP mailing list. 624 16. When all last call comments have been addressed or responded to 625 and all necessary working group last calls have been held, the 626 working group chairs of the owning working group with assistance 627 of the MPLS-TP responsible working group chair will request 628 publication of the document as an RFC following normal IETF 629 process. 631 Once this request for publication is sent there is no further 632 scope for the ITU-T to influence the development of the document. 633 After this point, the document will be handled as any other IETF 634 document with individual comments made during IETF last call, and 635 with IESG review following. 637 Note that if these later stages in the publication process cause 638 significant changes to the document, it MAY be fully or partially 639 returned to the working group, in which case some form of WG last 640 call with ITU-T consultation MUST take place following from step 641 12 as outlined above. 643 2.4. Naming Conventions for MPLS-TP Documents 645 To make it easier to search in the IETF Internet-Draft repositories, 646 the following rules MUST be followed for naming the MPLS-TP Internet- 647 Draft. 649 o All MPLS-TP Internet-Draft MUST include the sequence "mpls-tp" 650 in the filename. 652 o Individual MPLS-TP Internet-Draft MUST be named according to 653 this format: 655 draft-name-mpls-tp-topic-??.txt 657 "name" is the last name of the main editor, or an acronym 658 indicating the last names of the set of editors. 660 "topic" indicates the content of the draft, e.g. "oam-framework". 662 "??" indicates a two digit version number, starting with "00". 664 o MPLS working group documents MUST be named as follows: 666 draft-ietf-mpls-tp-topic-??.txt 668 "topic" indicates the content of the draft, e.g. "oam-framework". 670 "??" indicates a two digit version number, starting with "00". 672 o MPLS-TP documents from other working groups MUST be named 673 according to this format: 675 draft-ietf-wgname-mpls-tp-topic-??.txt 677 "wgname" is the acronym for any working group chartered to do 678 MPLS-TP work, e.g. pwe3 or ccamp. 680 "topic" indicates the content of the draft, e.g. "oam-framework". 682 "??" indicates a two digit version number, starting with "00". 684 3. Expectations on ITU-T Participation in the Process 686 The IETF looks for input from the ITU-T at three key points in the 687 process described in Section 2. 689 o Steps 4 and 5 : Review of MEAD Team Documents 690 o Steps 9 and 10 : Review of Working Group Documents 692 o Steps 13 and 14 : Working Group Last Call and Document Approval 694 This section briefly describes what the IETF expects to happen on the 695 ITU-T side at these interaction points. 697 3.1. MEAD Team Document Review 699 The ITU-T may provide input to documents that are being developed by 700 the MEAD team. These documents are individual Internet-Drafts (that 701 is, they have not been adopted by a working group), but they form 702 part of the formal IETF MPLS-TP effort and are open for informal and 703 formal comment by the ITU-T and its participants. 705 As shown by step 4 in the process described in Section 2, the IETF 706 will notify the ITU-T of the existence of such documents and will 707 normally inform the ITU-T of new revisions. The ITU-T is not 708 required to respond to these communications. 710 The IETF may also request review or discussion of MEAD team 711 documents. The ITU-T is required to respond to this type of 712 communication if it is a formal liaison (step 5) within the deadline 713 set by the liaison (see Section 3.4). In this case, it should either 714 send a liaison response with comments and questions, or it should 715 acknowledge the liaison from the IETF saying that there are no 716 questions or comments at this time. The latter type of response will 717 not be taken by the IETF to imply any form of support for the 718 document unless it is explicitly expressed. 720 Additionally, the ITU-T may send unsolicited communications on a MEAD 721 team document as either informal or formal communications (step 5). 722 Formal communications may request a response from the IETF. 724 However, ITU-T participants are encouraged to bring their comments 725 and questions to the MPLS-TP mailing list directly, because this will 726 be more efficient and conforms to the normal IETF process. Comments 727 received in this way will be given full consideration by the MEAD 728 team and the document authors. 730 3.2. Working Group Document Review 732 The ITU-T may provide input to documents that are being developed by 733 IETF working groups. They are open for informal and formal comment by 734 the ITU-T and its participants. 736 As shown by step 9 in the process described in Section 2, the IETF 737 will notify the ITU-T of the existence of such documents and will 738 normally inform the ITU-T of new revisions. The ITU-T is not 739 required to respond to these communications. 741 The IETF may also request review or discussion of working group 742 documents. The ITU-T is required to respond to this type of 743 communication if it is a formal liaison (step 10) within the deadline 744 set by the liaison (see Section 3.4). In this case, it should either 745 send a liaison response with comments and questions, or it should 746 acknowledge the liaison from the IETF saying that there are no 747 questions or comments at this time. The latter type of response will 748 not be taken by the IETF to imply any form of support for the 749 document unless it is explicitly expressed. 751 Additionally, the ITU-T may send unsolicited communications on a 752 working group document as either informal or formal communications 753 (step 5). Formal communications may request a response from the IETF. 755 However, ITU-T participants are encouraged to bring their comments 756 and questions to the MPLS-TP mailing list directly, because this will 757 be more efficient and conforms to the normal IETF process. Comments 758 received in this way will be treated in the same way any as other 759 individual comments received on IETF documents. 761 3.3. Working Group Last Call and Document Approval 763 A working group last call is issued when a working group document is 764 close to being ready for publication as an RFC. The intention is to 765 make sure that there are no important pieces missing, that technical 766 details are correct, and that there is consensus within the working 767 group for moving forward. Consensus for MPLS-TP documents is judged 768 on the designated mailing list (normally the MPLS-TP mailing list) by 769 the chairs of the working group that has developed the document in 770 association with the MPLS-TP responsible working group chair. 772 During working group last call for all MPLS-TP documents the ITU-T 773 will always be consulted about the content of the documents. The 774 purpose of this step (step 13) is to ensure that the documents 775 address the needs and requirements of the ITU-T participants. 777 A formal communication will be made to the ITU-T to make it aware 778 that an IETF working group last call has been started and requesting 779 review and comment. According to the JWT decision, the ITU-T is 780 required to respond to a liaison about a working group last call 781 within the time set in announcing the working group last call. ITU-T 782 participants need to be aware that this step in the process 783 represents their last chance to influence the document from within 784 the ITU-T, and the liaison response needs to contain all issues and 785 comments - there will not be any scope to raise further concerns at a 786 later date. 788 The chair of an IETF working group that starts a working group last 789 call will send a liaison to the ITU-T announcing the working group 790 last call. A message will also be sent to the MPLS-TP ad hoc team. 792 The IETF will make a best effort attempt to target the ITU-T Study 793 Groups and Questions that should be involved in responding to the 794 working group last call. However, the ITU-T must make sure that the 795 appropriate entities within the ITU-T participate in responding to 796 the working group last call. The ITU-T ad hoc team on MPLS-TP 797 coordinates the development of the ITU-T response to the working 798 group last call. 800 The response to a working group last call should be unambiguous and 801 as detailed as possible. The liaison response is not intended to 802 start a conversation for clarification. It is intended to make clear 803 statements of technical issues to be addressed and to propose 804 resolutions for those issues. Acceptable responses include: 806 o No issues found. The ITU-T approves publication of the Internet- 807 Draft as an RFC in its current form. 809 o Minor issues found or questions raised. Please consider fixes to 810 these issues or respond to these questions before publication of 811 the Internet-Draft as an RFC. 813 o Major issues found. Please address these issues and allow the 814 ITU-T to review the resolution (possibly during a further working 815 group last call) before proceeding to publication of the Internet- 816 Draft as an RFC. 818 Note that, as described in Section 1.2, the cooperation process is 819 designed to ensure constructive consideration and resolution of all 820 issues raised by the ITU-T without being blocking on the progress of 821 the IETF's work on MPLS-TP. It is expected that discussion of major 822 issues raised at this stage of the process will be conducted on the 823 MPLS-TP mailing list and through appropriate communication with the 824 ITU-T. It is further expected that such issues will be resolved 825 through technical evaluation and rough consensus judged as normal for 826 the IETF process. In the event that agreement between the IETF and 827 ITU-T cannot be reached on some technical point, the JWT will be 828 convened to seek a resolution. 830 3.4. Non-Response to Liaisons 832 The liaison relationship between the IETF and the ITU-T is founded on 833 the understanding that each party will respond in a timely and 834 appropriate manner to the other party's liaisons so long as 835 reasonable notice is given. 837 Failure to respond by a deadline properly expressed in a liaison must 838 not be used to cause deadlock or to block advancement of work. Such 839 failures shall be assumed to represent accidental errors or 840 oversights and shall be brought to the attention of the management of 841 the body that has failed to respond. 843 In extreme cases, the JWT is empowered to convene to resolve issues 844 of failed communications. 846 4. Guidelines For MPLS-TP work in the ITU-T 848 These guidelines apply to progressing work on MPLS-TP in the ITU-T. 850 Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T 851 Study Group or Question. 853 Before the ITU-T initiates any new work (i.e. items not previously 854 identified by the JWT) based on such contributions the ITU-T shall 855 send a liaison to the IETF. The message will go to the IETF 856 liaison to the ITU-T on MPLS, the MPLS-TP responsible working 857 group chair and the MPLS-TP responsible AD. They are responsible 858 for sending a consolidated response from the IETF, but may 859 delegate the work of writing the response. 861 The IETF must respond to such liaisons according to the deadline 862 in the liaison. Acceptable responses include: 864 o Acknowledgement of receipt and agreement that the ITU-T is 865 clear to proceed with the work described. 867 o Request that the work described be transferred from the ITU-T to 868 the IETF in the form of an Internet-Draft to form part of the 869 MPLS-TP work in the IETF. 871 o Request that the work be put on hold until specific issues have 872 been resolved. In the event that this response is seen as 873 blocking of ITU-T work, the JWT may be convened to seek a 874 resolution. 876 Note that the process described in this section is conformant to the 877 Change Process for Multiprotocol Label Switching (MPLS) and 878 Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929]. 880 5. IANA Considerations 882 There are no requests for IANA allocation of code points in this 883 document. 885 6. Security Considerations 887 This document defines a process adaptation for the cooperation 888 between IETF and ITU-T and thus does not introduce any new security 889 considerations. 891 The successful development of MPLS-TP standards that are consistent 892 across the industry is an essential component to ensuring the 893 security and stability of MPLS networks. 895 7. Acknowledgments 897 Thanks to Eric Gray who helped with grammar and useful comments. 898 Thanks to Tom Petch who spent time trying to sort out what the 899 document said, and who sent comments that helped clarify the 900 document. 902 8. References 904 8.1. Normative References 906 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 907 3", BCP 9, RFC 2026, October 1996. 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, March 1997. 912 8.2. Informative References 914 [RFC4052] Daigle, L., Ed., and Internet Architecture Board, "IAB 915 Processes for Management of IETF Liaison Relationships", 916 BCP 102, RFC 4052, April 2005. 918 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 919 Handling Liaison Statements to and from the IETF", BCP 920 103, RFC 4053, April 2005. 922 [RFC4677] Hoffman, P. and Harris, S., "The Tao of IETF: A Novice's 923 Guide to the Internet Engineering Task Force", RFC 4677, 924 September 2006. 926 [RFC4929] Andersson, L. and Farrel, A., "Change Process for 927 Multiprotocol Label Switching (MPLS) and Generalized MPLS 928 (GMPLS) Protocols and Procedures", BCP 129, RFC4929, June 929 2007. 931 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 932 Report on MPLS Architectural Considerations for a 933 Transport Profile", RFC 5317, February 2009. 935 Authors' Addresses 937 Loa Andersson 938 Ericsson Inc 940 Email: loa.andersson@ericsson.com 942 David Ward 943 Cisco Systems 945 Email: dward@cisco.com 947 Malcolm Betts 948 Huawei 950 Email: malcolm.betts@huawei.com 952 Adrian Farrel 953 Huawei 955 Email: adrian.farrel@huawei.com 957