idnits 2.17.1 draft-ietf-mpls-tp-process-03.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 (October 16, 2009) is 5300 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: April 16, 2010 Cisco Systems 6 M. Betts 7 A. Farrel 8 Huawei 9 October 16, 2009 11 IETF Multi-Protocol Label Switching (MPLS) 12 Transport Profile (MPLS-TP) Document Process 14 draft-ietf-mpls-tp-process-03.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 does 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 1.3. A Note on the MPLS-TP Interoperability Design Team ........ 8 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 ............................. 9 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 ........... 15 86 3.1. Working Group Document Review ............................ 16 87 3.2. Working Group Last Call and Document Approval ............ 16 88 3.3. Non-Response to Liaisons ................................. 19 89 4. Guidelines For MPLS-TP work in the ITU-T ..................... 19 90 5. IANA Considerations .......................................... 20 91 6. Security Considerations ...................................... 20 92 7. Acknowledgments .............................................. 20 93 8. References ................................................... 20 94 8.1. Normative References ..................................... 20 95 8.2. Informative References ................................... 20 96 Authors' Addresses .............................................. 21 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. This 106 cooperation will include review of the work at all stages of 107 drafting. 109 This document provides additional detail of the processes for the 110 development of IETF RFCs on MPLS-TP as follows. 112 o It Provides an adaptation of the IETF working group process, with 113 respect to how the IETF will take input from the ITU-T on MPLS-TP 114 topics. 116 o It identifies the expected participation by the ITU-T in the 117 document development process, noting that the ITU-T has committed 118 to responding promptly to IETF working group last calls in a way 119 that may require the ITU-T to develop responses via 120 correspondence. 122 o It clarifies the rules regarding MPLS-TP documents. 124 This document does not specify or modify the normal IETF working 125 group process. It is limited to the specific adaptations of that 126 process to facilitate the cooperation agreement between the IETF and 127 the ITU-T on MPLS-TP, and to ensure a good and consistent document 128 review across the two organizations. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 Although this document is not a protocol specification, this language 134 is used for clarity and decisiveness. 136 1.1. Terminology 138 This section includes a number of terms and abbreviations that are 139 used in this document. The section is split into two subsection: 140 IETF terms and ITU-T terms. 142 1.1.1. IETF Terms and Abbreviations 144 o JWT - Joint Working Team, a team with participants with experience 145 from standards development in the IETF and the ITU-T. 147 Note: The JWT is not part of either the IETF or ITU-T, but a group 148 that has been set up to facilitate cooperation on MPLS-TP between 149 the two organizations. 151 o JWT decision - A set of recommendations on the procedural approach 152 to the development of MPLS-TP made by the JWT and documented in 153 [RFC5317]. 155 o JWT agreement - The agreement between IETF and ITU-T based on the 156 JWT decision to jointly develop MPLS-TP according IETF processes. 158 o JWT documents - The set of documents envisioned in the JWT 159 decision [RFC5317]. 161 o MPLS-TP documents - The following sets of documents are counted as 162 MPLS-TP documents: 164 * Individual Internet-Drafts that address the MPLS-TP problem 165 space. 167 * Working group Internet-Drafts that address the MPLS-TP problem 168 space. 170 * Internet-Drafts that are considered for publication as RFCs by 171 the IESG and that address the MPLS-TP problem space. 173 * Internet-Drafts that are approved for publication as RFCs by 174 the IESG and that address the MPLS-TP problem space. 176 * Published RFCs that address the MPLS-TP problem space. 178 * ITU-T Recommendations and draft Recommendations in various 179 stages of development that address the MPLS-TP problem space. 181 Documents that originate from the IRTF RFC stream or the 182 Independent Submission Stream are not considered as MPLS-TP 183 documents. 185 o MPLS-TP mailing list - An IETF mailing list (mpls-tp@ietf.org) 186 established specifically for the discussion of MPLS-TP issues 187 within the IETF. The MPLS-TP list is the mailing list that is 188 usually used to decide consensus on MPLS-TP issues (although other 189 IETF mailing lists, such as WG lists, may be used). This is an 190 open mailing list with publicly available archives. 192 o MPLS-TP responsible working group chair - An IETF MPLS working 193 group chair assigned responsibility for the IETF MPLS-TP effort 194 by the IETF Routing Area Directors. 196 o MPLS-TP responsible AD - An IETF Routing Area Director with 197 management responsibility for the MPLS-TP effort. 199 o IETF liaison to the ITU-T on MPLS - An individual assigned 200 responsibility by the IAB for managing the liaison relationship 201 to the ITU-T in regard of all issues concerning MPLS, including 202 MPLS-TP. 204 o Contribution - Within the IETF, a contribution is any submission 205 to the IETF intended by the Contributor for publication as all or 206 part of an Internet-Draft or RFC, and any statement made within 207 the context of an IETF activity. Such statements include oral 208 statements in IETF sessions as well as written and electronic 209 communications. For more information on the IETF definition of a 210 contribution see [RFC5378]. 212 1.1.2. ITU-T Terms and Abbreviations 214 o Ad Hoc Team on MPLS-TP (ahtmplstp) - A team established by Study 215 Group 15 of the ITU-T to coordinate the work on MPLS-TP within the 216 ITU-T and to act as a focal point for communication with the IETF 217 about MPLS-TP. 219 o Ad Hoc Team on MPLS-TP mailing list - An ITU-T mail exploder 220 (ahmpls-tp@lists.itu.int) established specifically for the 221 discussion and coordination of the MPLS-TP effort within the 222 ITU-T. 224 o Contribution - Within the ITU-T, a contribution is a document that 225 is submitted to the ITU-T to advance work on the development of a 226 Recommendation or to propose the development of a new 227 Recommendation. 229 o Recommendation - A Recommendation is an ITU-T standards document. 231 1.2. Purpose and Intent of Cooperation on MPLS-TP 233 The purpose and objectives of the development activity on MPLS-TP is 234 described in [RFC5317]. The JWT decision includes the recognition 235 that the design authority for MPLS (including MPLS-TP) is the IETF. 237 At the same time, the JWT decision recognises the role of the ITU-T 238 in providing input (especially input to the requirements statements) 239 to the development process for MPLS-TP. There is also a clear 240 statement of expectation that the ITU-T's opinions will be heard 241 within the IETF and must be properly considered during the 242 development of MPLS-TP documents. 244 The development of standards for MPLS-TP is, therefore, carried out 245 within the IETF according to IETF process and with strong input from 246 the ITU-T. This input takes three forms (see also Section 2.2): 248 o Active participation. 250 All interested parties are encouraged to participate in the 251 development of MPLS-TP standards within the IETF through the 252 normal IETF process. In short, this involves the generation and 253 documentation of new ideas as Internet-Drafts, and the discussion 254 of work in progress through the IETF mailing lists. The IETF is 255 not a membership organisation, and the mailing lists are open. 257 o Informal communication. 259 It is recognised that discussions about MPLS-TP will take place 260 within the Questions and Study Groups of the ITU-T. In order to 261 speed up the development process and ensure smooth communications, 262 the ITU-T is requested to make informal (i.e., email) 263 communications to the IETF whenever any issues or questions 264 arise. Informal communication can be sent by any individual or 265 rapporteur of a Question as an email to the MPLS-TP mailing list. 266 The chairs of the Ad Hoc Team on MPLS-TP may also summarise 267 discussions within the ITU-T (especially those on the Ad Hoc Team 268 on MPLS-TP mailing list) and communicate them to the IETF via 269 email. 271 o Formal communication. 273 The formal liaison process with the IETF is described in [RFC4052] 274 and [RFC4053]. The process will be used for ensuring that specific 275 progress steps are check-pointed and recorded, and for making sure 276 that appropriate responses are generated in a timely manner. 277 Formal liaison communications may be marked as "For Action," "For 278 Comment," or "For Information" depending on the level of feedback 279 that is required. Where formal liaison communication is indicated 280 in this document, the type of liaison that is advised in each 281 instance is also indicated. 283 The objective of cooperation between the IETF and ITU-T is to ensure 284 full participation of interested parties to make sure that all 285 opinions are heard with the intention of producing sound and stable 286 MPLS-TP documentation. It is understood that the neither the IETF nor 287 the ITU-T can be in a position to block the work of the other body 288 within its areas of authority. In the context of this document, this 289 means that the ITU-T cannot block IETF work on MPLS-TP against the 290 IETF consensus view. 292 Part of this process must be the understanding that all IETF 293 documentation (including RFCs) can be revised or extended according 294 to normal IETF procedures. Therefore, it is not a requirement that 295 the first version of any RFC be perfect for all time (we do not need 296 to "boil the ocean"); the initial aim of the work is to provide 297 documentation of MPLS-TP as it is initially developed and deployed. 299 Fundamental to understanding the process described in the rest of 300 this document and to participating in the MPLS-TP development process 301 is a working knowledge of the procedures of the IETF. Readers needing 302 clarification of the IETF procedures are invited to read [RFC2026], 303 [RFC4677], and [RFC4929]. Further clarification and guidance can be 304 obtained from the MPLS-TP responsible working group chair, the MPLS- 305 TP responsible AD, and the IETF liaison to the ITU-T on MPLS. 307 The ITU-T may also develop Recommendations to document MPLS-TP. The 308 JWT decision recognises that these Recommendations must not contain 309 normative definitions of MPLS-TP (these are captured solely in IETF 310 RFCs). Recommendations on MPLS-TP will be provided for review by the 311 IETF to ensure conformance with the previous point and to verify that 312 the material is consistent across MPLS-TP. The process for producing 313 and reviewing Recommendations is out of scope for this document. 315 1.3. A Note on the MPLS-TP Interoperability Design Team 317 The MPLS Interoperability Design Team (the MEAD team) was a design 318 team established within the IETF with participants with experience 319 from standards development for MPLS and transport networks. The MEAD 320 team was chartered to coordinate the development of MPLS-TP within 321 the IETF and to create the initial document set before the work was 322 taken to the IETF working groups in the usual way. 324 The MEAD team was also responsible for coordinating cooperation with 325 the ITU-T on the Internet-Drafts it was working on. 327 The MEAD team completed its work and was closed in October 2009. 329 2. Adaptation of the IETF Working Group Process 331 The IETF working group processes as defined in RFC 2026 [RFC2026] are 332 adapted as described in this section solely for the purpose of the 333 MPLS-TP work. These adaptations do not apply to any other topic or 334 work within the IETF. 336 2.1. IETF Consensus and Mailing Lists 338 The IETF works according to a 'rough consensus' model, where working 339 group chairs determine the consensus after discussions on the mailing 340 lists. This is also applicable to the MPLS-TP work. The MPLS-TP 341 mailing list exists to focus all IETF discussions on MPLS-TP and to 342 avoid congesting other relevant working group mailing lists. All 343 technical discussion on MPLS-TP SHOULD be directed to the MPLS-TP 344 list, but other working group mailing lists SHOULD be notified when 345 appropriate so that individuals can participate in the discussions on 346 the MPLS-TP list. 348 Consensus activities (such as a working group last call) MUST be 349 started on an working group mailing list, but the MPLS-TP responsible 350 working group chair SHOULD direct discussions to the MPLS-TP list and 351 SHOULD direct that consensus will be judged on that list. The working 352 group chair MAY direct discussion and consensus to a specific working 353 group mailing list. 355 2.2. Communications with the ITU-T 357 A most important part of this process is the information exchange 358 between the IETF and ITU-T. This information exchange consists of 359 two equally important pieces. 361 o Informal information exchange 363 This is done primarily by e-mail to the relevant mailing lists. 364 Information sent to the ITU-T MUST be sent to the Ad Hoc Team on 365 MPLS-TP mailing list. Information sent to the IETF MUST be sent to 366 the MPLS-TP mailing list. 368 o Formal information exchange 370 In addition to the informal information exchange, a formal 371 information exchange is accomplished by liaison correspondence 372 between the two organisations. Exchange of liaisons makes it 373 possible to follow the request/response exchange between the 374 organisations in more detail, and to obtain an official view of 375 each organisation's position on any topic. 377 Formal liaisons SHOULD include tracking numbers in their subject 378 lines to facilitate easy coordination of responses with the 379 requests to which they are associated. 381 2.3. Adapted IETF Working Group Process 383 2.3.1. Flow Chart 385 The flow chart below describes the adaption of the working group 386 process. The flow chart and the process as described in Section 2.3.2 387 are equally normative. 389 ............. 390 : Ind Docs : 391 ............. 392 | 393 |(1) 394 v 395 +---------------+ 396 | WG Process | 397 +---------------+ 398 | ^ ind-00, ind-01, etc 399 | | | 400 | | |(2) 401 | | | 402 | +-------+ 403 (3)| review 404 | 405 v 406 +-----------------+ 407 | Poll for WG Doc | 408 +-----------------+ 409 | 410 |(4) 411 v 412 +-------------+ (5) +-------+ 413 +---------->| WG Doc |---------->| ITU-T | 414 | +-------------+ +-------+ 415 | | ^ wg-00, wg-01, etc | 416 | | | | | 417 | | | |(7) |(6) 418 | | | | | 419 (11)| (8)| +------+-<--------------+ 420 | | review 421 | v 422 | +-----------------+ 423 +----| WG Last Call | 424 +-----------------+ 425 | ^ | 426 (9)| |(10) |(12) 427 v | | 428 +---------+ | 429 | ITU-T | | 430 +---------+ | 431 v 432 +---------------+ 433 | Req for Pub | 434 +---------------+ 436 2.3.2. The IETF MPLS-TP Process 438 This section describes the development for MPLS-TP documents. It sets 439 out the process that is illustrated by the flow chart in Section 440 2.3.1. The numbered arrows in the flow chart are described as 441 numbered steps in the process in the list below. 443 Individual MPLS-TP documents can take different paths through the 444 this process. Although the different paths through the flow chart are 445 given as options, it is always possible for a particular MPLS-TP 446 Internet-Draft to be adopted as a working group draft. This is done 447 on the guidance of the MPLS-TP responsible working group chair and in 448 cooperation with the relevant working group chairs and the document 449 editors/authors. 451 1. Independent Documents through Working Group Processing 453 Internet-Drafts MAY be introduced by their authors to describe 454 any aspect of MPLS-TP. This option results in the document being 455 discussed and reviewed by the appropriate IETF working group as 456 determined by the working group chairs. The normal IETF process 457 will be applied, and the authors will revise the document (step 458 2) until it is adopted as a working group draft (see step 3). 460 Any individual or group of individuals can create an Internet- 461 Draft through this step. 463 2. Authors of independent documents SHOULD solicit comments on the 464 MPLS-TP mailing list and on any appropriate IETF working group 465 mailing lists. 467 The authors SHOULD revise the documents according to comments 468 received from all sources, or explain why no changes been made. 470 3. If an MPLS-TP document seems mature enough to become a working 471 group document, a poll is done on the MPLS-TP mailing list and 472 the appropriate working group mailing list to determine whether 473 there is consensus to adopt the document as a working group 474 document. 476 Which working group a document goes into is decided jointly by 477 the MPLS-TP responsible working group chair and the chairs of the 478 target working group. 480 4. If the document is accepted as a working group document the 481 working group takes over the revision control of the document. 482 Normal IETF working group process SHALL apply. All IETF 483 discussions about the document MUST now be held on the MPLS-TP 484 mailing list with notifications sent to the relevant IETF working 485 group mailing list. 487 5. When a document is accepted as a working group document, a 488 liaison MUST be sent to the ITU-T to inform them of the progress. 489 This liaison SHOULD be "for comment", but if the document is not 490 yet in a fit state for review the liaison MAY be "for 491 information". No response to this liaison is required. 493 An email to the Ad Hoc Team on MPLS-TP mailing list MUST be sent 494 in parallel with the liaison. 496 Each time an MPLS-TP document under working group control is 497 revised a note SHOULD be sent to the Ad Hoc Team on MPLS-TP 498 mailing list, and a liaison SHOULD be sent to the ITU-T to inform 499 them of the progress of the document. This liaison SHOULD be "for 500 comment" to allow for further review by the ITU-T, but MAY be 501 "for information" if the document is not in a fit state for 502 review or if there is no change in substance of the document 503 since the previous liaison. No response to these liaisons is 504 required. 506 The IETF working group MAY solicit input from the ITU-T at any 507 time by sending a liaison for comment. 509 6. At any time, it is possible for ITU-T participants to send review 510 comments on any MPLS-TP document. Such comments SHOULD be sent as 511 comments to the MPLS-TP mailing list according to normal IETF 512 process. 514 Additionally, this step provides for communication from ITU-T 515 Study Groups or Questions (see Section 3.2). These communications 516 may be unsolicited or in response to a request from the IETF 517 (step 5), and MAY be informal information exchanges or formal 518 information exchanges (see Section 2.2). Such exchanges (informal 519 or formal) SHOULD be accompanied by an email to the MPLS-TP 520 mailing list from the Ad Hoc Team on MPLS-TP chairs. 522 The document editors and the working group MUST give due 523 consideration to the issues raised in the communications from the 524 ITU-T, and SHOULD attempt to make suitable changes to the MPLS-TP 525 document or MUST otherwise explain why no change is being made. 527 Formal information exchanges MUST receive a response if 528 requested. The IETF liaison to the ITU-T on MPLS is responsible 529 for ensuring that this step is completed. 531 7. Editors of working group documents SHOULD solicit comments on the 532 MPLS-TP mailing list and on any appropriate IETF working group 533 mailing lists. Comments SHOULD also be solicited from the ITU-T 534 as "early review" using a liaison for comment (step 5). Comments 535 from the ITU-T may, therefore, be solicited or unsolicited and 536 are handled as described for step 6. 538 The authors SHOULD revise the documents according to comments 539 received from all sources. 541 Note that most comments that lead to updates of working group 542 documents are a result of spontaneous individual reviews and 543 comments from the individual participants in the MPLS-TP effort 544 according to normal IETF process. 546 8. When an MPLS-TP document is deemed mature enough, a working group 547 last call is initiated following normal IETF process. The working 548 group chairs are responsible for judging when to initiate this 549 last call. 551 9. When a working group last call is initiated for any MPLS-TP 552 document the following actions MUST be taken. 554 * A liaison for action containing a request for participation in 555 the working group last call MUST be sent to the appropriate 556 ITU-T Study Groups and Questions. 558 The Ad Hoc Team on MPLS-TP chairs are expected to verify that 559 all the Study Groups and Questions within the ITU-T that need 560 to respond to the working group last call are aware that it has 561 been issued. 563 * A notification that the working group last call is taking place 564 MUST be sent to the Ad Hoc Team on MPLS-TP mailing list and to 565 the MPLS-TP mailing list. 567 10. The ITU-T is REQUIRED to respond to the liaison in step 9 using a 568 liaison within the time indicated in the liaison (see Section 569 3.2). This deadline will usually be set according to the timeline 570 of the working group last call. 571 The ITU-T response MUST either include comments to be taken under 572 consideration by the working group along with other last call 573 comments, or provide a statement that the ITU-T has no comment. 574 The latter case SHALL be interpreted as ITU-T support for the 575 publication of the document as an RFC. 577 The working group and document editors MUST fully address any 578 comments received from the ITU-T via liaison under this step 579 either making the requested changes, or discuss the changes with 580 the ITU-T to reach a consensus position on the MPLS-TP mailing 581 list. The Rapporteur of the question that generated the liaison 582 statement is responsible for ensuring that the ITU participants 583 have visibility and input to the IETF WG comment resolution 584 process. If the changes are not as requested by the ITU liaison 585 the Rapporteur who was responsible for the generation of the 586 original liaison should generate another liaison statement 587 indicating if the resolution of the comments is acceptable to the 588 ITU-T. 590 11. According to normal IETF process, if the last call comments are 591 substantial the document MUST be returned to the working group 592 for revision and discussion. This MUST involve further 593 communication with the ITU-T (step 5) to clarify or resolve 594 issues raised during ITU-T review if they are handled other than 595 as requested by the ITU-T. 597 The working group last call (step 8) MAY be repeated multiple 598 times for revisions of the document. As is normal IETF process, 599 the working group chairs MAY issue subsequent working group last 600 calls for the entire document or MAY limit them to only the 601 updated text. In the latter case, further comments from within 602 the IETF or from the ITU-T SHOULD be limited as instructed by the 603 working group chair. 605 Note that, according to normal IETF process, if the last call 606 comments are minor, they SHOULD be addressed by the document 607 editors in coordination with the working group chairs and with 608 notification to the MPLS-TP mailing list. 610 12. When all last call comments have been addressed or responded to 611 and all necessary working group last calls have been held, the 612 working group chairs of the owning working group with assistance 613 of the MPLS-TP responsible working group chair will request 614 publication of the document as an RFC following normal IETF 615 process. 617 Once this request for publication is sent, the document will be 618 handled as any other IETF document with individual comments made 619 during IETF last call, and with IESG review following. Therefore, 620 after this point there is no further scope for ITU-T experts to 621 influence the development of the document other than as 622 individual contributors. 624 Note that if these later stages in the publication process cause 625 significant changes to the document, it MAY be fully or partially 626 returned to the working group, in which case some form of WG last 627 call with ITU-T consultation MUST take place following from step 628 8 as outlined above. 630 2.4. Naming Conventions for MPLS-TP Documents 632 To make it easier to search in the IETF Internet-Draft repositories, 633 the following rules MUST be followed for naming the MPLS-TP Internet- 634 Draft. 636 o All MPLS-TP Internet-Draft MUST include the sequence "mpls-tp" 637 in the filename. 639 o Individual MPLS-TP Internet-Draft MUST be named according to 640 this format: 642 draft-name-mpls-tp-topic-??.txt 644 "name" is the last name of the main editor, or an acronym 645 indicating the last names of the set of editors. 647 "topic" indicates the content of the draft, e.g. "oam-framework". 649 "??" indicates a two digit version number, starting with "00". 651 o MPLS working group documents MUST be named as follows: 653 draft-ietf-mpls-tp-topic-??.txt 655 "topic" indicates the content of the draft, e.g. "oam-framework". 657 "??" indicates a two digit version number, starting with "00". 659 o MPLS-TP documents from other working groups MUST be named 660 according to this format: 662 draft-ietf-wgname-mpls-tp-topic-??.txt 664 "wgname" is the acronym for any working group chartered to do 665 MPLS-TP work, e.g. pwe3 or ccamp. 667 "topic" indicates the content of the draft, e.g. "oam-framework". 669 "??" indicates a two digit version number, starting with "00". 671 3. Expectations on ITU-T Participation in the Process 673 The IETF looks for input from the ITU-T at two key points in the 674 process described in Section 2. 676 o Steps 5 and 6 : Review of Working Group Documents 678 o Steps 9 and 10 : Working Group Last Call and Document Approval 680 This section briefly describes what the IETF expects to happen on the 681 ITU-T side at these interaction points. 683 3.1. Working Group Document Review 685 The ITU-T may provide input to documents that are being developed by 686 IETF working groups. They are open for informal and formal comment by 687 the ITU-T and its participants. 689 As shown by step 5 in the process described in Section 2, the IETF 690 will notify the ITU-T of the existence of such documents and will 691 normally inform the ITU-T of new revisions. The ITU-T is not 692 required to respond to these communications. 694 The IETF may also request review or discussion of working group 695 documents. The ITU-T is required to respond to this type of 696 communication if it is a formal liaison (step 6) within the deadline 697 set by the liaison (see Section 3.3). In this case, it should either 698 send a liaison response with comments and questions, or it should 699 acknowledge the liaison from the IETF saying that there are no 700 questions or comments at this time. The latter type of response will 701 not be taken by the IETF to imply any form of support for the 702 document unless it is explicitly expressed. 704 Additionally, the ITU-T may send unsolicited communications on a 705 working group document as either informal or formal communications 706 (step 6). Formal communications may request a response from the IETF. 708 However, ITU-T participants are encouraged to bring their comments 709 and questions to the MPLS-TP mailing list directly, because this will 710 be more efficient and conforms to the normal IETF process. Comments 711 received in this way will be treated in the same way any as other 712 individual comments received on IETF documents. 714 3.2. Working Group Last Call and Document Approval 716 A working group last call is issued when a working group document is 717 close to being ready for publication as an RFC. The intention is to 718 make sure that there are no important pieces missing, that technical 719 details are correct, and that there is consensus within the working 720 group for moving forward. Consensus for MPLS-TP documents is judged 721 on the designated mailing list (normally the MPLS-TP mailing list) by 722 the chairs of the working group that has developed the document in 723 association with the MPLS-TP responsible working group chair. 725 During working group last call for all MPLS-TP documents the ITU-T 726 will always be consulted about the content of the documents. The 727 purpose of this step (step 9) is to ensure that the documents 728 address the needs and requirements of the ITU-T participants. 730 A formal communication will be made to the ITU-T to make it aware 731 that an IETF working group last call has been started and requesting 732 review and comment. According to the JWT decision, the ITU-T is 733 required to respond to a liaison about a working group last call 734 within the time set in announcing the working group last call. ITU-T 735 participants need to be aware that this step in the process 736 represents their last chance to influence the document from within 737 the ITU-T, and the liaison response needs to contain all issues and 738 comments - there will not be any scope to raise further concerns at a 739 later date. 741 The chair of an IETF working group that starts a working group last 742 call will send a liaison to the ITU-T announcing the working group 743 last call. A message will also be sent to the Ad Hoc Team on MPLS-TP 744 mailing list. 746 The IETF will make a best effort attempt to target the ITU-T Study 747 Groups and Questions that should be involved in responding to the 748 working group last call. However, the ITU-T must make sure that the 749 appropriate entities within the ITU-T participate in responding to 750 the working group last call. The ITU-T Ad Hoc Team on MPLS-TP 751 coordinates the development of the ITU-T response to the working 752 group last call. 754 The response to a working group last call should be unambiguous and 755 as detailed as possible. The liaison response is not intended to 756 start a conversation for clarification. It is intended to make clear 757 statements of technical issues to be addressed and to propose 758 resolutions for those issues. Acceptable responses include: 760 o No issues found. The ITU-T supports publication of the Internet- 761 Draft as an RFC in its current form. 763 o Minor issues found or questions raised. Please consider fixes to 764 these issues or respond to these questions before publication of 765 the Internet-Draft as an RFC. 767 o Major issues found. Please address these issues and allow the 768 ITU-T to review the resolution (possibly during a further working 769 group last call) before proceeding to publication of the Internet- 770 Draft as an RFC. 772 For the avoidance of doubt, the following guidance has been provided 773 by the ITU-T to its Rapporteurs: 775 During the final stages of development (e.g., Working Group last 776 call) the IETF will send a liaison to ITU-T for action. 778 At this stage the experts of the ITU-T must make a judgement if 779 the draft being reviewed is a suitable basis for a normative 780 reference from an ITU-T Recommendation. The group must reach a 781 consensus on this opinion. 783 A liaison to indicate support for the IETF to approve the draft 784 should contain the following text: 786 The experts of Qx have reviewed draft-xxxx by correspondence and 787 either: 789 - Have no concerns with the IETF proceeding with approval; 791 or 793 - Request that the following changes are made before the IETF 794 approves the draft. 796 Exceptionally, if consensus to support approval of the draft 797 cannot be reached, a response liaison must be sent indicating 798 that consensus could not be reached by correspondence and that 799 the matter will be addressed at the next SG (or interim) 800 meeting. 802 If the ITU-T is unable to reach consensus, the working group may 803 proceed to reach its own consensus on the document on the 804 understanding that it may be necessary to revise the document later 805 when ITU-T consensus is reached. 807 Note that, as described in Section 1.2, the cooperation process is 808 designed to ensure constructive consideration and resolution of all 809 issues raised by the ITU-T without blocking the progress of the 810 IETF's work on MPLS-TP. It is expected that discussion of major 811 issues raised at this stage of the process will be conducted on the 812 MPLS-TP mailing list and through appropriate communication with the 813 ITU-T. It is further expected that such issues will be resolved 814 through technical evaluation and rough consensus judged as normal for 815 the IETF process. In the event that agreement between the IETF and 816 ITU-T cannot be reached on some technical point, the JWT will be 817 convened to seek a resolution. 819 3.3. Non-Response to Liaisons 821 The liaison relationship between the IETF and the ITU-T is founded on 822 the understanding that each party will respond in a timely and 823 appropriate manner to the other party's liaisons so long as 824 reasonable notice is given. 826 Failure to respond by a deadline properly expressed in a liaison must 827 not be used to cause deadlock or to block advancement of work. Such 828 failures shall be assumed to represent accidental errors or 829 oversights and shall be brought to the attention of the management of 830 the body that has failed to respond. 832 In extreme cases, the JWT is empowered to convene itself to resolve 833 issues of failed communications. 835 4. Guidelines For MPLS-TP work in the ITU-T 837 These guidelines apply to progressing work on MPLS-TP in the ITU-T. 839 Any member of the ITU-T may send an MPLS-TP contribution to a ITU-T 840 Study Group or Question. 842 Before the ITU-T initiates any new work (i.e., items not previously 843 identified by the JWT) based on such contributions the ITU-T shall 844 send a liaison to the IETF. The message will go to the IETF 845 liaison to the ITU-T on MPLS, the MPLS-TP responsible working 846 group chair, and the MPLS-TP responsible AD. They are responsible 847 for sending a consolidated response from the IETF, but may 848 delegate the work of writing the response. 850 The IETF must respond to such liaisons according to the deadline 851 in the liaison. Acceptable responses include: 853 o Acknowledgement of receipt and agreement that the ITU-T is 854 clear to proceed with the work described. 856 o Request that the work described be transferred from the ITU-T to 857 the IETF in the form of an Internet-Draft to form part of the 858 MPLS-TP work in the IETF. 860 o Request that the work be put on hold until specific issues have 861 been resolved. In the event that this response is seen as 862 blocking of ITU-T work, the JWT may be convened to seek a 863 resolution. 865 Note that the process described in this section is conformant to the 866 Change Process for Multiprotocol Label Switching (MPLS) and 867 Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929]. 869 5. IANA Considerations 871 There are no requests for IANA action in this document. 873 6. Security Considerations 875 This document defines a process adaptation for the cooperation 876 between the IETF and the ITU-T and thus does not introduce any new 877 security considerations. 879 The successful development of MPLS-TP standards that are consistent 880 across the industry is an essential component to ensuring the 881 security and stability of MPLS networks. 883 7. Acknowledgments 885 Thanks to Eric Gray who helped with grammar and useful comments. 886 Thanks to Tom Petch who spent time trying to sort out what the 887 document said, and who sent comments that helped clarify the 888 document. Thanks to the participants of ITU-T Study Group 15 who 889 provided review and comments on an early version of this text. 891 8. References 893 8.1. Normative References 895 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 896 3", BCP 9, RFC 2026, October 1996. 898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 899 Requirement Levels", BCP 14, RFC 2119, March 1997. 901 8.2. Informative References 903 [RFC4052] Daigle, L., Ed., and Internet Architecture Board, "IAB 904 Processes for Management of IETF Liaison Relationships", 905 BCP 102, RFC 4052, April 2005. 907 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 908 Handling Liaison Statements to and from the IETF", BCP 909 103, RFC 4053, April 2005. 911 [RFC4677] Hoffman, P. and Harris, S., "The Tao of IETF: A Novice's 912 Guide to the Internet Engineering Task Force", RFC 4677, 913 September 2006. 915 [RFC4929] Andersson, L. and Farrel, A., "Change Process for 916 Multiprotocol Label Switching (MPLS) and Generalized MPLS 917 (GMPLS) Protocols and Procedures", BCP 129, RFC4929, June 918 2007. 920 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 921 Report on MPLS Architectural Considerations for a 922 Transport Profile", RFC 5317, February 2009. 924 [RFC5378] Bradner, S., and Contreras, J., "Rights Contributors 925 Provide to the IETF Trust", BCP 78, RFC 5378, November 926 2008. 928 Authors' Addresses 930 Loa Andersson 931 Ericsson Inc 933 Email: loa.andersson@ericsson.com 935 David Ward 936 Cisco Systems 938 Email: dward@cisco.com 940 Malcolm Betts 941 Huawei 943 Email: malcolm.betts@huawei.com 945 Adrian Farrel 946 Huawei 948 Email: adrian.farrel@huawei.com