idnits 2.17.1 draft-andersson-rtg-gmpls-change-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1017. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1030. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6250 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 normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3356 (Obsoleted by RFC 6756) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Andersson (Editor) 2 Internet-Draft Acreo AB 3 Intended Status: Best Current Practice A. Farrel (Editor) 4 Expires September 2007 Old Dog Consulting 6 March 2007 8 Change Process for Multiprotocol Label Switching (MPLS) and 9 Generalized MPLS (GMPLS) Protocols and Procedures 11 draft-andersson-rtg-gmpls-change-08 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document provides guidelines for applying or extending the 39 MPLS or GMPLS ((G)MPLS) protocol suites and clarifies the IETF's 40 (G)MPLS working groups' responsibility for the (G)MPLS protocols. 41 This document is directed to multi-vendor fora and Standards 42 Development Organizations (SDOs) to provide an understanding of 43 (G)MPLS work in the IETF and documents the requisite use of IETF 44 review procedures when considering (G)MPLS applications or 45 protocol extensions in their work. This document does not modify 46 IETF processes. 48 Table of Contents 50 1. Introduction ................................................... 3 51 1.1 Document Source ............................................... 4 52 1.2 Conventions Used in this Document ............................. 4 53 2. Applicability of the (G)MPLS Change Process .................... 4 54 2.1 IETF Working Groups Developing (G)MPLS Technology ............. 5 55 2.1.1 Multiprotocol Label Switching Working Group ................. 5 56 2.1.2 Common Control & Measurement Plane Working Group ............ 5 57 2.1.3 MPLS and CCAMP Division of Work ............................. 6 58 2.2 Other (G)MPLS Technology Working Groups ...................... 6 59 2.3 Organizations Outside the IETF ............................... 7 60 3. Summary of Procedures .......................................... 7 61 4. MPLS and GMPLS Change Process ................................. 9 62 4.1 Flow Diagram ................................................ 10 63 4.2 Description of Process Stages ............................... 11 64 4.2.1 Preliminary Investigation .................................. 11 65 4.2.2 Requirements Statement Evaluation .......................... 12 66 4.2.3 Chartering or Rechartering the REWG ........................ 13 67 4.2.4 REWG Evaluation of the Requirements Statement I-D .......... 13 68 4.2.5 AD Evaluation of Completed Requirements Statement I-D ...... 13 69 4.2.6 IESG review of Requirements Statement I-D and PSWG Charter . 14 70 4.2.7 Solutions Work ............................................. 14 71 5. Rejecting the Requirements Statements I-D ..................... 15 72 5.1 Reasons for Rejection ........................................ 15 73 5.2 Actions Required When Rejecting Requirements Statement I-Ds .. 17 74 5.3 Appeals ...................................................... 17 75 6. Abandonment of the Solutions I-D .............................. 18 76 6.1 Appeals ...................................................... 18 77 7. (G)MPLS Integrity ............................................. 18 78 8. Security Considerations ...................................... 19 79 9. Acknowledgements ............................................. 19 80 10. IANA Considerations .......................................... 19 81 11. References ................................................... 20 82 11.1 Normative References ........................................ 20 83 11.2 Informative References ...................................... 20 84 12. Editors' Addresses ........................................... 20 85 13. Authors' Addresses ........................................... 21 87 1. Introduction 89 The MPLS and GMPLS technology is developed in two main tracks in the 90 IETF. "MPLS" refers to the work done for packet switched networks, 91 while "GMPLS" refers to the efforts to apply the MPLS protocols to 92 all types of networks including packet and non-packet technologies. 94 Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" 95 is used in this document to indicate both of these tracks. A 96 terminology section that covers the use of terms and concepts used in 97 this document is found in Section 2.6. 99 [RFC4775] discusses procedural issues related to the extension or 100 variation of IETF protocols by other SDOs. It provides the guidelines 101 and procedures to be used by other SDOs when considering requirements 102 for extensions to IETF protocols. [RFC4775] recommends that major 103 extensions to, or variations of, IETF protocols only take place 104 through normal IETF processes or in coordination with the IETF. 106 The (G)MPLS protocol families were developed within the IETF and 107 constitute significant protocol suites within the Internet standards. 108 The (G)MPLS suites of protocols have become popular for a number of 109 new applications and deployment scenarios. There have been concerns 110 with regards to other technology fora developing, using, and 111 publishing non-standard protocol extensions as a standard not only 112 for use within their community, also for wider use by the industry. 113 Especially concerning is development of extensions, without 114 consulting the (G)MPLS working groups, which are in conflict with 115 efforts on-going in the (G)MPLS working groups, and then presented to 116 the (G)MPLS working group as 'fait accompli'. 118 The definition and publishing of non-standard extensions by other 119 fora, without IETF review and outside of the IETF publication 120 process, regardless if rationalized as limited to use among fora 121 vendors, or limited to a particular application, or rationalized as 122 allowing timely demos, has the unfortunate potential to hinder 123 interoperability and increase complexity of the protocol, sows 124 confusion in the industry, and circumvents the Internet standards 125 process that exists to ensure protocol implementability. As described 126 in [RFC4775], non-standard extensions, including experimental values, 127 are not to be portrayed as industrial standards whether by an 128 individual vendor, an industry forum, or a standards body. 130 This document clarifies the IETF's MPLS and Common Control and 131 Measurement Plane (CCAMP) working groups' roles and responsibilities 132 for the (G)MPLS protocols and documents the requisite use of, and how 133 to apply, the [RFC4775] procedure of using the IETF review processes, 134 [RFC2026] and [RFC2418], for fora wishing to apply or extend the 135 (G)MPLS protocols. Use of the IETF review processes will ensure an 136 open process for protocol development and ensure a non-harmful 137 evolution for these IETF protocols, which will benefit the larger 138 industry users' community. IETF itself can not enforce a forum to use 139 the (G)MPLS change procedure, though any forum not following it, when 140 applying for IANA assignment or IETF publication, will be delayed, 141 until this procedure has been completed. 143 This document does not change the formal IETF standards process as 144 defined in [RFC2026] and [RFC2418]. It is consistent with the general 145 procedures for protocol extensions defined in [RFC4775] and shows how 146 they are applied in the case of (G)MPLS. Any procedures described in 147 this document are to be implemented in a way consistent with these 148 three documents. They MUST be used when other SDOs and fora wish to 149 propose (G)MPLS changes. They SHOULD be used internally within the 150 IETF unless the changes concerned are considered non-controversial by 151 the responsible Area Director(s) (e.g. covered by the working group 152 charter), in which case other aspects of the normal IETF standards 153 process cover the necessary procedures. 155 1.1 Document Source 157 This document is the joint work of the IETF Routing Area Directors, 158 the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaisons 159 to the ITU-T. It had considerable review and comment from key 160 members of the ITU-T who have given their time and opinions based on 161 experience for which the authors are grateful. The IESG has also 162 provided valuable input to arrive at the process documented here. The 163 acknowledgements section lists those whose contributions have been 164 particularly helpful. 166 1.2 Conventions Used in this Document 168 Although this document is not a protocol definition, the key words 169 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 170 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 171 are to be interpreted as described in RFC 2119 [RFC2119]. This usage 172 is chosen to make the steps and procedures completely clear. 174 2. Overview of (G)MPLS within the IETF 176 This section describes the key IETF working groups developing the 177 (G)MPLS technology and provides information on IETF working groups 178 using the (G)MPLS technology. 180 It should be remembered that the IETF environment is highly dynamic. 181 Working groups and whole areas come and go. The overview of the 182 relevant working groups within the IETF is only a snapshot in time. 184 2.1 IETF Working Groups Developing (G)MPLS Technology 186 Two working groups in the IETF's Routing Area are responsible 187 for work related to developing the (G)MPLS technologies: 188 Multiprotocol Label Switching (MPLS) working group and the Common 189 Control and Measurement Plane (CCAMP) working group. 191 The following sections provide brief overviews of the chartered work 192 of these two IETF working groups. 194 2.1.1 Multiprotocol Label Switching Working Group 196 The Multiprotocol Label Switching (MPLS) working group is responsible 197 for standardizing the base technology that uses label switching, and 198 for describing the implementation of Label Switched Paths (LSPs) over 199 various packet and frame-based link level technologies. The working 200 group charter includes procedures and protocols for the distribution 201 of labels between routers, as well as encapsulations, operation and 202 management, traffic engineering, and multicast considerations. 204 This document assumes that the MPLS working group remains the 205 chartered authority on MPLS technologies, but notes that the IETF may 206 appoint another working group (refer to [RFC2418])) to handle 207 specific extensions or changes to the protocols. Further, in the 208 event that the MPLS working group completes its work and is closed, 209 the IETF will use the non-working group standards track document 210 process (described in [RFC2026]) using designated experts from the 211 community [RFC2434] for the MPLS protocols. 213 2.1.2 Common Control & Measurement Plane Working Group 215 The IETF Common Control and Measurement Plane (CCAMP) working group 216 coordinates the work within the IETF defining common control and 217 measurement planes for ISP and SP core tunneling technologies. This 218 includes, but is not limited to, defining signaling protocols and 219 measurement protocols such that they support multiple physical path 220 and tunnel technologies using input from technology-specific working 221 groups such as the MPLS working group. It also includes the 222 development of protocol-independent metrics and parameters for 223 describing links and paths that can be carried in protocols. 225 The technology that the CCAMP working group focuses on is called 226 Generalized MPLS (GMPLS), indicating that CCAMP addresses a 227 generalized technology, where labels are defined in such a way that 228 they will be compatible with the technology over which the data is 229 transported. While the MPLS working group focuses on packet- and 230 frame-switched technologies, the CCAMP working group work focuses on 231 common methods across a broad spectrum of switching technologies 232 including packet and frame technologies. In this respect, GMPLS can 233 be viewed as a superset of MPLS. 235 The procedures in this document assume that the CCAMP working group 236 remains the authority on GMPLS technologies, but acknowledges that 237 the IETF may appoint another working group (refer to [RFC2418]) to 238 handle specific extensions or changes to the protocols. Further, in 239 the event that the CCAMP working group completes its work and is 240 closed, the IETF will use the non-working group standards track 241 document process (described in [RFC2026]) using designated experts 242 from the community [RFC2434] for the GMPLS protocols. 244 2.1.3 MPLS and CCAMP Division of Work 246 From time to time, the MPLS and CCAMP working groups decide to divide 247 work between themselves in a way that does not strictly follow the 248 split between the working groups as defined in the working group 249 charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS 250 working group is specifying requirements and base technology for all 251 of the (G)MPLS technologies. 253 An entity or individual that wishes to propose extensions or changes 254 to (G)MPLS should first decide to which working group (MPLS or CCAMP) 255 it will bring the proposal. However, the MPLS and CCAMP working group 256 chairs, in conjunction with their Area Directors, may redirect the 257 proposal to another working group. 259 2.2 Other (G)MPLS Technology-Related Working Groups 261 Problem statements and requirements for (G)MPLS technology have been 262 produced by several working groups in addition to the MPLS and CCAMP 263 working groups. IETF working groups are defined for management of 264 specific tasks by their charter. Their charter defines their role, 265 relationship with other working groups, and the applicable procedures 266 to follow when extensions to (G)MPLS may be needed. This section 267 provides an overview of the (G)MPLS related groups and their 268 responsibilities. Additional information describing the working 269 groups and their charters is available on the IETF web pages. 271 The IP over Optical (IPO) working group and the Internet Traffic 272 Engineering working group (TEWG) are examples of working groups which 273 focus on problem statements and requirements for (G)MPLS to be 274 considered by the (G)MPLS working groups. These working groups have 275 not specified any protocols. 277 The Bidirectional Forwarding Detection (BFD) working group, also may 278 use the (G)MPLS protocols and mechanisms. The BFD working group is 279 chartered for requirements evaluation and protocol specification 280 related to BFD. If the working group needs to extend or change the 281 (G)MPLS protocols, the procedures specified by its charter and the 282 IETF's standard processes are applicable. 284 The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have 285 been chartered to specify a limited number of solutions for Provider 286 Provisioned VPNs. Both working groups are in the Internet Area. The 287 work of the L2VPN and L3VPN working groups does not include 288 specifying new protocols or extensions to existing protocols. If 289 extensions are needed, the procedures as specified by their charters 290 and the IETF's standard processes are applicable. 292 The Layer 1 VPN (L1VPN) working group is chartered to specify 293 mechanisms necessary for providing Layer 1 VPN services 294 (establishment of layer 1 connections between CE devices) over a 295 GMPLS-enabled transport service-provider network. Protocol extensions 296 required for L1VPN will be done in cooperation with MPLS, CCAMP, 297 OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the 298 L1VPN working group will not develop GMPLS protocol extensions in 299 isolation, but will develop requirements and propose extensions that 300 will be reviewed and approved by the (G)MPLS working groups. 302 The Pseudo Wire Emulation End to End (PWE3) working group is a 303 working group thatmay use the (G)MPLS protocols in its 304 specifications. Should the PWE3 specifications require extension or 305 changes to the (G)MPLS protocols, the procedures as specified by 306 its charter and the IETF's standard processes are applicable. 308 2.3 Organizations Outside the IETF 310 A number of standards development organizations (SDOs) and industrial 311 forums use or reference the (G)MPLS protocols in their 312 specifications. Some of these organizations have formal or informal 313 liaison relationships with the IETF [RFC4052]. The IETF exchanges 314 information with these organizations about what is happening on both 315 sides, including plans and schedules, using liaison statements 316 [RFC4053]. More details about the cooperation relationship between 317 the IETF and the ITU-T can be found in [RFC3356]. 319 The procedures in this document are applicable to all organizations 320 outside the IETF whether or not they have formal liaison 321 relationships with the IETF. If any organization outside the IETF 322 has a requirement for extensions or modifications to the (G)MPLS 323 protocols then the procedures in this document apply. 325 3. Overview of (G)MPLS Change Process 327 This is a non-normative section as it is intended to provide a high- 328 level view of [RFC4775] procedures for protocol extensions. 329 Application of these procedures for (G)MPLS are defined in detail in 330 Section 4. 332 Whenever there is reason to believe that a particular problem may be 333 solved by use of or extensions to the (G)MPLS protocols, a 334 communication using the formal liaison process, or, for a forum 335 without a formal relationship, an informal communication, may be used 336 to discuss the problem with the IETF ([RFC4052] and [RFC4053]). 337 Collaboration with IETF in the early discussion phase will facilitate 338 a timely understanding of whether the problem has already been 339 solved, may be outside the scope of the (G)MPLS protocols, or may 340 require more investigation. 342 Whenever any extension or change to the (G)MPLS protocols is desired, 343 a problem statement and/or requirements statement must be produced 344 and must be submitted to IETF as an Internet-Draft. When the 345 requirements come from an external organization, informal 346 communications, such as e-mail to working group mailing lists, is 347 strongly encouraged as it facilitates timely and cooperative work. 348 However, if desired, the Internet-Draft, containing the 349 requirement(s), may be submitted to the working group using a formal 350 liaison statement. IETF's response to the request will be given as a 351 reply to the liaison. This use of formal communication reduces the 352 risk of confusing an individual participant's opinion for that of the 353 group as can happen on mailing lists, though it does introduce a more 354 lengthy communication cycle. If there is no formal liaison 355 relationship, a communication may be sent directly to the (G)MPLS 356 working group, a relevant Area Director, or the IESG. 358 The IETF, through the appropriate Area Director, and the chairs of 359 the MPLS and CCAMP working groups for (G)MPLS related work, will 360 direct the requirements draft to an appropriate working group for 361 assessment and comment. This process may require communication and 362 discussion for clarification, but the IETF undertakes to perform the 363 assessment in a timely manner. 365 In assessing the requirements statement I-D, the IETF may determine: 367 - that the requirements can be satisfied without modifications to the 368 (G)MPLS protocols 370 - that the requirements are not sufficiently general or there is not 371 sufficient interest to do a standards-track solution to warrant a 372 Standards-track change to the (G)MPLS protocols 374 - that the requirements justify a standards-track change to the 375 (G)MPLS protocols 377 - that the requirements might not be possible to satisfy without 378 violating the (G)MPLS architecture in a way that would harm the 379 (G)MPLS technology 381 - that the requirements should be combined with other requirements 382 to solve a more general problem or solve the same problem in a more 383 flexible way. 385 In the event that the IETF agrees to develop a solution, the IETF 386 will set milestones that would result in timely delivery of the 387 solution in a timely manner. If the IETF rejects the requirements, 388 this will only be done with clear explanation and full discussion 389 with the source of the requirements. 391 The solutions that are developed within the IETF may be sourced from 392 external organizations and presented for review, discussion, 393 modification, and adoption as Internet-Drafts. Such solutions drafts 394 may be presented to the IETF in advance of the completion of the 395 requirements work, but all solutions will be processed through the 396 normal IETF process with other proposed solutions. Solution drafts 397 are adopted as an IETF working group draft when the requirements are 398 stable, and not before the protocol-responsible working group has a 399 charter item to cover the solutions work. It is strongly recommended 400 for interested parties to start informal discussion in the IETF, as 401 early as possible, and to co-author in the IETF's work. It is not 402 recommended for the source forum to continue to work on solutions in 403 parallel with on-going work in the IETF. If the protocol-responsible 404 working group is unable to accept the work (e.g., due to current work 405 load), IETF processes ([RFC2418]) provide alternate options for 406 ensuring the work is completed. 408 4. MPLS and GMPLS Change Process 410 This section defines the (G)MPLS change process and the rules that 411 must be followed in order to make extensions or changes to the 412 (G)MPLS protocols. The language of [RFC2119] is used in order to 413 clarify the required behavior of the IETF and the originator of the 414 change request. It is consistent with the general procedures for 415 protocol extensions defined in [RFC4775]. Any interpretation of 416 procedures described in this document and their implementation are to 417 be in a way consistent with [RFC4775]. 419 Anyone who intends to use one of the existing (G)MPLS protocols, but 420 thinks that it will not satisfy their needs MUST use the procedures 421 described in this document. They SHOULD be used internally within the 422 IETF unless the changes concerned are considered non-controversial by 423 the responsible Area Director(s) (e.g., covered by the working group 424 charter), in which case other aspects of the normal IETF standards 425 process apply. Changes or extensions to the (G)MPLS protocols MUST 426 NOT be made by any other mechanism. The IETF MUST NOT endorse any 427 publications (including RFCs whether on the Standards Track, 428 Informational, or Experimental) that change or extend the (G)MPLS 429 protocols except for those that arise through the correct execution 430 of the procedures in this document. The IETF MUST NOT endorse any 431 IANA action that allocates (G)MPLS protocol codepoints except as a 432 result of actions arising from the correct execution of the 433 procedures in this document. 435 4.1 Flow Diagram 437 Figure 1 gives a visual overview to illustrate the roles of a (G)MPLS 438 requirements evaluation working group (REWG) and (G)MPLS protocol 439 solutions working group (PSWG). The figure presents two alternatives 440 for a requestor: (1) contact the IETF early in the problem definition 441 phase (preliminary investigation), or, (2) later, with a requirements 442 statement. The figure is for illustration only; it does not contain 443 all of the possible interactions and IETF procedure alternatives. The 444 text in the subsequent sections describes the process. 446 Start +-------------+ 447 | |optional | 448 +--<--------------------|preliminary |<-------Start 449 | |investigation| 450 V +-------------+ 451 +------------+ +---------+ +---------+ 452 |requirements| discussion |review by| YES | IESG | YES 453 |statement |----------->|WG chairs|------------->|decision |------+ 454 |I-D | on mailing |and ADs | request to | | | 455 +------------+ list +---------+ IESG to +---------+ | 456 | appoint REWG | | 457 |NO and charter |NO REWG| 458 V req eval | chartered| 459 +-------------+ | to work on| 460 |response | | requirements| 461 |to the | | statement| 462 |requirements |<-----------------+ | 463 +->|statement |<----------------+ | 464 | +-------------+ | | 465 | ^ | | 466 NO| | NO | | 467 | +-----------------+ | V 468 | | | NO +------+ 469 +--------+ +-------+ +--------| REWG | 470 | IESG/ | YES | AD | | req | 471 +-----------|decision|<---------------|review |<------------| eval | 472 |PSWG | | request to | | YES | | 473 |chartered +--------+ IESG to +-------+ +------+ 474 |to work approve I-D 475 | and charter 476 | PSWG (if needed) 477 | +---------+ 478 | | IETF | +-----+ 479 +--------->| PSWG |-----/ /---->| RFC | 480 +---->| process | +-----+ 481 | +---------+ 482 solutions 483 I-D 484 Figure 1: Change Process Overview 486 4.2 Description of Process Stages 488 This section describes how the (G)MPLS change process works, what is 489 expected from individuals or organizations that want to extend or 490 change the (G)MPLS protocols, and the responsibilities of the IETF. 492 4.2.1 Preliminary Investigation 494 This step is OPTIONAL, and is intended to provide a lightweight way 495 to "feel out" the IETF's position on a proposal without going to the 496 effort of writing an Internet-Draft. The intention is to determine 497 whether the problem has been examined already, whether the problem is 498 in scope for the IETF, and whether solutions are already known. 500 Although the preliminary investigation phase is optional it is 501 RECOMMENDED that the originator of any requirements consult and 502 discuss the issues concerned as early as possible to avoid any wasted 503 effort, and the preliminary investigation phase provides a mechanism 504 to do this. 506 Useful discussions may be held at this stage in order to ensure that 507 the problem statement and requirements statement Internet-Drafts 508 contain the right material. This step is described as lightweight 509 because no Internet-Draft is required and because the step largely 510 involves offline discussions. However, it may be the case that this 511 step involves considerable technical discussions and may, in fact, 512 involve an extensive, substantive exchange of ideas and opinions. 514 This step SHOULD be carried out informally on the mailing list of the 515 REWG or on the Routing Area discussion mailing list, and MAY be 516 initiated by any individual, group of individuals, external 517 organization, or IETF working group. 519 When an external SDO has a liaison relationship with the IETF, it 520 MAY carry out this step using a formal liaison. The liaison SHOULD be 521 sent to the designated liaison manager who is responsible for 522 forwarding them to the IESG who will assign a Responsible AD. The 523 initiators of the liaison SHOULD make themselves available for 524 discussion on the selected mailing list. If a formal liaison is used, 525 the IETF will respond using the procedures of [RFC4053]. 527 At this stage, a problem statement I-D MAY be produced to help 528 further the discussions and to clarify the issues being addressed. 530 A possible outcome of this preliminary investigation is that the 531 requirements and problem are understood, but agreed to be out of 532 scope for the IETF. Alternatively it may be that the problem can be 533 solved with existing protocols. The full list of outcomes from the 534 preliminary investigation phase are similar to those for the 535 requirements statement evaluation phase described in section 4.2.2, 536 but the requirements statement evaluation phase which allows wider 537 IETF community participation in developing a complete requirement set 538 MUST form part of the process if the IETF is to consider to develop 539 protocol solutions. The process cannot move direct from the 540 preliminary investigation phase to the development of solutions 541 unless the working group agrees (e.g., the problem is minor). 543 4.2.2 Requirements Statement Evaluation 545 Before the IETF can formally pronounce on requests to change or 546 extend the (G)MPLS protocols, a requirements statement I-D MUST be 547 written per [RFC2026]. 549 The requirements statement I-D MUST be introduced by the authors to 550 the IETF through an email to the REWG mailing list, or to the Routing 551 Area discussion mailing list, or by a formal liaison from an external 552 SDO which will result in the IETF introducing the requirements 553 statement I-D to the REWG mailing list. If the requirements statement 554 I-D is brought to the IETF through a formal liaison, the initiators 555 of the liaison SHOULD make themselves available for discussion on the 556 designated IETF mailing lists. 558 After discussion on the IETF mailing lists, the responsible Area 559 Director MUST decide whether the requirements will be formally 560 evaluated by the IETF, and MUST deliver a response to the per 561 [RFC4053] and [RFC4775]. If a formal liaison was not used, the 562 response SHOULD be delivered to the appropriate contact as listed on 563 the communication. 565 The IETF response MUST be sufficiently explanatory to inform the 566 requesting organization of what, if anything, the IETF has decided to 567 do in response to the request. The following list is provided to 568 illustrate possible responses: 570 a. Requirements not understood. Further discussion required. 572 b. Requirements understood, but judged to be out of scope for the 573 IETF. In this case, the originator of the requirements can work 574 on requirements and solutions and will not be impeded by the 575 IETF. The IETF may request to be kept informed of progress. 577 c. Requirements understood, but no protocol extensions are needed. 578 It may be desirable for the external SDO to cooperate with the 579 an IETF working group in the production of an Applicability 580 Statement Internet-Draft. 582 d. Requirements understood, and the IETF would like to develop 583 protocol extensions. This results in execution of the rest of the 584 procedure, described below. The requirements raised in the 585 requirements statement I-D may be combined with other 586 requirements to produce more general extensions or changes to the 587 (G)MPLS protocols. 589 4.2.3 Working Group Procedures 591 In many cases the problem covered by the requirements statement I-D 592 will fall within the scope of the existing charter of a working 593 group. In this case, the responsible Area Directors will designate 594 the working group as the REWG and pass the requirements statement I-D 595 to the working group for evaluation. If the problem is not covered by 596 an existing charter, other alternatives (refer to [RFC2418]) may be 597 used, e.g. rechartering, BOF, chartering a new working group. 599 If the IETF modifies its prior decision to accept the work, the IETF 600 MUST communicate this to the requestor in a timely manner. 602 4.2.4 REWG Evaluation of the Requirements Statement I-D 604 The objective of the REWG evaluation process is to determine a clear 605 and complete statement of the requirements for changes or extensions 606 to the (G)MPLS protocols. This will necessitate normal IETF working 607 group procedures in the REWG and MAY include the generation of 608 revisions of the requirements statement I-D in cooperation between 609 the members of the REWG and the original authors of the requirements 610 statement I-D. 612 The originators of the requirements statement I-D MUST make 613 themselves available to discuss the work on the REWG mailing list. 614 If this does not happen, the chairs of the REWG MAY determine that 615 there is insufficient support for the work and MAY reject the 616 requirements statement I-D. 618 The output of the REWG will be either: 620 - a completed requirements statement I-D that has been accepted by 621 working group consensus within the REWG and has passed through 622 working group last call; 624 or: 626 - a rejection of the requirements using the response procedure as 627 described in Section 5. 629 4.2.5 AD Evaluation of Completed Requirements Statement I-D 631 As with all Internet-Drafts produced by a working group, the ADs will 632 review the completed requirements statement I-D produced by the REWG. 633 The ADs will then pass the document to the IESG for review. If 634 charter changes are needed or a new PSWG needed, the appropriate 635 process will be followed. 637 4.2.6 IESG review of Requirements Statement I-D and PSWG Charter 639 As with all Internet-Drafts, the IESG will review and make a decision 640 on the progression of the requirements statement I-D. 642 If the IESG rejects the requirements statement I-D, it will generate 643 an appropriate response to the working group (and, if needed, to the 644 originator of the request). 646 The IESG will review any proposed charter changes for the PSWG or, if 647 needed, consider alternatives. This might include the formation of a 648 new working group specifically to work on the solutions. 650 4.2.7 Solutions Work 652 The appropriate PSWG will start work on solutions following the 653 normal IETF process. 655 Solutions I-Ds MAY be prepared externally (such as within an external 656 organization) or within the IETF, submitted to the IETF for draft 657 publication using the procedures of [RFC2418], and introduced to the 658 PSWG for consideration. Such I-Ds MAY be submitted at earlier stages 659 in the process to assist the REWG in its development and discussion 660 of the requirements, but no I-D will be formally considered as a 661 solutions I-D until the PSWG has a charter item that covers the work 662 and the REWG chairs are confident that the requirements are stable. 664 The IETF makes no guarantees that an externally produced solutions 665 I-D will form the basis of the PSWG solutions I-D, but the PSWG MUST 666 consider such an I-D for review and revision as a possible solution 667 I-D, using the same open procedures ([RFC2418]) as for any individual 668 submission. The IETF's procedures are based on open and fair 669 participation, and thorough consideration of technical alternatives. 671 Interested parties (both implementers and users) of the SDO 672 originating the request are strongly encouraged to participate in the 673 PSWG to ensure appropriate interest is shown in the solutions work 674 and to provide timely solutions development. The IETF's work, as that 675 of any SDO, is driven by its participants. The IETF is an open 676 community and any SDO requesting IETF solutions work SHOULD ensure 677 appropriate industry interest in the work, or the IETF MAY 678 discontinue its support of the work. Appropriate communication of the 679 discontinued work will be made to the originator of the request (if 680 the originator is reachable). 682 The final development of the solutions I-D is subject to the normal 683 working group review, consensus, and last call within the PSWG. 685 Where the requirements originated from an external organization, the 686 PSWG SHOULD regularly communicate its progress using a formal liaison 687 process if one exists. This communication SHOULD also be used to 688 request review input and comment on the development of the solutions 689 I-D. The solutions I-D MUST be communicated to the originating 690 organization during working group last call for final review against 691 the requirements. When the solutions I-D is complete (normally upon 692 completing working group last call and/or on entering the RFC 693 Editor's queue) the PSWG MUST inform the originating organization of 694 the completed solution. 696 5. Rejecting the Requirements Statements I-D 698 Rejection of the requirements statements is a sensitive matter for 699 the authors of the requirements and MUST be handled with full 700 disclosure and explanation by the IETF. All working group actions are 701 taken in a public forum ([RFC2418]). 703 The requirements can be rejected at various stages of the process as 704 described in the previous sections. The person or group that makes 705 the rejection is responsible for generating an explanation of the 706 rejection and MUST follow the [RFC4775] process. Possible reasons for 707 rejection are described in this section. 709 5.1 Reasons for Rejection 711 The requirements statement I-D can only be rejected with full 712 disclosure by the IETF.. Possible reasons for rejection and possible 713 next steps as described here. 715 - Requirements not understood. Either during preliminary 716 investigation or during evaluation of the requirements statement 717 I-D, it wasn't clear what the requirements are, or what the problem 718 being addressed is. 720 This rejection forms part of an on-going communication and it is 721 expected that the process will continue with further iterations. 723 - Out of scope for the IETF. Many stages of this process may 724 determine that the requirements are out of scope for the IETF. In 725 this case, the IETF MUST NOT constrain the authors of the 726 requirements statement I-D from working on a solution. If any 727 (G)MPLS changes are later identified, the requestor MUST 728 re-initiate the (G)MPLS change procedure. 730 - No protocols extensions or changes are needed. At some stage in the 731 evaluation of the requirements it may become clear that they can 732 all be met through appropriate use of existing protocols. In this 733 case no further evaluation of the requirements is required, but the 734 REWG MUST explain how the protocols can be used to meet the 735 requirements and MAY cooperate with the authors of the requirements 736 statement I-D in the production of an Applicability Statement 737 Internet-Draft or a Profiles Internet-Draft that explains precisely 738 how the existing protocols can be used to meet the requirements. 740 - Insufficient support within the IETF. Although the work described 741 within the requirements statement I-D is within scope for the IETF, 742 and despite the support of the originators of the requirements 743 statement I-D on the REWG mailing list, the chairs of the REWG have 744 determined that there is insufficient support in the REWG to 745 complete requirements statement I-D and initiate solutions work in 746 the PSWG. In this case, the IETF MUST NOT restrict the authors of 747 the requirements statement I-D from working on a solution. The 748 solution (and/or IANA codepoints requested) SHALL be presented to 749 the IETF's (G)MPLS PSWG for review and possible publication as an 750 Informational or Experimental RFC, and, pending IETF review 751 results, the IETF SHALL NOT block applications to IANA for 752 codepoints. If IANA codepoint assignments are required, the IANA 753 Requirements prescribed for those assignments in the relevant RFCs 754 MUST be satisfied. It is highly recommended for the SDO to 755 encourage its participants to participate in the IETF work to 756 ensure appropriate industry representation in the work. 758 - Insufficient support for the work from the original requesters. If 759 the authors of the requirements statement I-D do not make 760 themselves available on the REWG mailing list for discussion of the 761 requirements or do not contribute the completion of the 762 requirements statement I-D, the chairs of the REWG MAY determine 763 that there is insufficient support for the work and MAY reject the 764 requirements statement I-D. In this case, the IETF MUST NOT grant 765 permission for the work to be carried out in any other 766 organization, and MUST NOT endorse the publication of any changes 767 or extensions to the (G)MPLS protocols and MUST NOT instruct IANA 768 to allocate any codepoints. The requirements may be re-introduced 769 by starting the procedure again from the top. 771 - Satisfying the requirements would break the technology. It is 772 possible that an assessment will be made that, although the 773 requirements are reasonable, it is not possible to satisfy them 774 through extensions or changes to the (G)MPLS protocols without 775 violating the (G)MPLS architecture in such a way as would break the 776 (G)MPLS technology. In this case a recommendation will be made that 777 some other technology be used to satisfy the requirements. See 778 Section 7 for further discussions of the protection of the 779 integrity of the (G)MPLS technology. In this case, the IETF MUST 780 NOT grant permission for the work to be carried out in any other 781 organization, and MUST NOT endorse the publication of any changes 782 or extensions to the (G)MPLS protocols and MUST NOT instruct IANA 783 to allocate any codepoints. 785 5.2 Actions Required When Rejecting Requirements Statement I-Ds 787 Upon rejection, the IETF MUST make a clear statement of why the 788 requirements statement I-D has been rejected and what next step 789 actions are acceptable (refer to Section 5.1). 791 The communication of the rejection depends on the form of the 792 original submission as follows. 794 - If the requirements are brought to the IETF as a preliminary 795 investigation (see Section 4.2.1) through an email exchange then 796 the response MUST be made as an email response copied to an IETF 797 mailing list so that it is automatically archived. 799 - If the requirements are brought to the IETF as a preliminary 800 investigation (see Section 4.2.1) through a formal liaison, the 801 rejection MUST be delivered through a formal liaison response. 803 - If a requirements statement I-D has been produced and discussed on 804 an IETF email list, the response MUST be made as an email response 805 and copied to the email list. 807 - If a requirements statement I-D has been produced and brought to 808 the IETF through a formal liaison, the rejection MUST be delivered 809 through a formal liaison response. 811 - If an IETF working group has been involved in the review or 812 production of any Internet-Drafts for the requirements or for the 813 solutions, the working group MUST be notified of the rejection and 814 the reasons. 816 The responsibility for the generation of the response lies with the 817 person, people, or group that instigates the rejection. This may 818 be the IESG, one or more Area Directors, one or more working group 819 chairs, or a designated expert [RFC2434]. In the case of the use of a 820 liaison relationship, the IETF's liaison manager has responsibility 821 for ensuring that the procedures in this document, and particularly 822 the rejection procedures, are followed. 824 5.3 Appeals 826 [RFC2026] contains additional information related to procedure 827 disagreements and appeals. The rejection of a requirements statement 828 I-D as described in Sections 5.1 and 5.2 may be appealed in the event 829 it is disputed and cannot be reversed by direct discussion between 830 the parties. The conflict resolution and appeal mechanism is 831 documented in [RFC2026]. 833 6. Abandonment of the Solutions I-D 835 Once the solutions work has been started by the PSWG, it may be 836 abandoned before completion. This can happen if the PSWG chairs 837 determine that there is no longer working group support for doing the 838 work. This could arise, for example, if no-one (including the 839 originators of the requirements statement I-D) is willing to 840 contribute to the development of a solutions I-D. 842 In the event that the solutions work is abandoned by the PSWG, the 843 Area Directors responsible for the PSWG MUST be consulted. The 844 originators of the requirements statement I-D MUST be informed that 845 the work has been abandoned using a mechanism dependent on how the 846 requirements were introduced (as discussed in Section 5.2). 848 If the solution is abandoned in this way, work on solutions for the 849 requirements MUST NOT be started in another forum. The status of 850 extensions and changes to the (G)MPLS protocols with regard to the 851 specific requirements returns to how it was before the process 852 started. Any new examination of the requirements MUST commence at the 853 top of the process. 855 6.1 Appeals 857 The abandonment of a solutions I-D may be appealed in the event it is 858 disputed and cannot be reversed by direct discussion between the 859 parties. The conflict resolution and appeal mechanism is documented 860 in [RFC2026]. 862 7. (G)MPLS Integrity and Ownership 864 The (G)MPLS working groups are REQUIRED to protect the architectural 865 integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS 866 architecture with features that do not have general use beyond the 867 specific case. They also MUST NOT modify the architecture just to 868 make some function more efficient at the expense of simplicity or 869 generality. 871 The architectural implications of additions or changes to the (G)MPLS 872 protocols MUST consider interoperability with existing and future 873 versions of the protocols. The effects of adding features that 874 overlap, or that deal with a point solution and are not general, are 875 much harder to control with rules and risk impacting the protocol as 876 a whole. Therefore to minimize operational and technical risks to the 877 (G)MPLS technology, IETF processes SHALL be followed for any requests 878 on extensions to (G)MPLS protocols. With respect to (G)MPLS 879 protocols, the (G)MPLS PSWG is the chartered "owner" of the (G)MPLS 880 protocol, as long as the working group exists. All changes or 881 extensions to (G)MPLS MUST first be reviewed by the (G)MPLS PSWG. 883 8. Security Considerations 885 All requirements statement I-Ds MUST give full consideration to the 886 security impact of the proposed additional features or functions. All 887 solutions I-Ds MUST consider the impact on the security of the 888 protocol extensions and to the pre-existing protocol. 890 This documents does not itself introduce any security issues for any 891 (G)MPLS protocols. 893 The IETF process is itself at risk from denial of service attacks. 894 This document utilizes the IETF process and adds clarity to that 895 process. It is possible, therefore, that this document might put the 896 IETF process at risk. 898 Therefore, provided that the number of requirements statement I-Ds is 899 not unreasonable, there will be no significant impact on the IETF 900 process. The rate of arrival of requirements statement I-Ds MAY be 901 used by the IESG to detect denial of service attacks, and the IESG 902 SHOULD act on such an event depending on the source of the 903 requirements statement I-D and the perceived relevance of the work. 904 The IESG might, for example, discuss the issue with the management of 905 external organizations. 907 9. Acknowledgements 909 The input given by Bert Wijnen has been useful and detailed. 911 Review feedback and discussions with various members of the ITU-T has 912 been helpful in refining the process described in this document. 913 Thanks in particular to the members of Question 14 of Study Group 15, 914 and to the management of Study Group 15. Important discussions were 915 held with the following participants in the ITU-T: Yoichi Maeda, 916 Greg Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, George 917 Newsome, Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, and 918 Ben Mack-Crane. 920 Thanks for further review comments to Brian Carpenter, Stewart 921 Bryant, Sam Hartman, Mark Townsley, and Dave Ward. Thanks to Spencer 922 Dawkins for the GenArt review. 924 10. IANA Considerations 926 This document makes no specific requests to IANA for action. The 927 procedures described in this document assume that IANA will adhere to 928 the allocation policies defined for the (G)MPLS codepoint registries 929 and that the IETF will not endorse allocation of codepoints from 930 those registries except where work has been carried out in accordance 931 with the procedures described in this document. 933 11. References 935 11.1 Normative References 937 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 938 3", BCP 9, RFC 2026, October 1996. 940 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 941 Requirement Levels", BCP 14, RFC 2119, March 1997. 943 [RFC2418] Bradner, S., "IETF Working Group - Guidelines and 944 Procedures", BCP 25, RFC 2418, September 1998. 946 [RFC2434] Narten, T. and Alvestrand, H. "Guidelines for Writing an 947 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 948 October 1998 950 [RFC4052] Daigle, L., "IAB Processes for Management of IETF Liaison 951 Relationships", BCP 102, RFC 4052, April 2005. 953 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 954 Handling Liaison Statements to and from the IETF", 955 BCP 103, RFC4053, April 2005. 957 [RFC4775] Bradner, S., and Carpenter, B., "Procedures for protocol 958 extensions and variations", BCP 125, RFC 4775, December 959 2006. 961 11.2 Informative References 963 [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task 964 Force and International Telecommunication Union - 965 Telecommunications Standardization Sector Collaboration 966 Guidelines", RFC 3356, August 2002. 968 12. Editors' Addresses 970 Loa Andersson 971 Acreo AB 972 Email: loa@pi.se 974 Adrian Farrel 975 Old Dog Consulting 976 Email: adrian@olddog.co.uk 978 13. Authors' Addresses 980 George Swallow 981 Cisco Systems 982 Email: swallow@cisco.com 984 Deborah Brungard 985 AT&T 986 Email: dbrungard@att.com 988 Bill Fenner 989 AT&T 990 Email: fenner@research.att.com 992 Ross Callon 993 Juniper Networks 994 Email: rcallon@juniper.net 996 Kireeti Kompella 997 Juniper Networks 998 Email: Kireeti@juniper.net 1000 Alex Zinin 1001 Alcatel 1002 Email: zinin@psg.com 1004 Scott Bradner 1005 Harvard University 1006 Email: sob@harvard.edu 1008 Intellectual Property Statement 1010 The IETF takes no position regarding the validity or scope of any 1011 Intellectual Property Rights or other rights that might be claimed to 1012 pertain to the implementation or use of the technology described in 1013 this document or the extent to which any license under such rights 1014 might or might not be available; nor does it represent that it has 1015 made any independent effort to identify any such rights. Information 1016 on the procedures with respect to rights in RFC documents can be 1017 found in BCP 78 and BCP 79. 1019 Copies of IPR disclosures made to the IETF Secretariat and any 1020 assurances of licenses to be made available, or the result of an 1021 attempt made to obtain a general license or permission for the use of 1022 such proprietary rights by implementers or users of this 1023 specification can be obtained from the IETF on-line IPR repository at 1024 http://www.ietf.org/ipr. 1026 The IETF invites any interested party to bring to its attention any 1027 copyrights, patents or patent applications, or other proprietary 1028 rights that may cover technology that may be required to implement 1029 this standard. Please address the information to the IETF at 1030 ietf-ipr@ietf.org. 1032 Disclaimer of Validity 1034 This document and the information contained herein are provided on an 1035 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1036 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1037 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1038 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1039 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1040 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1042 Copyright Statement 1044 Copyright (C) The IETF Trust (2007). 1046 This document is subject to the rights, licenses and restrictions 1047 contained in BCP 78, and except as set forth therein, the authors 1048 retain all their rights.