idnits 2.17.1 draft-ietf-mpls-tp-process-02.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 19, 2009) is 5332 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Ericsson Inc 4 Intended status: BCP D. Ward 5 Expires: March 19, 2010 Cisco Systems 6 M. Betts 7 A. Farrel 8 Huawei 9 September 19, 2009 11 IETF Multi-Protocol Label Switching (MPLS) 12 Transport Profile (MPLS-TP) Document Process 14 draft-ietf-mpls-tp-process-02.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 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 The decision to develop a Multiprotocol Label Switching (MPLS) 51 Transport Profile (MPLS-TP) in cooperation between the IETF and the 52 ITU-T is document in RFC 5317 as the decision of the Joint Working 53 Team on MPLS-TP. 55 This document provides additional detail of the processes for the 56 development of IETF RFCs on MPLS-TP. It provides an adaptation of the 57 IETF working group process; identifies the expected participation in 58 the process by the ITU-T; and clarifies the rules and conventions 59 regarding MPLS-TP documents. 61 This document doe not specify any ITU-T process; ITU-T activities 62 will be done according to ITU-T process/rules. 64 This document does not specify or modify the normal IETF working 65 group process. It is limited to the specific adaptations of that 66 process to facilitate the cooperation agreement between the IETF and 67 the ITU-T on MPLS-TP, and to ensure a good and consistent document 68 review across the two organizations. 70 Table of Contents 72 1. Introduction .................................................. 4 73 1.1. Terminology ............................................... 4 74 1.1.1. IETF Terms and Abbreviations .......................... 4 75 1.1.2. ITU-T Terms and Abbreviations ......................... 6 76 1.2. Purpose and Intent of Cooperation on MPLS-TP .............. 6 77 2. Adaptation of the IETF Working Group Process .................. 8 78 2.1. IETF Consensus and Mailing Lists .......................... 8 79 2.2. Communications with the ITU-T ............................. 9 80 2.3. Adapted IETF Working Group Process ........................ 9 81 2.3.1. Flow Chart ............................................ 9 82 2.3.2. The IETF MPLS-TP Process ............................. 11 83 2.4. Naming Conventions for MPLS-TP Documents ................. 16 84 3. Expectations on ITU-T Participation in the Process ........... 16 85 3.1. MEAD Team Document Review ................................ 17 86 3.2. Working Group Document Review ............................ 17 87 3.3. Working Group Last Call and Document Approval ............ 18 88 3.4. Non-Response to Liaisons ................................. 19 89 4. Guidelines For MPLS-TP work in the ITU-T ..................... 20 90 5. IANA Considerations .......................................... 21 91 6. Security Considerations ...................................... 21 92 7. Acknowledgments .............................................. 21 93 8. References ................................................... 21 94 8.1. Normative References ..................................... 21 95 8.2. Informative References ................................... 21 96 Authors' Addresses .............................................. 22 98 1. Introduction 100 The IETF and ITU-T have entered into an agreement to develop the 101 Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP). 102 This agreement is known as the Joint Working Team on MPLS-TP (JWT) 103 Agreement and is documented in [RFC5317]. The agreement states that 104 MPLS-TP will be documented in IETF RFCs, and assumes that there will 105 be close cooperation with the ITU-T in reviewing these RFCs. 107 This document provides additional detail of the processes for the 108 development of IETF RFCs on MPLS-TP as follows. 110 o It Provides an adaptation of the IETF working group process, with 111 respect to the how the IETF will take input from the ITU-T on 112 MPLS-TP topics. 114 o It identifies the expected participation by the ITU-T in the 115 document development process, noting that the ITU-T has committed 116 to responding promptly to IETF working group last calls in a way 117 that may require the ITU-T to develop responses via 118 correspondence. 120 o It clarifies the rules regarding MPLS-TP documents. 122 This document does not specify or modify the normal IETF working 123 group process. It is limited to the specific adaptations of that 124 process to facilitate the cooperation agreement between the IETF and 125 the ITU-T on MPLS-TP, and to ensure a good and consistent document 126 review across the two organizations. 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 Although this document is not a protocol specification, this language 132 is used for clarity and decisiveness. 134 1.1. Terminology 136 This section includes a number of terms and abbreviations that are 137 used in this document. The section is split into two subsection: 138 IETF terms and ITU-T terms. 140 1.1.1. IETF Terms and Abbreviations 142 o JWT - Joint Working Team, a team with participants with experience 143 from standards development in the IETF and the ITU-T. 145 Note: The JWT is not part of either the IETF or ITU-T, but a group 146 that has been set up to facilitate cooperation on MPLS-TP between 147 the two organizations. 149 o JWT decision - A set of recommendations on the procedural approach 150 to the development of MPLS-TP made by the JWT and documented in 151 [RFC5317]. 153 o JWT agreement - The agreement between IETF and ITU-T based on the 154 JWT decision to jointly develop MPLS-TP according IETF processes. 156 o JWT documents - The set of documents envisioned in the JWT 157 decision [RFC5317]. 159 o MEAD team - MPLS Interoperability Design Team, a temporary team 160 with participants with experience from standards development for 161 MPLS and transport networks. The MEAD team is chartered to 162 coordinate the development of MPLS-TP within the IETF and to 163 coordinate the MPLS-TP cooperation with the ITU-T. 165 o MPLS-TP documents - The following sets of documents are counted as 166 MPLS-TP documents: 168 * Internet-Drafts that are coordinated by the MEAD team. 170 * Individual Internet-Drafts that addresses the MPLS-TP problem 171 space. 173 * Working group Internet-Drafts that addresses the MPLS-TP 174 problem space. 176 * Internet-Drafts that are considered for publication as RFCs by 177 the IESG and that addresses the MPLS-TP problem space. 179 * Internet-Drafts that are approved for publication as RFCs by 180 the IESG and that addresses the MPLS-TP problem space. 182 * Published RFCs that addresses the MPLS-TP problem space. 184 * ITU-T Recommendations and draft Recommendations in various 185 stages of development that address the MPLS-TP problem space. 187 Documents that originate from the IRTF RFC stream are NOT 188 considered as MPLS-TP documents. 190 o MPLS-TP mailing list - An IETF mailing list (mpls-tp@ietf.org) 191 established specifically for the discussion of MPLS-TP issues 192 within the IETF. The MPLS-TP list is the mailing list that is used 193 decide consensus on MPLS-TP issues. This is an open mailing list 194 with publicly available archives. 196 o MPLS-TP responsible working group chair - An IETF MPLS working 197 group chair assigned responsibility for the IETF MPLS-TP effort 198 by the IETF Routing Area Directors. 200 o MPLS-TP responsible AD - An IETF Routing Area Director with 201 management responsibility for the MPLS-TP effort. 203 o IETF liaison to the ITU-T on MPLS - An individual assigned 204 responsibility by the IAB for managing the liaison relationship 205 to the ITU-T in regard of all issues concerning MPLS, including 206 MPLS-TP. 208 o Contribution - Within the IETF, a contribution is any submission 209 to the IETF intended by the Contributor for publication as all or 210 part of an Internet-Draft or RFC, and any statement made within 211 the context of an IETF activity. Such statements include oral 212 statements in IETF sessions as well as written and electronic 213 communications. For more information on the IETF definition of a 214 contribution see [RFC5378]. 216 1.1.2. ITU-T Terms and Abbreviations 218 o Ad Hoc Team on MPLS-TP (ahtmplstp) - A team established by Study 219 Group 15 of the ITU-T to coordinate the work on MPLS-TP within the 220 ITU-T and to act as a focal point for communication with the IETF 221 about MPLS-TP. 223 o Ad Hoc Team on MPLS-TP mailing list - An ITU-T mail exploder 224 (ahmpls-tp@lists.itu.int) established specifically for the 225 discussion and coordination of the MPLS-TP effort within the 226 ITU-T. 228 o Contribution - Within the ITU-T, a contribution is a document that 229 is submitted to the ITU-T to advance work on the development of a 230 Recommendation or to propose the development of a new 231 Recommendation. 233 o Recommendation - A Recommendation is an ITU-T standards document. 235 1.2. Purpose and Intent of Cooperation on MPLS-TP 237 The purpose and objectives of the development activity on MPLS-TP is 238 described in [RFC5317]. The JWT decision includes the recognition 239 that the design authority for MPLS (including MPLS-TP) is the IETF. 240 At the same time, the JWT decision recognises the role of the ITU-T 241 in providing input (especially input to the requirements statements) 242 to the development process for MPLS-TP. There is also a clear 243 statement of expectation that the ITU-T's opinions will be heard 244 within the IETF and must be properly considered during the 245 development of MPLS-TP documents. 247 The development of standards for MPLS-TP is, therefore, carried out 248 within the IETF according to IETF process and with strong input from 249 the ITU-T. This input takes three forms (see also Section 2.2): 251 o Active participation. 253 All interested parties are encouraged to participate in the 254 development of MPLS-TP standards within the IETF through the 255 normal IETF process. In short, this involves the generation and 256 documentation of new ideas as Internet-Drafts, and the discussion 257 of work in progress through the IETF mailing lists. The IETF is 258 not a membership organisation, and the mailing lists are open. 260 o Informal communication. 262 It is recognised that discussions about MPLS-TP will take place 263 within the Questions and Study Groups of the ITU-T. In order to 264 speed up the development process and ensure smooth communications, 265 the ITU-T is requested to make informal (i.e., email) 266 communications to the IETF whenever any issues or questions 267 arise. Informal communication can be sent by any individual or 268 rapporteur of a Question as an email to the MPLS-TP mailing list. 269 The chairs of the ahtmplstp may also summarise discussions within 270 the ITU-T (especially those on the ahtmplstp mailing list) and 271 communicate them to the IETF via email. 273 o Formal communication. 275 The formal liaison process with the IETF is described in [RFC4052] 276 and [RFC4053]. The process will be used for ensuring that specific 277 progress steps are check-pointed and recorded, and for making sure 278 that appropriate responses are generated in a timely manner. 280 The objective of cooperation between the IETF and ITU-T is to ensure 281 full participation of interested parties to make sure that all 282 opinions are heard with the intention of producing sound and stable 283 MPLS-TP documentation. It is understood that the neither the IETF nor 284 the ITU-T should be in a position to block the work of the other body 285 within its areas of authority. In the context of this document, this 286 means that the ITU-T must not block IETF work on MPLS-TP against the 287 IETF consensus view. 289 Part of this process must be the understanding that all IETF 290 documentation (including RFCs) can be revised or extended according 291 to normal IETF procedures. Therefore, it is not a requirement that 292 the first version of any RFC be perfect for all time (we do not need 293 to "boil the ocean"); the initial aim of the work is to provide 294 documentation of MPLS-TP as it is initially developed and deployed. 296 Fundamental to understanding the process described in the rest of 297 this document and to participating in the MPLS-TP development process 298 is a working knowledge of the procedures of the IETF. Readers needing 299 clarification of the IETF procedures are invited to read [RFC2026], 300 [RFC4677], and [RFC4929]. Further clarification and guidance can be 301 obtained from the MPLS-TP responsible working group chair, the MPLS- 302 TP responsible AD, and the IETF liaison to the ITU-T on MPLS. 304 The ITU-T may also develop Recommendations to document MPLS-TP. The 305 JWT decision recognises that these Recommendations must not contain 306 normative definitions of MPLS-TP (these are captured solely in IETF 307 RFCs). Recommendations on MPLS-TP will be provided for review by the 308 IETF to ensure conformance with the previous point and to verify that 309 the material is consistent across MPLS-TP. The process for producing 310 and reviewing Recommendations is out of scope for this document. 312 2. Adaptation of the IETF Working Group Process 314 The IETF working group processes as defined in RFC 2026 [RFC2026] are 315 adapted as described in this section solely for the purpose of the 316 MPLS-TP work. These adaptations do not apply to any other topic or 317 work within the IETF. 319 2.1. IETF Consensus and Mailing Lists 321 The IETF works according to a 'rough consensus' model, where working 322 group chairs determine the consensus after discussions on the mailing 323 lists. This is also applicable to the MPLS-TP work. The MPLS-TP 324 mailing list exists to focus all IETF discussions on MPLS-TP and to 325 avoid congesting other relevant working group mailing lists. All 326 technical discussion on MPLS-TP SHOULD be directed to the MPLS-TP 327 list, but other working group mailing lists SHOULD be notified when 328 appropriate so that individuals can participate in the discussions on 329 the MPLS-TP list. 331 Consensus activities (such as a working group last call) MUST be 332 started on an working group mailing list, but the MPLS-TP responsible 333 working group chair MAY direct discussions to the MPLS-TP list and 334 MAY direct that consensus will be judged on that list. 336 2.2. Communications with the ITU-T 338 A most important part of this process is the information exchange 339 between the IETF and ITU-T. This information exchange consists of 340 two equally important pieces. 342 o Informal information exchange 344 This is done primarily by e-mail to the relevant mailing lists. 345 Information sent to the ITU-T MUST be sent to the Ad Hoc MPLS-TP 346 mailing list. Information sent to the IETF MUST be sent to the 347 MPLS-TP mailing list. 349 o Formal information exchange 351 In addition to the informal information exchange, a formal 352 information exchange is accomplished by liaison correspondence 353 between the two organisations. Exchange of liaisons makes it 354 possible to follow the request/response exchange between the 355 organisations in more detail, and to obtain an official view of 356 each organisation's position on any topic. 358 2.3. Adapted IETF Working Group Process 360 2.3.1. Flow Chart 362 The flow chart below describes the adaption of the working group 363 process. The flow chart and the process as described in Section 2.3.2 364 are equally normative. 366 ............. ............. 367 : Ind Docs :--------+ : JWT docs : 368 ............. | ............. 369 | | | 370 |(1) |(2) |(3) 371 | | | 372 v | v 373 +-----------+ | +----------------+ (4) +-------+ 374 +--->| WG proc | +----->| MEAD team proc |------>| ITU-T | 375 | | |-------+ +--| | +-------+ 376 | +-----------+ | | +----------------+ | 377 | ind-00, ind-01, etc | | ^ ind-00, ind-01, etc |(5) 378 | |(6) +--+---+ | |(6) | 379 +----------+ |(7) +-------+<-----------------+ 380 review | review 381 v 382 +-----------------+ 383 | poll for wg doc | 384 +-----------------+ 385 |(8) 386 | 387 v 388 +-------------+ (9) +-------+ 389 +----------->| wg doc |------------->| ITU-T | 390 | +-------------+ +-------+ 391 | | ^ wg-00, wg-01, etc | 392 | | | |(11) |(10) 393 (15)| (12)| +------+<------------------+ 394 | | review 395 | v 396 | +-----------------+ 397 +-----| wg last call | 398 +-----------------+ 399 | ^ | 400 (13)| |(14) |(16) 401 v | | 402 +---------+ | 403 | ITU-T | | 404 +---------+ | 405 v 406 +---------------+ 407 | req for pub | 408 +---------------+ 410 2.3.2. The IETF MPLS-TP Process 412 This section describes the development for MPLS-TP documents. It sets 413 out the process that is illustrated by the flow chart in Section 414 2.3.1. The numbered arrows in the flow chart are described as 415 numbered steps in the process in the list below. 417 Individual MPLS-TP documents can take different paths through the 418 this process. Although the different paths through the flow chart are 419 given as options, it is always possible a particular MPLS-TP 420 Internet-Draft to be adopted as a working group draft. This is done 421 on the guidance of the MPLS-TP responsible working group chair and in 422 cooperation with the relevant working group chairs and the document 423 editors/authors. 425 1. Independent Documents through Working Group Processing 427 Internet-Drafts MAY be introduced by their authors to describe 428 any aspect of MPLS-TP. This option (compare with step 2) results 429 in the document being discussed and reviewed by the appropriate 430 IETF working group as determined by the working group chairs. The 431 normal IETF process will be applied, and the authors will revise 432 the document (step 6) until it is adopted as a working group 433 draft (see step 7). 435 Any individual or group of individuals can create an Internet- 436 Draft through this step. 438 2. Independent Documents through MEAD Team Coordination 440 Internet-Drafts MAY be brought to the MEAD team or initiated by 441 the MEAD team. The MEAD team is responsible for discussing, 442 reviewing, and revising (step 6) the documents as independent 443 drafts. The MEAD team will solicit input from the ITU-T (step 4) 444 and will publicise the documents on the MPLS-TP mailing list to 445 encourage input from the IETF community. Normal IETF design team 446 process will apply until the document is adopted as a working 447 group draft (see step 7). 449 Any individual or group of individuals can create an Internet- 450 Draft through this step. However, the MEAD team MAY decide that 451 it is unwilling to support the document. In this case, the 452 authors MAY bring the document in following step 1. 454 3. Joint Working Team Originated Documents 456 The JWT MAY initiate MPLS-TP documents, or request that the MEAD 457 team create specific documents. The MEAD team MUST process these 458 as independent submissions as described in step 2. 460 [RFC5317] includes a list of JWT documents that MUST be 461 considered by the MEAD team to be processed on this step, but the 462 MEAD team MAY vary this list if, for example, it becomes more 463 appropriate to split a single document into two or more, or if 464 some new aspect of MPLS-TP needs to be specified. 466 4. Every time a document is accepted by the MEAD team into the set 467 of documents coordinated by the MEAD team a liaison MUST be sent 468 to the ITU-T with a pointer to that document. At the same time a 469 note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list 470 informing the list that the document has become a MEAD team 471 document. 473 Each time a document coordinated by the MEAD team is revised a 474 note SHOULD be sent to the Ad Hoc Team on MPLS-TP mailing list, 475 and a liaison MAY be sent to the ITU-T to inform them of the 476 progress of the document. 478 The ITU-T MAY respond to these liaisons (step 5), but a response 479 is not required (see Section 3 and Section 4). 481 5. At any time, it is possible for ITU-T participants to send review 482 comments on any MPLS-TP document. Such comments SHOULD be sent as 483 comments to the MPLS-TP mailing list according to normal IETF 484 process. 486 Additionally, this step provides for communication from ITU-T 487 Study Groups or Questions. These communications may be 488 unsolicited or in response to a request from the IETF (step 4), 489 and MAY be informal information exchanges or formal information 490 exchanges (see Section 2.2). Such exchanges (informal or formal) 491 SHOULD be accompanied by an email to the MPLS-TP mailing list 492 from the ahtmplstp chair. 494 The MEAD team SHOULD give due consideration to the issues raised 495 in the communications received ITU-T, and SHOULD attempt to make 496 suitable changes to the MPLS-TP document or MUST otherwise 497 explain why no change is being made. 499 Formal information exchanges MUST receive a response if 500 requested. The IETF liaison to the ITU-T on MPLS and the 501 addressees of the liaison are responsible for ensuring that this 502 step is completed. 504 6. Authors of independent documents SHOULD solicit comments on the 505 MPLS-TP mailing list and on any appropriate IETF working group 506 mailing lists. Comments can also be received from the ITU-T as 507 described for step 5. 509 The authors SHOULD revise the documents according to comments 510 received from all sources, or explain why no changes been made. 512 7. If an MPLS-TP document seems mature enough to become a working 513 group document, a poll is done on the MPLS-TP mailing list and 514 the appropriate working group mailing list to determine whether 515 there is consensus to adopt the document as a working group 516 document. 518 Which working group a document goes into is decided jointly by 519 the MPLS-TP responsible working group chair and the chairs of the 520 target working group. 522 8. If the document is accepted as a working group document the 523 working group takes over the revision control of the document. 524 Normal IETF working group process SHALL apply. All IETF 525 discussions about the document MUST now be held on the MPLS-TP 526 mailing list with notifications sent to the relevant IETF working 527 group mailing list. 529 9. When a document is accepted as a working group document 530 informational notification MUST be sent to the ITU-T as a liaison 531 and as an email to the ahtmplstp mailing list. No response to 532 this liaison is expected. 534 Each time an MPLS-TP document under working group control is 535 revised a note SHOULD be sent to the Ad Hoc Team on MPLS-TP 536 mailing list, and a liaison MAY be sent to the ITU-T to inform 537 them of the progress of the document. No response to these 538 liaisons is expected. 540 The IETF working group MAY solicit input from the ITU-T at any 541 time. 543 10. At any time, it is possible for ITU-T participants to send review 544 comments on any MPLS-TP document. Such comments SHOULD be sent as 545 comments to the MPLS-TP mailing list according to normal IETF 546 process. 548 Additionally, this step provides for communication from ITU-T 549 Study Groups or Questions (see Section 3.2). These communications 550 may be unsolicited or in response to a request from the IETF 551 (step 8), and MAY be informal information exchanges or formal 552 information exchanges (see Section 2.2). Such exchanges (informal 553 or formal) SHOULD be accompanied by an email to the MPLS-TP 554 mailing list from the ahtmplstp chairs. 556 The document editors and the working group SHOULD give due 557 consideration to the issues raised in the communications from the 558 ITU-T, and SHOULD attempt to make suitable changes to the MPLS-TP 559 document or MUST otherwise explain why no change is being made. 561 Formal information exchanges MUST receive a response if 562 requested. The IETF liaison to the ITU-T on MPLS is responsible 563 for ensuring that this step is completed. 565 11. Editors working group documents SHOULD solicit comments on the 566 MPLS-TP mailing list and on any appropriate IETF working group 567 mailing lists. Comments can also be received from the ITU-T as 568 described for step 9. 570 The authors SHOULD revise the documents according to comments 571 received from all sources. 573 Note that most comments that lead to updates of working group 574 documents are a result of spontaneous individual reviews and 575 comments from the individual participants in the MPLS-TP effort 576 according to normal IETF process. 578 12. When an MPLS-TP document is deemed mature enough, a working group 579 last call is initiated following normal IETF process. 581 13. When a working group last call is initiated for any MPLS-TP 582 document the following actions MUST be taken. 584 * A liaison containing a request for participation in the working 585 group last call MUST be sent to the appropriate ITU-T Study 586 Groups and Questions. 588 The ad hoc team on MPLS-TP is expected to verify that all the 589 Study Groups and Questions within the ITU-T that need to 590 respond to the working group last call are aware that it has 591 been issued. 593 * A notification that the working group last call is taking place 594 MUST be sent to the ahtmplstp mailing list and to the MPLS-TP 595 mailing list. 597 14. The ITU-T is REQUIRED to respond to the liaison in step 13 within 598 the time indicated in the liaison (see Section 3.3). This 599 deadline will usually be set according to the timeline of the 600 working group last call. 602 The ITU-T response MUST either include comments to be taken under 603 consideration by the working group along with other last call 604 comments, or provide a statement that the ITU-T has no comment. 605 The latter case SHALL be interpreted as ITU-T approval for the 606 publication of the document as an RFC. 608 The working group and document editors MUST fully address any 609 comments received from the ITU-T under this step either making 610 the requested changes, or discussing the changes with the ITU-T 611 to reach a consensus position on the MPLS-TP mailing list. 613 15. According to normal IETF process, if the last call comments are 614 substantial the document MUST be returned to the working group 615 for revision and discussion. This MAY necessitate further 616 communication with the ITU-T (step 9) to clarify or resolve 617 issues raised during ITU-T review. 619 The working group last call MAY be repeated multiple times for 620 revisions of the document. As is normal IETF process, the working 621 group chairs MAY issue subsequent working group last calls for 622 the entire document or MAY be limited to only the updated text in 623 the document. In the latter case, further comments from within 624 the IETF or from the ITU-T SHOULD be limited as instructed by the 625 working group chair. 627 Note that, according to normal IETF process, if the last call 628 comments are minor, they SHOULD be addressed by the document 629 editors in coordination with the working group chairs and with 630 notification to the MPLS-TP mailing list. 632 16. When all last call comments have been addressed or responded to 633 and all necessary working group last calls have been held, the 634 working group chairs of the owning working group with assistance 635 of the MPLS-TP responsible working group chair will request 636 publication of the document as an RFC following normal IETF 637 process. 639 Once this request for publication is sent there is no further 640 scope for the ITU-T to influence the development of the document. 641 After this point, the document will be handled as any other IETF 642 document with individual comments made during IETF last call, and 643 with IESG review following. 645 Note that if these later stages in the publication process cause 646 significant changes to the document, it MAY be fully or partially 647 returned to the working group, in which case some form of WG last 648 call with ITU-T consultation MUST take place following from step 649 12 as outlined above. 651 2.4. Naming Conventions for MPLS-TP Documents 653 To make it easier to search in the IETF Internet-Draft repositories, 654 the following rules MUST be followed for naming the MPLS-TP Internet- 655 Draft. 657 o All MPLS-TP Internet-Draft MUST include the sequence "mpls-tp" 658 in the filename. 660 o Individual MPLS-TP Internet-Draft MUST be named according to 661 this format: 663 draft-name-mpls-tp-topic-??.txt 665 "name" is the last name of the main editor, or an acronym 666 indicating the last names of the set of editors. 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 working group documents MUST be named as follows: 674 draft-ietf-mpls-tp-topic-??.txt 676 "topic" indicates the content of the draft, e.g. "oam-framework". 678 "??" indicates a two digit version number, starting with "00". 680 o MPLS-TP documents from other working groups MUST be named 681 according to this format: 683 draft-ietf-wgname-mpls-tp-topic-??.txt 685 "wgname" is the acronym for any working group chartered to do 686 MPLS-TP work, e.g. pwe3 or ccamp. 688 "topic" indicates the content of the draft, e.g. "oam-framework". 690 "??" indicates a two digit version number, starting with "00". 692 3. Expectations on ITU-T Participation in the Process 694 The IETF looks for input from the ITU-T at three key points in the 695 process described in Section 2. 697 o Steps 4 and 5 : Review of MEAD Team Documents 698 o Steps 9 and 10 : Review of Working Group Documents 700 o Steps 13 and 14 : Working Group Last Call and Document Approval 702 This section briefly describes what the IETF expects to happen on the 703 ITU-T side at these interaction points. 705 3.1. MEAD Team Document Review 707 The ITU-T may provide input to documents that are being developed by 708 the MEAD team. These documents are individual Internet-Drafts (that 709 is, they have not been adopted by a working group), but they form 710 part of the formal IETF MPLS-TP effort and are open for informal and 711 formal comment by the ITU-T and its participants. 713 As shown by step 4 in the process described in Section 2, the IETF 714 will notify the ITU-T of the existence of such documents and will 715 normally inform the ITU-T of new revisions. The ITU-T is not 716 required to respond to these communications. 718 The IETF may also request review or discussion of MEAD team 719 documents. The ITU-T is required to respond to this type of 720 communication if it is a formal liaison (step 5) within the deadline 721 set by the liaison (see Section 3.4). In this case, it should either 722 send a liaison response with comments and questions, or it should 723 acknowledge the liaison from the IETF saying that there are no 724 questions or comments at this time. The latter type of response will 725 not be taken by the IETF to imply any form of support for the 726 document unless it is explicitly expressed. 728 Additionally, the ITU-T may send unsolicited communications on a MEAD 729 team document as either informal or formal communications (step 5). 730 Formal communications may request a response from the IETF. 732 However, ITU-T participants are encouraged to bring their comments 733 and questions to the MPLS-TP mailing list directly, because this will 734 be more efficient and conforms to the normal IETF process. Comments 735 received in this way will be given full consideration by the MEAD 736 team and the document authors. 738 3.2. Working Group Document Review 740 The ITU-T may provide input to documents that are being developed by 741 IETF working groups. They are open for informal and formal comment by 742 the ITU-T and its participants. 744 As shown by step 9 in the process described in Section 2, the IETF 745 will notify the ITU-T of the existence of such documents and will 746 normally inform the ITU-T of new revisions. The ITU-T is not 747 required to respond to these communications. 749 The IETF may also request review or discussion of working group 750 documents. The ITU-T is required to respond to this type of 751 communication if it is a formal liaison (step 10) within the deadline 752 set by the liaison (see Section 3.4). In this case, it should either 753 send a liaison response with comments and questions, or it should 754 acknowledge the liaison from the IETF saying that there are no 755 questions or comments at this time. The latter type of response will 756 not be taken by the IETF to imply any form of support for the 757 document unless it is explicitly expressed. 759 Additionally, the ITU-T may send unsolicited communications on a 760 working group document as either informal or formal communications 761 (step 5). Formal communications may request a response from the IETF. 763 However, ITU-T participants are encouraged to bring their comments 764 and questions to the MPLS-TP mailing list directly, because this will 765 be more efficient and conforms to the normal IETF process. Comments 766 received in this way will be treated in the same way any as other 767 individual comments received on IETF documents. 769 3.3. Working Group Last Call and Document Approval 771 A working group last call is issued when a working group document is 772 close to being ready for publication as an RFC. The intention is to 773 make sure that there are no important pieces missing, that technical 774 details are correct, and that there is consensus within the working 775 group for moving forward. Consensus for MPLS-TP documents is judged 776 on the designated mailing list (normally the MPLS-TP mailing list) by 777 the chairs of the working group that has developed the document in 778 association with the MPLS-TP responsible working group chair. 780 During working group last call for all MPLS-TP documents the ITU-T 781 will always be consulted about the content of the documents. The 782 purpose of this step (step 13) is to ensure that the documents 783 address the needs and requirements of the ITU-T participants. 785 A formal communication will be made to the ITU-T to make it aware 786 that an IETF working group last call has been started and requesting 787 review and comment. According to the JWT decision, the ITU-T is 788 required to respond to a liaison about a working group last call 789 within the time set in announcing the working group last call. ITU-T 790 participants need to be aware that this step in the process 791 represents their last chance to influence the document from within 792 the ITU-T, and the liaison response needs to contain all issues and 793 comments - there will not be any scope to raise further concerns at a 794 later date. 796 The chair of an IETF working group that starts a working group last 797 call will send a liaison to the ITU-T announcing the working group 798 last call. A message will also be sent to the MPLS-TP ad hoc team. 800 The IETF will make a best effort attempt to target the ITU-T Study 801 Groups and Questions that should be involved in responding to the 802 working group last call. However, the ITU-T must make sure that the 803 appropriate entities within the ITU-T participate in responding to 804 the working group last call. The ITU-T ad hoc team on MPLS-TP 805 coordinates the development of the ITU-T response to the working 806 group last call. 808 The response to a working group last call should be unambiguous and 809 as detailed as possible. The liaison response is not intended to 810 start a conversation for clarification. It is intended to make clear 811 statements of technical issues to be addressed and to propose 812 resolutions for those issues. Acceptable responses include: 814 o No issues found. The ITU-T approves publication of the Internet- 815 Draft as an RFC in its current form. 817 o Minor issues found or questions raised. Please consider fixes to 818 these issues or respond to these questions before publication of 819 the Internet-Draft as an RFC. 821 o Major issues found. Please address these issues and allow the 822 ITU-T to review the resolution (possibly during a further working 823 group last call) before proceeding to publication of the Internet- 824 Draft as an RFC. 826 Note that, as described in Section 1.2, the cooperation process is 827 designed to ensure constructive consideration and resolution of all 828 issues raised by the ITU-T without being blocking on the progress of 829 the IETF's work on MPLS-TP. It is expected that discussion of major 830 issues raised at this stage of the process will be conducted on the 831 MPLS-TP mailing list and through appropriate communication with the 832 ITU-T. It is further expected that such issues will be resolved 833 through technical evaluation and rough consensus judged as normal for 834 the IETF process. In the event that agreement between the IETF and 835 ITU-T cannot be reached on some technical point, the JWT will be 836 convened to seek a resolution. 838 3.4. Non-Response to Liaisons 840 The liaison relationship between the IETF and the ITU-T is founded on 841 the understanding that each party will respond in a timely and 842 appropriate manner to the other party's liaisons so long as 843 reasonable notice is given. 845 Failure to respond by a deadline properly expressed in a liaison must 846 not be used to cause deadlock or to block advancement of work. Such 847 failures shall be assumed to represent accidental errors or 848 oversights and shall be brought to the attention of the management of 849 the body that has failed to respond. 851 In extreme cases, the JWT is empowered to convene to resolve issues 852 of failed communications. 854 4. Guidelines For MPLS-TP work in the ITU-T 856 These guidelines apply to progressing work on MPLS-TP in the ITU-T. 858 Any member of the ITU-T may send a MPLS-TP contribution to a ITU-T 859 Study Group or Question. 861 Before the ITU-T initiates any new work (i.e. items not previously 862 identified by the JWT) based on such contributions the ITU-T shall 863 send a liaison to the IETF. The message will go to the IETF 864 liaison to the ITU-T on MPLS, the MPLS-TP responsible working 865 group chair and the MPLS-TP responsible AD. They are responsible 866 for sending a consolidated response from the IETF, but may 867 delegate the work of writing the response. 869 The IETF must respond to such liaisons according to the deadline 870 in the liaison. Acceptable responses include: 872 o Acknowledgement of receipt and agreement that the ITU-T is 873 clear to proceed with the work described. 875 o Request that the work described be transferred from the ITU-T to 876 the IETF in the form of an Internet-Draft to form part of the 877 MPLS-TP work in the IETF. 879 o Request that the work be put on hold until specific issues have 880 been resolved. In the event that this response is seen as 881 blocking of ITU-T work, the JWT may be convened to seek a 882 resolution. 884 Note that the process described in this section is conformant to the 885 Change Process for Multiprotocol Label Switching (MPLS) and 886 Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929]. 888 5. IANA Considerations 890 There are no requests for IANA allocation of code points in this 891 document. 893 6. Security Considerations 895 This document defines a process adaptation for the cooperation 896 between IETF and ITU-T and thus does not introduce any new security 897 considerations. 899 The successful development of MPLS-TP standards that are consistent 900 across the industry is an essential component to ensuring the 901 security and stability of MPLS networks. 903 7. Acknowledgments 905 Thanks to Eric Gray who helped with grammar and useful comments. 906 Thanks to Tom Petch who spent time trying to sort out what the 907 document said, and who sent comments that helped clarify the 908 document. 910 8. References 912 8.1. Normative References 914 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 915 3", BCP 9, RFC 2026, October 1996. 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, March 1997. 920 8.2. Informative References 922 [RFC4052] Daigle, L., Ed., and Internet Architecture Board, "IAB 923 Processes for Management of IETF Liaison Relationships", 924 BCP 102, RFC 4052, April 2005. 926 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 927 Handling Liaison Statements to and from the IETF", BCP 928 103, RFC 4053, April 2005. 930 [RFC4677] Hoffman, P. and Harris, S., "The Tao of IETF: A Novice's 931 Guide to the Internet Engineering Task Force", RFC 4677, 932 September 2006. 934 [RFC4929] Andersson, L. and Farrel, A., "Change Process for 935 Multiprotocol Label Switching (MPLS) and Generalized MPLS 936 (GMPLS) Protocols and Procedures", BCP 129, RFC4929, June 937 2007. 939 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 940 Report on MPLS Architectural Considerations for a 941 Transport Profile", RFC 5317, February 2009. 943 [RFC5378] Bradner, S., and Contreras, J., "Rights Contributors 944 Provide to the IETF Trust", BCP 78, RFC 5378, November 945 2008. 947 Authors' Addresses 949 Loa Andersson 950 Ericsson Inc 952 Email: loa.andersson@ericsson.com 954 David Ward 955 Cisco Systems 957 Email: dward@cisco.com 959 Malcolm Betts 960 Huawei 962 Email: malcolm.betts@huawei.com 964 Adrian Farrel 965 Huawei 967 Email: adrian.farrel@huawei.com