idnits 2.17.1 draft-ietf-mpls-tp-process-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (January 24, 2010) is 5206 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Farrel (Ed.) 2 Internet-Draft Huawei Technologies 3 Intended status: BCP L. Andersson 4 Expires: July 24, 2010 Ericsson Inc. 5 D. Ward 6 Juniper Networks 7 M. Betts 9 January 24, 2010 11 IETF Multi-Protocol Label Switching (MPLS) 12 Transport Profile (MPLS-TP) Document Process 14 draft-ietf-mpls-tp-process-05.txt 16 Status of this Memo 18 This Internet-Draft is submitted 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) 2010 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 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Abstract 54 The decision to develop a Multiprotocol Label Switching (MPLS) 55 Transport Profile (MPLS-TP) in cooperation between the IETF and the 56 ITU-T is document in RFC 5317 as the decision of the Joint Working 57 Team on MPLS-TP. 59 This document provides additional detail of the processes for the 60 development of IETF RFCs on MPLS-TP. It provides an adaptation of the 61 IETF working group process; identifies the expected participation in 62 the process by the ITU-T; and clarifies the rules and conventions 63 regarding MPLS-TP documents. 65 This document does not specify any ITU-T process; ITU-T activities 66 will be done according to ITU-T process/rules. 68 This document does not specify or modify the normal IETF working 69 group process. It is limited to the specific adaptations of that 70 process to facilitate the cooperation agreement between the IETF and 71 the ITU-T on MPLS-TP, and to ensure a good and consistent document 72 review across the two organizations. 74 This document is a product of a joint Internet Engineering Task Force 75 (IETF) / International Telecommunication Union Telecommunication 76 Standardization Sector (ITU-T) effort to include an MPLS Transport 77 Profile within the IETF MPLS and PWE3 architectures to support the 78 capabilities and functionalities of a packet transport network. 80 Table of Contents 82 1. Introduction ................................................... 4 83 1.1. Terminology ................................................ 4 84 1.1.1. IETF Terms and Abbreviations ........................... 5 85 1.1.2. ITU-T Terms and Abbreviations .......................... 6 86 1.2. Purpose, Intent, and Procedures for Cooperation on MPLS-TP . 6 87 1.3. A Note on the MPLS-TP Interoperability Design Team ......... 8 88 2. Adaptation of the IETF Working Group Process ................... 8 89 2.1. IETF Consensus and Mailing Lists ........................... 9 90 2.2. Communications with the ITU-T .............................. 9 91 2.3. Adapted IETF Working Group Process ........................ 10 92 2.3.1. Flow Chart ............................................ 10 93 2.3.2. The IETF MPLS-TP Process .............................. 12 94 2.4. Naming Conventions for MPLS-TP Documents .................. 16 95 2.5. Boilerplate Text For Inclusion in MPLS-TP Documents ....... 16 96 2.5.1. Abstract .............................................. 17 97 2.5.2. Introduction .......................................... 17 98 2.5.3. Recognition of IETF Consensus for Informational RFCs .. 17 99 3. Expectations on ITU-T Participation in the Process ............ 17 100 3.1. Working Group Document Review ............................. 18 101 3.2. Working Group Last Call and Document Approval ............. 18 102 3.3. Non-Response to Liaisons .................................. 21 103 4. Guidelines For MPLS-TP work in the ITU-T ...................... 21 104 5. IANA Considerations ........................................... 22 105 6. Security Considerations ....................................... 22 106 7. Acknowledgments ............................................... 22 107 8. References .................................................... 22 108 8.1. Normative References ...................................... 22 109 8.2. Informative References .................................... 22 110 Authors' Addresses ............................................... 23 112 1. Introduction 114 The IETF and ITU-T have entered into an agreement to develop the 115 Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP). 116 This agreement is known as the Joint Working Team on MPLS-TP (JWT) 117 Agreement and is documented in [RFC5317]. The agreement states that 118 MPLS-TP will be documented in IETF RFCs, and assumes that there will 119 be close cooperation with the ITU-T in reviewing these RFCs. This 120 cooperation will include review of the work at all stages of 121 drafting. 123 This document provides additional detail of the processes for the 124 development of IETF RFCs on MPLS-TP as follows. 126 o It Provides an adaptation of the IETF working group process, with 127 respect to how the IETF will take input from the ITU-T on MPLS-TP 128 topics. 130 o It identifies the expected participation by the ITU-T in the 131 document development process, noting that the ITU-T has committed 132 to responding promptly to IETF working group last calls in a way 133 that may require the ITU-T to develop responses via 134 correspondence. 136 o It clarifies the rules regarding MPLS-TP documents. 138 This document does not specify or modify the normal IETF working 139 group process. It is limited to the specific adaptations of that 140 process to facilitate the cooperation agreement between the IETF and 141 the ITU-T on MPLS-TP, and to ensure a good and consistent document 142 review across the two organizations. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 Although this document is not a protocol specification, this language 148 is used for clarity and decisiveness. 150 This document is a product of a joint Internet Engineering Task Force 151 (IETF) / International Telecommunication Union Telecommunication 152 Standardization Sector (ITU-T) effort to include an MPLS Transport 153 Profile within the IETF MPLS and PWE3 architectures to support the 154 capabilities and functionalities of a packet transport network. 156 1.1. Terminology 158 This section includes a number of terms and abbreviations that are 159 used in this document. The section is split into two subsection: 161 IETF terms and ITU-T terms. 163 1.1.1. IETF Terms and Abbreviations 165 o JWT - Joint Working Team, a team with participants with experience 166 from standards development in the IETF and the ITU-T. 168 Note: The JWT is not part of either the IETF or ITU-T, but a group 169 that has been set up to facilitate cooperation on MPLS-TP between 170 the two organizations. 172 o JWT decision - A set of recommendations on the procedural approach 173 to the development of MPLS-TP made by the JWT and documented in 174 [RFC5317]. 176 o JWT agreement - The agreement between IETF and ITU-T based on the 177 JWT decision to jointly develop MPLS-TP according IETF processes. 179 o JWT documents - The set of documents envisioned in the JWT 180 decision [RFC5317]. 182 o MPLS-TP documents - The following sets of documents are counted as 183 MPLS-TP documents: 185 * Individual Internet-Drafts that address the MPLS-TP problem 186 space. 188 * Working group Internet-Drafts that address the MPLS-TP problem 189 space. 191 * Internet-Drafts that are considered for publication as RFCs by 192 the IESG and that address the MPLS-TP problem space. 194 * Internet-Drafts that are approved for publication as RFCs by 195 the IESG and that address the MPLS-TP problem space. 197 * Published RFCs that address the MPLS-TP problem space. 199 * ITU-T Recommendations and draft Recommendations in various 200 stages of development that address the MPLS-TP problem space. 202 Documents that originate from the IRTF RFC stream or the 203 Independent Submission Stream are not considered as MPLS-TP 204 documents. 206 o MPLS-TP mailing list - An IETF mailing list (mpls-tp@ietf.org) 207 established specifically for the discussion of MPLS-TP issues 208 within the IETF. The MPLS-TP list is the mailing list that is 209 usually used to decide consensus on MPLS-TP issues (although other 210 IETF mailing lists, such as WG lists, may be used). This is an 211 open mailing list with publicly available archives. 213 o MPLS-TP responsible working group chair - An IETF MPLS working 214 group chair assigned responsibility for the IETF MPLS-TP effort 215 by the IETF Routing Area Directors. 217 o MPLS-TP responsible AD - An IETF Routing Area Director with 218 management responsibility for the MPLS-TP effort. 220 o IETF liaison to the ITU-T on MPLS - An individual assigned 221 responsibility by the IAB for managing the liaison relationship 222 to the ITU-T in regard of all issues concerning MPLS, including 223 MPLS-TP. 225 o Contribution - Within the IETF, a contribution is any submission 226 to the IETF intended by the Contributor for publication as all or 227 part of an Internet-Draft or RFC, and any statement made within 228 the context of an IETF activity. Such statements include oral 229 statements in IETF sessions as well as written and electronic 230 communications. For more information on the IETF definition of a 231 contribution see [RFC5378]. 233 1.1.2. ITU-T Terms and Abbreviations 235 o Ad Hoc Team on MPLS-TP (ahtmplstp) - A team established by Study 236 Group 15 of the ITU-T to coordinate the work on MPLS-TP within the 237 ITU-T and to act as a focal point for communication with the IETF 238 about MPLS-TP. 240 o Ad Hoc Team on MPLS-TP mailing list - An ITU-T mail exploder 241 (ahmpls-tp@lists.itu.int) established specifically for the 242 discussion and coordination of the MPLS-TP effort within the 243 ITU-T. 245 o Contribution - Within the ITU-T, a contribution is a document that 246 is submitted to the ITU-T to advance work on the development of a 247 Recommendation or to propose the development of a new 248 Recommendation. 250 o Recommendation - A Recommendation is an ITU-T standards document. 252 1.2. Purpose, Intent, and Procedures for Cooperation on MPLS-TP 254 The purpose and objectives of the development activity on MPLS-TP is 255 described in [RFC5317]. The JWT decision includes the recognition 256 that the design authority for MPLS (including MPLS-TP) is the IETF. 258 At the same time, the JWT decision recognises the role of the ITU-T 259 in providing input (especially input to the requirements statements) 260 to the development process for MPLS-TP. There is also a clear 261 statement of expectation that the ITU-T's opinions will be heard 262 within the IETF and must be properly considered during the 263 development of MPLS-TP documents. 265 It should be noted that other related technologies (espeically those 266 for core MPLS and pseudowire deployments) do not fall within this 267 cooperation agreement. The IETF will continue to develop Internet 268 technologies as before and welcomes particpation from all 269 individuals. Where such developments overlap with MPLS-TP such that 270 they are important to the work on MPLS-TP, they will form part of the 271 cooperation project. 273 The development of standards for MPLS-TP is, therefore, carried out 274 within the IETF according to IETF process and with strong input from 275 the ITU-T. This input takes three forms (see also Section 2.2): 277 o Active participation. 279 All interested parties are encouraged to participate in the 280 development of MPLS-TP standards within the IETF through the 281 normal IETF process. In short, this involves the generation and 282 documentation of new ideas as Internet-Drafts, and the discussion 283 of work in progress through the IETF mailing lists. The IETF is 284 not a membership organisation, and the mailing lists are open. 286 o Informal communication. 288 It is recognised that discussions about MPLS-TP will take place 289 within the Questions and Study Groups of the ITU-T. In order to 290 speed up the development process and ensure smooth communications, 291 the ITU-T is requested to make informal (i.e., email) 292 communications to the IETF whenever any issues or questions 293 arise. Informal communication can be sent by any individual or 294 rapporteur of a Question as an email to the MPLS-TP mailing list. 295 The chairs of the Ad Hoc Team on MPLS-TP may also summarise 296 discussions within the ITU-T (especially those on the Ad Hoc Team 297 on MPLS-TP mailing list) and communicate them to the IETF via 298 email. 300 o Formal communication. 302 The formal liaison process with the IETF is described in [RFC4052] 303 and [RFC4053]. The process will be used for ensuring that specific 304 progress steps are check-pointed and recorded, and for making sure 305 that appropriate responses are generated in a timely manner. 307 Formal liaison communications may be marked as "For Action," "For 308 Comment," or "For Information" depending on the level of feedback 309 that is required. Where formal liaison communication is indicated 310 in this document, the type of liaison that is advised in each 311 instance is also indicated. 313 The objective of cooperation between the IETF and ITU-T is to ensure 314 full participation of interested parties to make sure that all 315 opinions are heard with the intention of producing sound and stable 316 MPLS-TP documentation. It is understood that the neither the IETF nor 317 the ITU-T can be in a position to block the work of the other body 318 within its areas of authority. In the context of this document, this 319 means that the ITU-T cannot block IETF work on MPLS-TP against the 320 IETF consensus view. 322 Part of this process must be the understanding that all IETF 323 documentation (including RFCs) can be revised or extended according 324 to normal IETF procedures. Therefore, it is not a requirement that 325 the first version of any RFC be perfect for all time (we do not need 326 to "boil the ocean"); the initial aim of the work is to provide 327 documentation of MPLS-TP as it is initially developed and deployed. 329 Fundamental to understanding the process described in the rest of 330 this document and to participating in the MPLS-TP development process 331 is a working knowledge of the procedures of the IETF. Readers needing 332 clarification of the IETF procedures are invited to read [RFC2026], 333 [RFC4677], and [RFC4929]. Further clarification and guidance can be 334 obtained from the MPLS-TP responsible working group chair, the MPLS- 335 TP responsible AD, and the IETF liaison to the ITU-T on MPLS. 337 The ITU-T may also develop Recommendations to document MPLS-TP. The 338 JWT decision recognises that these Recommendations must not contain 339 normative definitions of MPLS-TP (these are captured solely in IETF 340 RFCs). Recommendations on MPLS-TP will be provided for review by the 341 IETF to ensure conformance with the previous point and to verify that 342 the material is consistent across MPLS-TP. The process for producing 343 and reviewing Recommendations is out of scope for this document. 345 1.3. A Note on the MPLS-TP Interoperability Design Team 347 The MPLS Interoperability Design Team (the MEAD team) was a design 348 team established within the IETF with participants with experience 349 from standards development for MPLS and transport networks. The MEAD 350 team was chartered to coordinate the development of MPLS-TP within 351 the IETF and to create the initial document set before the work was 352 taken to the IETF working groups in the usual way. 354 The MEAD team was also responsible for coordinating cooperation with 355 the ITU-T on the Internet-Drafts it was working on. 357 The MEAD team completed its work and was closed in October 2009. 359 2. Adaptation of the IETF Working Group Process 361 The IETF working group processes as defined in RFC 2026 [RFC2026] are 362 adapted as described in this section solely for the purpose of the 363 MPLS-TP work. These adaptations do not apply to any other topic or 364 work within the IETF. 366 2.1. IETF Consensus and Mailing Lists 368 The IETF works according to a 'rough consensus' model, where working 369 group chairs determine the consensus after discussions on the mailing 370 lists. This is also applicable to the MPLS-TP work. The MPLS-TP 371 mailing list exists to focus all IETF discussions on MPLS-TP and to 372 avoid congesting other relevant working group mailing lists. All 373 technical discussion on MPLS-TP SHOULD be directed to the MPLS-TP 374 list, but other working group mailing lists SHOULD be notified when 375 appropriate so that individuals can participate in the discussions on 376 the MPLS-TP list. 378 Consensus activities (such as a working group last call) MUST be 379 started on an working group mailing list, but the MPLS-TP responsible 380 working group chair SHOULD direct discussions to the MPLS-TP list and 381 SHOULD direct that consensus will be judged on that list. The working 382 group chair MAY direct discussion and consensus to a specific working 383 group mailing list. 385 2.2. Communications with the ITU-T 387 A most important part of this process is the information exchange 388 between the IETF and ITU-T. This information exchange consists of 389 two equally important pieces. 391 o Informal information exchange 393 This is done primarily by e-mail to the relevant mailing lists. 394 Information sent to the ITU-T MUST be sent to the Ad Hoc Team on 395 MPLS-TP mailing list. Information sent to the IETF MUST be sent to 396 the MPLS-TP mailing list. 398 o Formal information exchange 400 In addition to the informal information exchange, a formal 401 information exchange is accomplished by liaison correspondence 402 between the two organisations. Exchange of liaisons makes it 403 possible to follow the request/response exchange between the 404 organisations in more detail, and to obtain an official view of 405 each organisation's position on any topic. 407 Formal liaisons SHOULD include tracking numbers in their subject 408 lines to facilitate easy coordination of responses with the 409 requests to which they are associated. 411 2.3. Adapted IETF Working Group Process 413 2.3.1. Flow Chart 415 The flow chart below describes the adaption of the working group 416 process. The flow chart and the process as described in Section 2.3.2 417 are equally normative. 419 ............. 420 : Ind Docs : 421 ............. 422 | 423 |(1) 424 v 425 +---------------+ 426 | WG Process | 427 +---------------+ 428 | ^ ind-00, ind-01, etc 429 | | | 430 | | |(2) 431 | | | 432 | +-------+ 433 (3)| review 434 | 435 v 436 +-----------------+ 437 | Poll for WG Doc | 438 +-----------------+ 439 | 440 |(4) 441 v 442 +-------------+ (5) +-------+ 443 +---------->| WG Doc |---------->| ITU-T | 444 | +-------------+ +-------+ 445 | | ^ wg-00, wg-01, etc | 446 | | | | | 447 | | | |(7) |(6) 448 | | | | | 449 (11)| (8)| +------+-<--------------+ 450 | | review 451 | v 452 | +-----------------+ 453 +----| WG Last Call | 454 +-----------------+ 455 | ^ | 456 (9)| |(10) |(12) 457 v | | 458 +---------+ | 459 | ITU-T | | 460 +---------+ | 461 v 462 +---------------+ 463 | Req for Pub | 464 +---------------+ 466 2.3.2. The IETF MPLS-TP Process 468 This section describes the development for MPLS-TP documents. It sets 469 out the process that is illustrated by the flow chart in Section 470 2.3.1. The numbered arrows in the flow chart are described as 471 numbered steps in the process in the list below. 473 Individual MPLS-TP documents can take different paths through the 474 this process. Although the different paths through the flow chart are 475 given as options, it is always possible for a particular MPLS-TP 476 Internet-Draft to be adopted as a working group draft. This is done 477 on the guidance of the MPLS-TP responsible working group chair and in 478 cooperation with the relevant working group chairs and the document 479 editors/authors. 481 1. Independent Documents through Working Group Processing 483 Internet-Drafts MAY be introduced by their authors to describe 484 any aspect of MPLS-TP. This option results in the document being 485 discussed and reviewed by the appropriate IETF working group as 486 determined by the working group chairs. The normal IETF process 487 will be applied, and the authors will revise the document (step 488 2) until it is adopted as a working group draft (see step 3). 490 Any individual or group of individuals can create an Internet- 491 Draft through this step. 493 2. Authors of independent documents SHOULD solicit comments on the 494 MPLS-TP mailing list and on any appropriate IETF working group 495 mailing lists. 497 The authors SHOULD revise the documents according to comments 498 received from all sources, or explain why no changes been made. 500 3. If an MPLS-TP document seems mature enough to become a working 501 group document, a poll is done on the MPLS-TP mailing list and 502 the appropriate working group mailing list to determine whether 503 there is consensus to adopt the document as a working group 504 document. 506 Which working group a document goes into is decided jointly by 507 the MPLS-TP responsible working group chair and the chairs of the 508 target working group. 510 4. If the document is accepted as a working group document the 511 working group takes over the revision control of the document. 512 Normal IETF working group process SHALL apply. All IETF 513 discussions about the document MUST now be held on the MPLS-TP 514 mailing list with notifications sent to the relevant IETF working 515 group mailing list. 517 5. When a document is accepted as a working group document, a 518 liaison MUST be sent to the ITU-T to inform them of the progress. 519 This liaison SHOULD be "for comment", but if the document is not 520 yet in a fit state for review the liaison MAY be "for 521 information". No response to this liaison is required. 523 An email to the Ad Hoc Team on MPLS-TP mailing list MUST be sent 524 in parallel with the liaison. 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 SHOULD be sent to the ITU-T to inform 529 them of the progress of the document. This liaison SHOULD be "for 530 comment" to allow for further review by the ITU-T, but MAY be 531 "for information" if the document is not in a fit state for 532 review or if there is no change in substance of the document 533 since the previous liaison. No response to these liaisons is 534 required. 536 The IETF working group MAY solicit input from the ITU-T at any 537 time by sending a liaison for comment. 539 6. At any time, it is possible for ITU-T participants to send review 540 comments on any MPLS-TP document. Such comments SHOULD be sent as 541 comments to the MPLS-TP mailing list according to normal IETF 542 process. 544 Additionally, this step provides for communication from ITU-T 545 Study Groups or Questions (see Section 3.2). These communications 546 may be unsolicited or in response to a request from the IETF 547 (step 5), and MAY be informal information exchanges or formal 548 information exchanges (see Section 2.2). Such exchanges (informal 549 or formal) SHOULD be accompanied by an email to the MPLS-TP 550 mailing list from the Ad Hoc Team on MPLS-TP chairs. 552 The document editors and the working group MUST give due 553 consideration to the issues raised in the communications from the 554 ITU-T, and SHOULD attempt to make suitable changes to the MPLS-TP 555 document or MUST otherwise explain why no change is being made. 557 Formal information exchanges MUST receive a response if 558 requested. The IETF liaison to the ITU-T on MPLS is responsible 559 for ensuring that this step is completed. 561 7. Editors of working group documents SHOULD solicit comments on the 562 MPLS-TP mailing list and on any appropriate IETF working group 563 mailing lists. Comments SHOULD also be solicited from the ITU-T 564 as "early review" using a liaison for comment (step 5). Comments 565 from the ITU-T may, therefore, be solicited or unsolicited and 566 are handled as described for step 6. 568 The authors SHOULD revise the documents according to comments 569 received from all sources. 571 Note that most comments that lead to updates of working group 572 documents are a result of spontaneous individual reviews and 573 comments from the individual participants in the MPLS-TP effort 574 according to normal IETF process. 576 8. When an MPLS-TP document is deemed mature enough, a working group 577 last call is initiated following normal IETF process. The working 578 group chairs are responsible for judging when to initiate this 579 last call. 581 9. When a working group last call is initiated for any MPLS-TP 582 document the following actions MUST be taken. 584 * A liaison for action containing a request for participation in 585 the working group last call MUST be sent to the appropriate 586 ITU-T Study Groups and Questions. 588 The Ad Hoc Team on MPLS-TP chairs are expected to verify that 589 all the Study Groups and Questions within the ITU-T that need 590 to 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 Ad Hoc Team on MPLS-TP mailing list and to 595 the MPLS-TP mailing list. 597 10. The ITU-T is REQUIRED to respond to the liaison in step 9 using a 598 liaison within the time indicated in the liaison (see Section 599 3.2). This deadline will usually be set according to the timeline 600 of the working group last call. 601 The ITU-T response MUST either include comments to be taken under 602 consideration by the working group along with other last call 603 comments, or provide a statement that the ITU-T has no comment. 604 The latter case SHALL be interpreted as ITU-T support for the 605 publication of the document as an RFC. 607 The working group and document editors MUST fully address any 608 comments received from the ITU-T via liaison under this step 609 either making the requested changes, or discuss the changes with 610 the ITU-T to reach a consensus position on the MPLS-TP mailing 611 list. The Rapporteur of the question that generated the liaison 612 statement is responsible for ensuring that the ITU participants 613 have visibility and input to the IETF WG comment resolution 614 process. If the changes are not as requested by the ITU liaison 615 the Rapporteur who was responsible for the generation of the 616 original liaison should generate another liaison statement 617 indicating if the resolution of the comments is acceptable to the 618 ITU-T. 620 11. According to normal IETF process, if the last call comments are 621 substantial the document MUST be returned to the working group 622 for revision and discussion. This MUST involve further 623 communication with the ITU-T (step 5) to clarify or resolve 624 issues raised during ITU-T review if they are handled other than 625 as requested by the ITU-T. 627 The working group last call (step 8) MAY be repeated multiple 628 times for revisions of the document. As is normal IETF process, 629 the working group chairs MAY issue subsequent working group last 630 calls for the entire document or MAY limit them to only the 631 updated text. In the latter case, further comments from within 632 the IETF or from the ITU-T SHOULD be limited as instructed by the 633 working group chair. 635 Note that, according to normal IETF process, if the last call 636 comments are minor, they SHOULD be addressed by the document 637 editors in coordination with the working group chairs and with 638 notification to the MPLS-TP mailing list. 640 12. When all last call comments have been addressed or responded to 641 and all necessary working group last calls have been held, the 642 working group chairs of the owning working group with assistance 643 of the MPLS-TP responsible working group chair will request 644 publication of the document as an RFC following normal IETF 645 process. 647 Once this request for publication is sent, the document will be 648 handled as any other IETF document with individual comments made 649 during IETF last call, and with IESG review following. Therefore, 650 after this point there is no further scope for ITU-T experts to 651 influence the development of the document other than as 652 individual contributors. 654 Note that if these later stages in the publication process cause 655 significant changes to the document, it MAY be fully or partially 656 returned to the working group, in which case some form of WG last 657 call with ITU-T consultation MUST take place following from step 658 8 as outlined above. 660 2.4. Naming Conventions for MPLS-TP Documents 662 To make it easier to search in the IETF Internet-Draft repositories, 663 the following rules MUST be followed for naming the MPLS-TP Internet- 664 Draft. 666 o All MPLS-TP Internet-Draft MUST include the sequence "mpls-tp" 667 in the filename. 669 o Individual MPLS-TP Internet-Draft MUST be named according to 670 this format: 672 draft-name-mpls-tp-topic-??.txt 674 "name" is the last name of the main editor, or an acronym 675 indicating the last names of the set of editors. 677 "topic" indicates the content of the draft, e.g. "oam-framework". 679 "??" indicates a two digit version number, starting with "00". 681 o MPLS working group documents MUST be named as follows: 683 draft-ietf-mpls-tp-topic-??.txt 685 "topic" indicates the content of the draft, e.g. "oam-framework". 687 "??" indicates a two digit version number, starting with "00". 689 o MPLS-TP documents from other working groups MUST be named 690 according to this format: 692 draft-ietf-wgname-mpls-tp-topic-??.txt 694 "wgname" is the acronym for any working group chartered to do 695 MPLS-TP work, e.g. pwe3 or ccamp. 697 "topic" indicates the content of the draft, e.g. "oam-framework". 699 "??" indicates a two digit version number, starting with "00". 701 2.5. Boilerplate Text For Inclusion in MPLS-TP Documents 703 In order to clarify the status of MPLS-TP documents within the IETF, 704 the following boilerplate text is included in Internet-Drafts. 706 2.5.1. Abstract 708 In the Abstract of each MPLS-TP Internet-Draft, as the final 709 paragraph, the following text is included: 711 This document is a product of a joint Internet Engineering Task 712 Force (IETF) / International Telecommunication Union 713 Telecommunication Standardization Sector (ITU-T) effort to include 714 an MPLS Transport Profile within the IETF MPLS and PWE3 715 architectures to support the capabilities and functionalities of a 716 packet transport network. 718 2.5.2. Introduction 720 Somewhere within the Introduction section of each MPLS-TP Internet- 721 Draft, the following text is included: 723 This document is a product of a joint Internet Engineering Task 724 Force (IETF) / International Telecommunication Union 725 Telecommunication Standardization Sector (ITU-T) effort to include 726 an MPLS Transport Profile within the IETF MPLS and PWE3 727 architectures to support the capabilities and functionalities of a 728 packet transport network. 730 2.5.3. Recognition of IETF Consensus for Informational RFCs 732 In order to allow the ITU-T to make normative references to 733 Informational RFCs, the documents need to progress through IETF last 734 call and have the weight of IETF consensus. This will be recorded in 735 the published RFC using text added by the RFC Editor. 737 To make sure that the RFC Editor is reminded to do this, the 738 following two paragraphs are included before the Introduction section 739 of an Informational MPLS-TP Internet-Draft. 741 This Informational Internet-Draft is aimed at achieving IETF 742 Consensus before publication as an RFC and will be subject to an 743 IETF Last Call. 745 [RFC Editor, please remove this note before publication as an RFC 746 and insert the correct Streams Boilerplate to indicate that the 747 published RFC has IETF Consensus.] 749 3. Expectations on ITU-T Participation in the Process 751 The IETF looks for input from the ITU-T at two key points in the 752 process described in Section 2. 754 o Steps 5 and 6 : Review of Working Group Documents 756 o Steps 9 and 10 : Working Group Last Call and Document Approval 758 This section briefly describes what the IETF expects to happen on the 759 ITU-T side at these interaction points. 761 3.1. Working Group Document Review 763 The ITU-T may provide input to documents that are being developed by 764 IETF working groups. They are open for informal and formal comment by 765 the ITU-T and its participants. 767 As shown by step 5 in the process described in Section 2, the IETF 768 will notify the ITU-T of the existence of such documents and will 769 normally inform the ITU-T of new revisions. The ITU-T is not 770 required to respond to these communications. 772 The IETF may also request review or discussion of working group 773 documents. The ITU-T is required to respond to this type of 774 communication if it is a formal liaison (step 6) within the deadline 775 set by the liaison (see Section 3.3). In this case, it should either 776 send a liaison response with comments and questions, or it should 777 acknowledge the liaison from the IETF saying that there are no 778 questions or comments at this time. The latter type of response will 779 not be taken by the IETF to imply any form of support for the 780 document unless it is explicitly expressed. 782 Additionally, the ITU-T may send unsolicited communications on a 783 working group document as either informal or formal communications 784 (step 6). Formal communications may request a response from the IETF. 786 However, ITU-T participants are encouraged to bring their comments 787 and questions to the MPLS-TP mailing list directly, because this will 788 be more efficient and conforms to the normal IETF process. Comments 789 received in this way will be treated in the same way any as other 790 individual comments received on IETF documents. 792 3.2. Working Group Last Call and Document Approval 794 A working group last call is issued when a working group document is 795 close to being ready for publication as an RFC. The intention is to 796 make sure that there are no important pieces missing, that technical 797 details are correct, and that there is consensus within the working 798 group for moving forward. Consensus for MPLS-TP documents is judged 799 on the designated mailing list (normally the MPLS-TP mailing list) by 800 the chairs of the working group that has developed the document in 801 association with the MPLS-TP responsible working group chair. 803 During working group last call for all MPLS-TP documents the ITU-T 804 will always be consulted about the content of the documents. The 805 purpose of this step (step 9) is to ensure that the documents 806 address the needs and requirements of the ITU-T participants. 808 A formal communication will be made to the ITU-T to make it aware 809 that an IETF working group last call has been started and requesting 810 review and comment. According to the JWT decision, the ITU-T is 811 required to respond to a liaison about a working group last call 812 within the time set in announcing the working group last call. ITU-T 813 participants need to be aware that this step in the process 814 represents their last chance to influence the document from within 815 the ITU-T, and the liaison response needs to contain all issues and 816 comments - there will not be any scope to raise further concerns at a 817 later date. 819 The chair of an IETF working group that starts a working group last 820 call will send a liaison to the ITU-T announcing the working group 821 last call. A message will also be sent to the Ad Hoc Team on MPLS-TP 822 mailing list. 824 The IETF will make a best effort attempt to target the ITU-T Study 825 Groups and Questions that should be involved in responding to the 826 working group last call. However, the ITU-T must make sure that the 827 appropriate entities within the ITU-T participate in responding to 828 the working group last call. The ITU-T Ad Hoc Team on MPLS-TP 829 coordinates the development of the ITU-T response to the working 830 group last call. 832 The response to a working group last call should be unambiguous and 833 as detailed as possible. The liaison response is not intended to 834 start a conversation for clarification. It is intended to make clear 835 statements of technical issues to be addressed and to propose 836 resolutions for those issues. Acceptable responses include: 838 o No issues found. The ITU-T supports publication of the Internet- 839 Draft as an RFC in its current form. 841 o Minor issues found or questions raised. Please consider fixes to 842 these issues or respond to these questions before publication of 843 the Internet-Draft as an RFC. 845 o Major issues found. Please address these issues and allow the 846 ITU-T to review the resolution (possibly during a further working 847 group last call) before proceeding to publication of the Internet- 848 Draft as an RFC. 850 For the avoidance of doubt, the following guidance has been provided 851 by the ITU-T to its Rapporteurs: 853 During the final stages of development (e.g., Working Group last 854 call) the IETF will send a liaison to ITU-T for action. 856 At this stage the experts of the ITU-T must make a judgement if 857 the draft being reviewed is a suitable basis for a normative 858 reference from an ITU-T Recommendation. The group must reach a 859 consensus on this opinion. 861 A liaison to indicate support for the IETF to approve the draft 862 should contain the following text: 864 The experts of Qx have reviewed draft-xxxx by correspondence and 865 either: 867 - Have no concerns with the IETF proceeding with approval; 869 or 871 - Request that the following changes are made before the IETF 872 approves the draft. 874 Exceptionally, if consensus to support approval of the draft 875 cannot be reached, a response liaison must be sent indicating 876 that consensus could not be reached by correspondence and that 877 the matter will be addressed at the next SG (or interim) 878 meeting. 880 If the ITU-T is unable to reach consensus, the working group may 881 proceed to reach its own consensus on the document on the 882 understanding that it may be necessary to revise the document later 883 when ITU-T consensus is reached. 885 Note that, as described in Section 1.2, the cooperation process is 886 designed to ensure constructive consideration and resolution of all 887 issues raised by the ITU-T without blocking the progress of the 888 IETF's work on MPLS-TP. It is expected that discussion of major 889 issues raised at this stage of the process will be conducted on the 890 MPLS-TP mailing list and through appropriate communication with the 891 ITU-T. It is further expected that such issues will be resolved 892 through technical evaluation and rough consensus judged as normal for 893 the IETF process. In the event that agreement between the IETF and 894 ITU-T cannot be reached on some technical point, the JWT will be 895 convened to seek a resolution. 897 3.3. Non-Response to Liaisons 899 The liaison relationship between the IETF and the ITU-T is founded on 900 the understanding that each party will respond in a timely and 901 appropriate manner to the other party's liaisons so long as 902 reasonable notice is given. 904 Failure to respond by a deadline properly expressed in a liaison must 905 not be used to cause deadlock or to block advancement of work. Such 906 failures shall be assumed to represent accidental errors or 907 oversights and shall be brought to the attention of the management of 908 the body that has failed to respond. 910 In extreme cases, the JWT is empowered to convene itself to resolve 911 issues of failed communications. 913 4. Guidelines For MPLS-TP work in the ITU-T 915 These guidelines apply to progressing work on MPLS-TP in the ITU-T. 917 Any member of the ITU-T may send an MPLS-TP contribution to a ITU-T 918 Study Group or Question. 920 Before the ITU-T initiates any new work (i.e., items not previously 921 identified by the JWT) based on such contributions the ITU-T shall 922 send a liaison to the IETF. The message will go to the IETF 923 liaison to the ITU-T on MPLS, the MPLS-TP responsible working 924 group chair, and the MPLS-TP responsible AD. They are responsible 925 for sending a consolidated response from the IETF, but may 926 delegate the work of writing the response. 928 The IETF must respond to such liaisons according to the deadline 929 in the liaison. Acceptable responses include: 931 o Acknowledgement of receipt and agreement that the ITU-T is 932 clear to proceed with the work described. 934 o Request that the work described be transferred from the ITU-T to 935 the IETF in the form of an Internet-Draft to form part of the 936 MPLS-TP work in the IETF. 938 o Request that the work be put on hold until specific issues have 939 been resolved. In the event that this response is seen as 940 blocking of ITU-T work, the JWT may be convened to seek a 941 resolution. 943 Note that the process described in this section is conformant to the 944 Change Process for Multiprotocol Label Switching (MPLS) and 945 Generalized MPLS (GMPLS) Protocols and Procedures [RFC4929]. 947 5. IANA Considerations 949 There are no requests for IANA action in this document. 951 6. Security Considerations 953 This document defines a process adaptation for the cooperation 954 between the IETF and the ITU-T and thus does not introduce any new 955 security considerations. 957 The successful development of MPLS-TP standards that are consistent 958 across the industry is an essential component to ensuring the 959 security and stability of MPLS networks. 961 7. Acknowledgments 963 Thanks to Eric Gray who helped with grammar and useful comments. 964 Thanks to Tom Petch who spent time trying to sort out what the 965 document said, and who sent comments that helped clarify the 966 document. Thanks to the participants of ITU-T Study Group 15 who 967 provided review and comments on an early version of this text. 968 Thanks to Ben Niven-Jenkins for discussions. 970 8. References 972 8.1. Normative References 974 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 975 3", BCP 9, RFC 2026, October 1996. 977 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 978 Requirement Levels", BCP 14, RFC 2119, March 1997. 980 8.2. Informative References 982 [RFC4052] Daigle, L., Ed., and Internet Architecture Board, "IAB 983 Processes for Management of IETF Liaison Relationships", 984 BCP 102, RFC 4052, April 2005. 986 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 987 Handling Liaison Statements to and from the IETF", BCP 988 103, RFC 4053, April 2005. 990 [RFC4677] Hoffman, P. and Harris, S., "The Tao of IETF: A Novice's 991 Guide to the Internet Engineering Task Force", RFC 4677, 992 September 2006. 994 [RFC4929] Andersson, L. and Farrel, A., "Change Process for 995 Multiprotocol Label Switching (MPLS) and Generalized MPLS 996 (GMPLS) Protocols and Procedures", BCP 129, RFC4929, June 997 2007. 999 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 1000 Report on MPLS Architectural Considerations for a 1001 Transport Profile", RFC 5317, February 2009. 1003 [RFC5378] Bradner, S., and Contreras, J., "Rights Contributors 1004 Provide to the IETF Trust", BCP 78, RFC 5378, November 1005 2008. 1007 Authors' Addresses 1009 Loa Andersson 1010 Ericsson Inc 1012 Email: loa.andersson@ericsson.com 1014 David Ward 1015 Juniper Networks 1017 Email: dward@juniper.net 1019 Malcolm Betts 1021 Email: malcolm.betts@rogers.com 1023 Adrian Farrel 1024 Huawei Technologies 1026 Email: adrian.farrel@huawei.com