idnits 2.17.1 draft-andersson-rtg-gmpls-change-03.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 on line 1005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 989. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 995. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (August 2006) is 6463 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3356 (Obsoleted by RFC 6756) -- Obsolete informational reference (is this intentional?): RFC 3932 (Obsoleted by RFC 5742) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 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 Proposed Status: Best Current Practice A. Farrel (Editor) 4 Old Dog Consulting 6 August 2006 8 Change Process for Multiprotocol Label Switching (MPLS) and 9 Generalized MPLS (GMPLS) Protocols and Procedures 11 draft-andersson-rtg-gmpls-change-03 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 The issues surrounding the extensibility of IETF protocols have been 39 widely debated. These issues include when it is reasonable to 40 extend IETF protocols with little or no review, and when extensions 41 or variations need to be reviewed by the larger IETF community. 42 Experience with IETF protocols has shown that extensibility of 43 protocols without early IETF review can cause problems. 45 The Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 46 suites of protocols have become popular for a number of applications 47 and deployment scenarios. One result of this popularity is a large 48 number of suggestions for modifications and extensions. 50 This document defines a flexible and responsive process for the IETF 51 to handle suggestions for extensions to the MPLS and GMPLS protocols, 52 and clarifies the IETF's responsibility to supervise the growth and 53 evolution of MPLS and GMPLS protocols. 55 The process allows individuals, IETF working groups, and external 56 standards bodies to influence the development of the MPLS and GMPLS 57 standards. When possible, existing liaison relationships are used. 59 Table of Contents 61 1. Introduction ................................................... 3 62 1.1 Document Source ............................................... 4 63 1.2 Conventions Used in this Document ............................. 4 64 2. Applicability of the (G)MPLS Change Process .................... 4 65 2.1 IETF Working Groups Developing (G)MPLS Technology ............. 4 66 2.1.1 Multiprotocol Label Switching Working Group ................. 5 67 2.1.2 Common Control & Measurement Plane Working Group ............ 5 68 2.1.3 MPLS and CCAMP Division of Work ............................. 6 69 2.2 Other (G)MPLS Technology Working Groups ...................... 6 70 2.3 Organizations Outside the IETF ............................... 7 71 2.4 Terminology .................................................. 7 72 3. Summary of Procedures .......................................... 8 73 4. MPLS and GMPLS Change Process ................................. 9 74 4.1 Flow Diagram ................................................ 11 75 4.2 Description of Process Stages ............................... 12 76 4.2.1 Preliminary Investigation .................................. 12 77 4.2.2 Requirements Statement Evaluation .......................... 12 78 4.2.3 Chartering the Rewg ........................................ 13 79 4.2.4 Rewg Evaluation of the Requirements Statement I-D .......... 14 80 4.2.5 AD Evaluation of Completed Requirements Statement I-D ...... 14 81 4.2.6 IESG and IAB review of Requirements Statement I-D and Pswg 82 Charter .................................................... 14 83 4.2.7 Solutions Work ............................................. 15 84 5. Rejecting Requirements Statements I-D ......................... 16 85 5.1 Reasons for Rejection ........................................ 16 86 5.2 Actions Upon Rejection ....................................... 17 87 6. Abandonment of the Solutions I-D .............................. 18 88 7. (G)MPLS Integrity ............................................. 18 89 8. Security Considerations ...................................... 19 90 9. Acknowledgements ............................................. 19 91 10. IANA Considerations .......................................... 20 92 11. References .................................................. 20 93 11.1 Normative References ....................................... 20 94 11.2 Informative References ..................................... 20 96 1. Introduction 98 [PROT-EXT] discusses procedural issues related to the extensibility 99 of IETF protocols, including when it is reasonable to extend IETF 100 protocols with little or no review, and when extensions or variations 101 need to be reviewed by the larger IETF community. Experience with 102 IETF protocols has shown that extensibility of protocols without 103 early IETF review can cause problems. The document also recommends 104 that major extensions to or variations of IETF protocols only take 105 place through normal IETF processes or in coordination with the IETF. 107 This document recognizes that the Multiprotocol Label Switching 108 (MPLS) and Generalized MPLS (GMPLS) protocol families were created 109 within the IETF and constitute significant protocol suites that are 110 strategic to the development of the Internet. They should not be 111 extended or varied without IETF review, and that should preferably 112 only be extended within the IETF process. 114 The process described in this document allows individuals, IETF 115 working groups, and external standards bodies to influence the 116 development of MPLS and GMPLS protocols and related standards. The 117 process means that MPLS and GMPLS extensions and changes can only be 118 done through or in coordination with the IETF. In particular, the 119 MPLS and/or CCAMP working groups or their successors need to be 120 involved in the process. When possible, existing liaison 121 relationships ([RFC4052], [RFC4053]) are leveraged. 123 The IETF will not endorse the publication of any MPLS or GMPLS 124 protocol or technology extensions in RFCs or other documents where 125 the process described here have not been followed. If publication of 126 individual Internet-Drafts describing extensions or changes to the 127 MPLS or GMPLS protocols is requested of the RFC Editor the documents 128 will be returned to the process described in this document using the 129 mechanism described in [RFC3932]. 131 IANA is responsible for managing many codepoints registries including 132 those for MPLS and GMPLS protocols. These registries have specific 133 allocation policies that IANA uses in order to determine whether 134 codepoints can be allocated and which codepoints to allocate. In many 135 cases, the rules require IANA to refer back to the IETF when asked to 136 make an allocation. In the case of changes or extensions to the MPLS 137 or GMPLS protocols, IANA will use the process described in this 138 document to judge whether or not a code point allocation should be 139 made. 141 The MPLS and GMPLS technology is developed in two main tracks in the 142 IETF. "MPLS" refers to the work done for packet switched networks, 143 while "GMPLS" refers to the efforts to apply the MPLS protocols to 144 all types of networks including packet and non-packet technologies. 145 Though GMPLS by definition is a superset of MPLS, the term "(G)MPLS" 146 is used in this document to indicate both of these tracks. A 147 terminology section that covers the use of terms and concepts used in 148 this document is found in Section 2.6. 150 1.1 Document Source 152 This document is the joint work of the IETF Routing Area Directors, 153 the IETF MPLS and CCAMP Working Group Chairs, and the IETF's liaison 154 to the ITU-T. It has had considerable review and comment from key 155 members of the ITU-T who have given their time and opinions based on 156 experience for which the authors are grateful. The acknowledgements 157 section lists those whose contributions have been particularly 158 helpful. 160 1.2 Conventions Used in this Document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 2. Applicability of the (G)MPLS Change Process 168 This section outlines the applicability of the (G)MPLS change process 169 specified in this document. It lists the key IETF working groups 170 developing the (G)MPLS technology, examples of IETF working groups 171 using the (G)MPLS technology, and possible parties interested in 172 using, extending, or changing the (G)MPLS technology. 174 It should be remembered that the IETF environment is highly dynamic. 175 Working groups and whole areas come and go. The overview of the 176 relevant working groups within the IETF is only a snapshot in time. 178 A section listing terminology local to this document that will be 179 used in specifying the change process is also included. 181 2.1 IETF Working Groups Developing (G)MPLS Technology 183 Two working groups in the IETF's Routing Area have been responsible 184 for work to develop the (G)MPLS technology. The Multiprotocol Label 185 Switching (MPLS) working group and the Common Control and Measurement 186 Plane (CCAMP) working group. 188 The sections below give brief overviews of the work these two IETF 189 working groups were chartered to do. 191 The IETF may in the future, define additional working groups to work 192 on specific chartered issues related to (G)MPLS. Further, specific 193 existing working groups such as those listed in section 2.2 may be 194 rechartered by the IESG to work on particular aspects of the (G)MPLS 195 protocols. The procedure for chartering new or existing working 196 groups to undertake (G)MPLS work is covered in section 4.2.3. 198 2.1.1 Multiprotocol Label Switching Working Group 200 The Multiprotocol Label Switching (MPLS) working group is responsible 201 for standardizing the base technology that uses label switching, and 202 for describing the implementation of Label Switched Paths (LSPs) over 203 various packet and frame-based link level technologies. The working 204 group charter includes procedures and protocols for the distribution 205 of labels between routers, as well as encapsulations, operation and 206 management, traffic engineering, and multicast considerations. 208 The procedures in this document assume that the MPLS working group 209 remains the authority on MPLS technologies, but acknowledges that 210 the IETF may appoint another working group (using the procedures in 211 this document) to handle specific extensions or changes to the 212 protocols. Further, in the event that the MPLS working group 213 completes its work and is closed, the IETF may appoint a Designated 214 Expert (sometimes known as a Caretaker) for the MPLS protocols. 216 2.1.2 Common Control & Measurement Plane Working Group 218 The IETF Common Control and Measurement Plane (CCAMP) working group 219 coordinates the work within the IETF defining common control and 220 measurement planes for ISP and SP core tunneling technologies. This 221 includes, but is not limited to, defining signaling protocols and 222 measurement protocols such that they support multiple physical path 223 and tunnel technologies using input from technology-specific working 224 groups such as the MPLS working group. It also includes the 225 development of protocol-independent metrics and parameters for 226 describing links and paths that can be carried in protocols. 228 The technology that the CCAMP working group focuses on is called 229 Generalized MPLS (GMPLS), indicating that CCAMP addresses a 230 generalized technology, where labels are defined in such a way that 231 they will be compatible with the technology over which the data is 232 transported. While the MPLS working group focuses on packet- and 233 frame-switched technologies, the CCAMP working group work focuses on 234 common methods across a broad spectrum of switching technologies 235 including packet and frame technologies. In this respect, GMPLS can 236 be viewed as a superset of MPLS. 238 The procedures in this document assume that the CCAMP working group 239 remains the authority on GMPLS technologies, but acknowledges that 240 the IETF may appoint another working group (using the procedures in 241 this document) to handle specific extensions or changes to the 242 protocols. Further, in the event that the CCAMP working group 243 completes its work and is closed, the IETF may appoint a Designated 244 Expert (sometimes known as a Caretaker) for the GMPLS protocols. 246 2.1.3 MPLS and CCAMP Division of Work 248 From time to time the MPLS and CCAMP working groups decide to divide 249 work between themselves in a way that does not strictly follow the 250 split between the working groups as defined in the working group 251 charters. This is the case, e.g., for P2MP TE LSPs, where the MPLS 252 working group is specifying requirements and base technology for all 253 of the (G)MPLS technology. 255 An entity or individual that wishes to propose extensions or changes 256 to (G)MPLS should first decide to which working group (MPLS or CCAMP) 257 it will bring the proposal. However, the MPLS and CCAMP working group 258 chairs, in conjunction with their Area Directors, may redirect the 259 proposal to another working group. 261 2.2 Other (G)MPLS Technology Working Groups 263 Problem statements and requirements for (G)MPLS technology have been 264 produced by several working groups in addition to the MPLS and CCAMP 265 working groups. For example, the IP over Optical (IPO) working group 266 and the Internet Traffic Engineering working group (TEWG). These 267 working groups have not specified any protocols, but have been a 268 source of problem statements and requirements to be considered by the 269 (G)MPLS working groups. 271 Other working groups, e.g., the Bidirectional Forwarding Detection 272 (BFD) working group, also use the (G)MPLS protocols and mechanisms. 273 When any of these working groups needs to extend or change the 274 (G)MPLS protocols the procedures specified in this document are 275 applicable. 277 The Layer 2 VPN (L2VPN) and Layer 3 VPN (L3VPN) working groups have 278 been chartered to specify a limited number of solutions for Provider 279 Provisioned VPNs. Both working groups are in the Internet Area. The 280 work of the L2VPN and L3VPN working groups does not include 281 specifying new protocols, however, protocol changes and extensions 282 to the (G)MPLS protocols may be needed. If so, the procedures 283 specified in this document are applicable. 285 The Layer 1 VPN (L1VPN) working group is chartered to specify 286 mechanisms necessary for providing layer 1 VPN services 287 (establishment of layer 1 connections between CE devices) over a 288 GMPLS-enabled transport service-provider network. Protocol extensions 289 required for L1VPN will be done in cooperation with MPLS, CCAMP, 290 OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary. That is, the 291 L1VPN will not develop GMPLS protocol extensions in isolation, but 292 will develop requirements and propose extensions that will be 293 reviewed and approved by the (G)MPLS working groups. 295 The Pseudo Wire Emulation End to End (PWE3) working group is another 296 working group in the Internet Area that also uses the (G)MPLS 297 protocols in its specifications. Should the PWE3 specifications 298 require extension or changes to the (G)MPLS protocols the procedures 299 specified in this document are applicable. 301 It is assumed that the change process for the MPLS and CCAMP working 302 groups, specified in this document, will be applicable or at least 303 adaptable to other (G)MPLS technology working groups if such a need 304 should arise. 306 2.3 Organizations Outside the IETF 308 A number of standards development organizations (SDOs) and industrial 309 forums use or reference the (G)MPLS protocols in their 310 specifications. Some of these organizations have formal liaison 311 relationships with the IETF [RFC4052]. The IETF exchanges information 312 with these organizations about what is happening on both sides, 313 including plans and schedules, using liaison statements [RFC4053]. 314 More details about the cooperation relationship between the IETF and 315 the ITU-T can be found in [RFC3356]. 317 The procedures in this document are applicable to all organizations 318 outside the IETF whether or not they have formal liaison 319 relationships with the IETF. If any organization outside the IETF 320 has a requirement or believes it may have a requirement for 321 extensions or modifications to the (G)MPLS protocols then the 322 procedures in this document apply. 324 2.4 Terminology 326 This section defines terms for use in the context of this document. 328 o (G)MPLS protocols 329 The (G)MPLS protocols are the protocols and protocol variants 330 developed by the IETF to control, manage, or measure MPLS or GMPLS 331 networks and their component devices. 333 The set of RFCs that constitutes the (G)MPLS protocols are the 334 standards track RFCs from the (G)MPLS working groups (see below). 335 A list of these RFCs is not supplied here since new RFCs are 336 produced from time to time. 338 For the purpose of extending and changing any protocols specified 339 in Experimental RFCs developed by the (G)MPLS working groups, 340 those protocols are considered to be part of the (G)MPLS 341 protocols. 343 o (G)MPLS working groups 344 The (G)MPLS working groups are the MPLS and the CCAMP working 345 groups, and any future working group specifically chartered by the 346 IESG to work on the development or extension of the (G)MPLS 347 protocols. 349 o (G)MPLS technology working group 350 Any working group chartered by the IESG to specify requirements 351 for the (G)MPLS protocols, and any working group that specifies a 352 use for the (G)MPLS protocols. This include the (G)MPLS working 353 groups. 355 o Requirement evaluating working group (rewg) 356 The rewg is the IETF working group charged with the task of 357 evaluating a specific set of requirements and the associated 358 problem statement. 360 o Protocol specifying working group (pswg) 361 The pswg is the working group chartered by the IESG to specify 362 changes or extensions to the (G)MPLS protocols either as part of 363 the normal IETF process or in response to a requirements draft. 365 o Problem statement Internet-Draft 366 The Internet-Draft that initiates the discussion on changing or 367 extending the (G)MPLS protocols. This draft includes a detailed 368 problem description that (G)MPLS is called on to solve. The 369 problem statement draft may also include the requirements (see 370 requirements statement Internet-Draft, below). 372 o Requirements statement Internet-Draft 373 This Internet-Draft provides a detailed list of the requirements 374 that the (G)MPLS extensions or changes need to fulfil. This draft 375 may be merged with the problem statement draft (see above). 377 o Solutions Internet-Draft 378 A specification of extensions or changes to the (G)MPLS protocols 379 to meet the requirements in the requirement statement 380 Internet-Draft. 382 3. Summary of Procedures 384 This non-normative section is intended to provide a high-level view 385 of the procedures in this document to illustrate how they work and to 386 introduce the mechanisms that are defined in detail in Section 4. 388 Whenever any extension or change to the (G)MPLS protocols is desired, 389 a requirements statement must be produced and must be submitted to 390 IETF as an Internet-Draft. As described in [RFC4052], when the 391 requirements come from an external organization informal 392 communications such as e-mail to working group mailing lists often 393 facilitates cooperative work. However, if desired, the Internet-Draft 394 containing the requirement may be submitted to the working group 395 using a liaison statement. That way, the IETF's response to the 396 request will be given as the reply to the liaison, with no risk of 397 confusing an individual participant's opinion for that of the group 398 as can happen on mailing lists. 400 The IETF, through the Routing Area Directors and the chairs of the 401 MPLS and CCAMP working groups, will direct the requirements draft to 402 an appropriate working group for assessment and comment. This process 403 may require communication and discussion for clarification, but the 404 IETF undertakes to perform the assessment in a timely manner. 406 In assessing the requirements statement I-D, the IETF may determine: 407 that the requirements can be satisfied without modifications to the 408 (G)MPLS protocols; that the requirements are not sufficiently general 409 to warrant a change to the (G)MPLS protocols; that the requirements 410 justify a change to the (G)MPLS protocols that will be created by the 411 IETF or within another organization; that the requirements might not 412 be possible to satisfy without vioalting the (G)MPLS architecture in 413 a way that would harm the (G)MPLS technology; or that the 414 requirements should be combined with other requirements to solve a 415 more general problem or solve the same problem in a more flexible 416 way. 418 In the event that the IETF agrees to develop a solution, the IETF 419 will commit to do so in a timely manner. If the IETF rejects the 420 requirements, this will only be done with clear explanation and full 421 discussion with the source of the requirements. 423 The solutions that are developed within the IETF may be sourced from 424 external organizations and presented for review, discussion, 425 modification, and adoption as Internet-Drafts. Such solutions drafts 426 may be presented to the IETF in advance of the completion of the 427 requirements work, but all solutions will compete through the normal 428 IETF process with other proposed solutions, and none will be adopted 429 as an IETF working group draft until the requirements are agreed by 430 the rewg chairs to be stable and, in any case, not before the pswg 431 has a charter item to cover the solutions work. 433 4. MPLS and GMPLS Change Process 435 This section defines the (G)MPLS change process and the rules that 436 must be followed in order to make extensions or changes to the 437 (G)MPLS protocols. The language of [RFC2119] is used in order to 438 clarify the precise required behavior. 440 Anyone who intends to use one of the existing (G)MPLS protocols, but 441 thinks that it will not satisfy their needs MUST use the procedures 442 described in this document. Changes or extensions to the (G)MPLS 443 protocols MUST NOT be made by any other mechanism. The IETF MUST NOT 444 endorse any publications (including RFCs whether on the Standards 445 Track, Informational, or Experimental) that change or extended the 446 (G)MPLS protocols except for those that arise through the correct 447 execution of the procedures in this document. The IETF MUST NOT 448 endorse any IANA action that allocates (G)MPLS protocol codepoints 449 except as a result of actions arising from the correct execution of 450 the procedures in this document. 452 4.1 Flow Diagram 454 Figure 1 is presented to give a visual overview of the process. It 455 does not contain all of the possible interactions of procedures, and 456 the text in the subsequent sections should be used for a definitive 457 description of the process. 459 Start +-------------+ 460 | |optional | 461 +--<--------------------|preliminary |<-------Start 462 | |investigation| 463 V +-------------+ 464 +------------+ +---------+ +---------+ 465 |requirements| discussion |review by| ACK | IESG/ | ACK 466 |statement |----------->|WG chairs|------------->| IAB |------+ 467 |I-D | on mailing |and ADs | request to |decision | | 468 +------------+ list +---------+ IESG/IAB to +---------+ | 469 | appoint rewg | | 470 | NAK and charter |NAK rewg| 471 V req eval | chartered| 472 +-------------+ | to work on| 473 |response | | requirements| 474 |to the | | statement| 475 |requirements |<-----------------+ | 476 +->|statement |<----------------+ | 477 | +-------------+ | | 478 | ^ | | 479 NAK| | NAK | | 480 | +-----------------+ | V 481 | | | NAK +------+ 482 +--------+ +-------+ +--------| rewg | 483 | IESG/ | ACK | AD | | req | 484 +-----------| IAB |<---------------|review |<------------| eval | 485 |WG |decision| request to | | ACK | | 486 |chartered +--------+ IESG/IAB to +-------+ +------+ 487 |to work approve I-D 488 | and charter 489 | 490 | +---------+ 491 | | IETF | +-----+ 492 +--------->| WG |-----/ /---->| RFC | 493 +---->| process | +-----+ 494 | +---------+ 495 solutions 496 I-D 498 Figure 1: Change Process Overview 500 4.2 Description of Process Stages 502 This section describes how the (G)MPLS change process works, what is 503 expected from individuals or organizations that want to extend or 504 change the (G)MPLS protocols, and the responsibilities of the (G)MPLS 505 working groups, the Routing Area and the IETF in general. 507 4.2.1 Preliminary Investigation 509 This step is OPTIONAL, and is intended to provide a lightweight way 510 to "feel out" the IETF's position on a proposal without going to the 511 effort of writing an Internet-Draft. The intention is to determine 512 whether the problem has been examined already, whether the problem is 513 in scope for the IETF, and whether solutions are already known. 515 Useful discussions may be held at this stage in order to ensure that 516 the problem statement and requirements statement Internet-Drafts 517 contain the right material. 519 This step SHOULD be carried out informally on the mailing list of the 520 rewg or on the Routing Area discussion mailing list and may be 521 initiated by any individual, group of individuals, external 522 organization, or IETF working group. 524 When an external SDO has a liaison relationship with the IETF, it 525 MAY carry out this step using a formal liaison. The liaison SHOULD be 526 sent to the rewg or to the Routing Area, and the initiators of the 527 liaison SHOULD make themselves available for discussion on the 528 selected mailing list. If a formal liaison is used, the IETF MUST 529 respond to pursue the discussion. 531 At this stage, a problem statement I-D MAY be produced to help 532 further the discussions and to clarify the issues being addressed. 534 4.2.2 Requirements Statement Evaluation 536 Before the IETF can formally pronounce on requirements to change or 537 extend the (G)MPLS protocols, a requirements statement I-D MUST be 538 written and submitted to the IETF for publication. 540 The requirements statement I-D MUST be introduced to the IETF through 541 an email to the rewg mailing list or to the Routing Area discussion 542 mailing list, or by a formal liaison from an external SDO which will 543 result in the IETF introducing the requirements statement I-D to the 544 rewg mailing list. If the requirements statement I-D is brought to 545 the IETF through a formal liaison, the initiators of the liaison 546 SHOULD make themselves available for discussion on the appropriate 547 mailing lists. 549 After discussion on the IETF mailing lists, the appropriate IETF 550 working group chairs and the Routing Area Directors MUST decide 551 whether the requirements will be formally evaluated by the IETF or 552 MUST deliver a response to the requirements statement I-D. 554 If the requirements statement I-D is brought to the IETF through a 555 formal liaison, the IETF MUST respond using one of the following 556 answers in a formal liaison reply: 558 a. Requirements not understood. Further discussion required. 560 b. Requirements understood, but judged to be out of scope for the 561 IETF. 563 In this case, the originator of the requirements can work on 564 on requirements and solutions and will not be impeded by the 565 IETF. The IETF may request to be kept informed of progress. 567 c. Requirements understood, but no protocol extensions are needed. 569 It may be desirable for the external SDO to cooperate with the 570 appropriate working group in the production of an Applicability 571 Statement Internet-Draft. 573 d. Requirements understood, and the IETF would like to develop 574 protocol extensions. 576 This results in execution of the rest of the procedure, described 577 below. The requirements raised in the requirements statement I-D 578 may be combined with other requirements to produce more general 579 extensions or changes to the (G)MPLS protocols. 581 4.2.3 Chartering the Rewg 583 In many cases the problem covered by the requirements statement I-D 584 will fall within the scope of the existing charter of a working 585 group. In this case, the Routing Area Directors SHOULD designate the 586 working group as the rewg and pass the requirements statement I-D to 587 the working group for evaluation. 589 If a new charter item is required, the Routing Area Directors with 590 assistance from working group chairs MUST apply to the IESG and IAB 591 for a modification of an existing working group's charter or for the 592 creation of a new working group. If the IESG and IAB approve the 593 charter, the requirements statement I-D is passed to the rewg for 594 evaluation. If the charter change is not approved, the IESG and IAB 595 MUST respond to the requirements statement I-D and, if the 596 requirements were introduced through a formal liaison from another 597 SDO, the IESG and IAB MUST send a liaison response using the options 598 described in Section 5. 600 4.2.4 Rewg Evaluation of the Requirements Statement I-D 602 The objective of the rewg evaluation process is to determine a clear 603 and complete statement of the requirements for changes or extensions 604 to the (G)MPLS protocols. This will necessitate normal IETF working 605 group procedures in the rewg and MAY include the generation of 606 revisions of the requirements statement I-D in cooperation between 607 the members of the rewg and the original authors of the requirements 608 statement I-D. 610 The originators of the requirements statement I-D MUST make 611 themselves available to discuss the work on the rewg mailing list. 612 If this does not happen, the chairs of the rewg MAY determine that 613 there is insufficient support for the work and MAY reject the 614 requirements statement I-D. 616 The output of the rewg MUST be either: 617 - a completed requirements statement I-D that has been accepted by 618 working group consensus within the rewg and has passed through 619 working group last call; 620 or: 621 - a rejection of the requirements following exactly the same format 622 and procedure as described in Section 5. 624 4.2.5 AD Evaluation of Completed Requirements Statement I-D 626 As with all Internet-Drafts produced by a working group, the ADs are 627 MUST review the completed requirements statement I-D produced by the 628 rewg to determine its fitness for publication. The ADs MAY use an 629 Area Directorate to assist them in this review. 631 The result of the AD review MAY request the rewg to do further work 632 on the I-D in which case the previous step and this one will be 633 repeated. 635 The ADs SHOULD NOT reject the requirements statement I-D outright at 636 this stage since the requirements have already been accepted by the 637 ADs at an earlier stage. However, in some situations (such as a 638 significant change in related circumstances) the ADs MAY reject the 639 requirements statement I-D using the format and procedure described 640 in Section 5. 642 When the ADs accept the requirements statement I-D they MUST pass it 643 to the IESG for review, and propose any charter changes necessary to 644 select a pswg. 646 4.2.6 IESG and IAB review of Requirements Statement I-D and Pswg Charter 648 As with all Internet-Drafts, the IESG MUST take a ballot on the 649 progression of the requirements statement I-D. 651 If the IESG rejects the requirements statement I-D, it MUST generate 652 a response to the requirements as described in Section 5. 654 The IESG and IAB MUST take a ballot on any proposed charter changes 655 for the pswg. This MAY include the formation of a new working group 656 specifically to work on the solutions, although it is also possible 657 that the solutions work is covered by an existing working group 658 charter without any changes. 660 If the IESG rejects working group charter changes such that it is not 661 possible for the IETF to work on solutions for the requirements in 662 the requirements statement I-D, this MUST be treated as a rejection 663 of the requirements statement I-D, and the requirements statement I-D 664 MUST NOT be published as an RFC. In this case the IESG MUST reject 665 the requirements statement I-D using the format and procedure 666 described in Section 5. 668 4.2.7 Solutions Work 670 Once the requirements statement I-D has been approved by the IESG it 671 will enter the RFC Editor's queue and be handled according to normal 672 IETF process. 674 Once the pswg has been identified and (re-)chartered as necessary and 675 the requirements statement I-D has been approved by the IESG, the 676 pswg can start work on solutions following the normal IETF process. 678 Solutions I-Ds MAY be prepared externally (such as within an external 679 organization) or within the IETF, submitted to the IETF for 680 publication, and introduced to the pswg for consideration. Such I-Ds 681 MAY be submitted at earlier stages in the process to assist the rewg 682 in its development and discussion of the requirements, but no I-D 683 will be formally considered as a solutions I-Ds until the pswg has a 684 charter item that covers the work and the rewg chairs are confident 685 that the requirements are stable. Even at this stage in the process, 686 the IETF makes no guarantees that an externally produced solutions 687 I-D will form the basis of the pswg solutions I-D, but the pswg MUST 688 consider such an I-D as a possible solution I-D. 690 The final development of the solutions I-D is subject to the normal 691 working group review, consensus, and last call within the pswg. 693 Where the requirements originated from an external organization, the 694 pswg SHOULD regularly communicate its progress using a formal liaison 695 process if one exists. This communication SHOULD also be used to 696 request review input and comment on the development of the solutions 697 I-D. When the solutions I-D is complete (normally upon completing 698 working group last call and/or on entering the RFC Editor's queue) 699 the pswg MUST inform the originating organization of the completed 700 solution. 702 5. Rejecting Requirements Statements I-D 704 Rejection of the requirements statements is a sensitive matter for 705 the authors of the requirements and MUST be handled with full 706 disclosure and explanation by the IETF. 708 The requirements can be rejected at various stages of the process as 709 described in the previous sections. The person or grouping that makes 710 the rejection is responsible for generating an explanation of the 711 rejection and MUST follow the process described in this section. 713 5.1 Reasons for Rejection 715 The requirements statement I-D can only be rejected using one of the 716 following reasons. Each reason MUST be stated with the acceptable 717 next steps as described here. 719 - Requirements not understood. At the early stage of evaluation of 720 the requirements statement I-D before the rewg has been tasked with 721 performing a full evaluation and completing the requirements 722 statement I-D or during the optional preliminary investigation it 723 is not clear what the requirements are for or what the problem 724 being addressed is. 726 This rejection forms part of an on-going communication and it is 727 expected that the process will continue with further iterations. 729 - Out of scope for the IETF. Many stages of this process may 730 determine that the requirements are out of scope for the IETF. In 731 this case, the IETF MUST NOT constrain the authors of the 732 requirements statement I-D permission to work on a solution. 734 - No protocols extensions or changes are needed. At some stage in the 735 evaluation of the requirements it may become clear that they can 736 all be met through appropriate use of existing protocols. In this 737 case no further evaluation of the requirements is required, but the 738 IETF MUST explain how the protocols can be used to meet the 739 requirements and MAY cooperate with the authors of the requirements 740 statement I-D in the production of an Applicability Statement 741 Internet-Draft that explains precisely how the existing protocols 742 can be used to meet the requirements. 744 - Insufficient support within the IETF. Although the work described 745 within the requirements statement I-D is within scope for the IETF, 746 and despite the support of the originators of the requirements 747 statement I-D on the rewg mailing list, the chairs of the rewg have 748 determined that there is insufficient support in the rewg to 749 complete requirements statement I-D. In this case, the IETF MUST 750 grant the authors of the requirements statement I-D permission to 751 work on a solution. The solution SHALL be presented to the IETF 752 for review and possible publication as an Informational or 753 Experimental RFC, and the IETF SHALL NOT block applications to IANA 754 for codepoints. 756 - Insufficient support for the work. If the authors of the 757 requirements statement I-D do not make themselves available on the 758 rewg mailing list for discussion of the requirements or do not 759 contribute the completion of the requirements statement I-D, the 760 chairs of the rewg MAY determine that there is insufficient support 761 for the work and MAY reject the requirements statement I-D. In this 762 case, the IETF MUST NOT grant permission for the work to be carried 763 out in any other organization, and MUST NOT endorse the publication 764 of any changes or extensions to the (G)MPLS protocols and MUST NOT 765 instruct IANA to allocate any codepoints. The requirements may be 766 re-introduced by starting the procedure again from the top. 768 - Satisfying the requirements would break the technology. It is 769 possible that an assessment will be made that, although the 770 requirements are reasonable, it is not possible to satisfy them 771 through extensions or changes to the (G)MPLS protocols without 772 violating the (G)MPLS architecture in such a way as would break the 773 (G)MPLS technology. In this case a recommendation will be made that 774 some other technology be used to satisfy the requirements. See 775 Section 7 for further discussions of the protection of the 776 integrity of the (G)MPLS technology. 778 5.2 Actions Upon Rejection 780 Upon rejection, the IETF MUST make a clear statement of why the 781 requirements statement I-D has been rejected and what next step 782 actions are acceptable. The reasons SHOULD be based on the list in 783 Section 5.1. 785 The form of the rejection depends on the form of the original 786 submission. 788 - If the requirements are brought to the IETF as a preliminary 789 investigation through an email exchange then the response SHOULD 790 be made as an email response and SHOULD be archived through an 791 IETF email archive. 793 - If the requirements are brought to the IETF as a preliminary 794 investigation through a formal liaison, the rejection MUST be 795 delivered through a formal liaison response. 797 - If a requirements statement I-D has been produced and discussed on 798 an IETF email list, the response SHOULD be made as an email 799 response and copied to the email list. 801 - If a requirements statement I-D has been produced and brought to 802 the IETF through a formal liaison, the rejection MUST be 803 delivered through a formal liaison response. 805 - If an IETF working group has been involved in the review or 806 production of any Internet-Drafts for the requirements or for the 807 solutions, the working group MUST be notified of the rejection and 808 the reasons. 810 The responsibility for the generation response lies with the person, 811 people, or grouping that instigates the rejection. This may be the 812 IAB, the IESG, one or more Area Directors, one or more working group 813 chairs, or a protocol caretaker. In the case of the use of a liaison 814 relationship, the IETF's liaison manager has responsibility for 815 ensuring that the procedures in this document, and particularly the 816 rejection procedures, are followed. 818 6. Abandonment of the Solutions I-D 820 Once the solutions work has been started by the pswg, it MAY be 821 abandoned before completion. This can happen if the pswg chairs 822 determine that there is no longer working group support for doing the 823 work. This could arise, for example, if no-one (including the 824 originators of the requirements statement I-D) is willing to 825 contribute to the development of a solutions I-D. 827 In the event that the solutions work is abandoned by the pswg, the 828 Area Directors responsible for the pswg MUST be consulted. The 829 originators of the requirements statement I-D MUST be informed that 830 the work has been stopped using a mechanism dependent on how the 831 requirements were introduced (as discussed in Section 5.2). 833 If the solution is abandoned in this way, work on solutions for the 834 requirements MUST NOT be started in another forum. The status of 835 extensions and changes to the (G)MPLS protocols with regard to the 836 specific requirements returns to how it was before the process 837 started. Any new examination of the requirements MUST commence at 838 the top of the process. 840 7. (G)MPLS Integrity 842 The (G)MPLS working groups are REQUIRED to protect the architectural 843 integrity of the (G)MPLS protocols and MUST NOT extend the GMPLS 844 architecture with features that do not have general use beyond the 845 specific case. They also MUST NOT modify the architecture just to 846 make some function more efficient at the expense of simplicity or 847 generality. 849 The architectural implications of additions or changes to the (G)MPLS 850 protocols MUST be consider interoperability with existing and future 851 versions of the protocols. The effects of adding features that 852 overlap or that deal with a point solution and are not general are 853 much harder to control with rules. Therefore the (G)MPLS technology 854 calls for this architectural guardianship by its working groups. 856 8. Security Considerations 858 All requirements statement I-Ds MUST give full consideration to the 859 security impact of the proposed additional features or functions. All 860 solutions I-Ds MUST consider the impact on the security of the 861 protocol extensions and to the pre-existing protocol. 863 This documents does not itself introduce any security issues for any 864 (G)MPLS protocols. 866 The IETF process is itself at risk from denial of service attacks. 867 This document utilizes the IETF process and adds details to that 868 process. It is possible, therefore, that this document might put the 869 IETF process at risk. Although this document places additional 870 requirements on key individuals within the IETF those requirements 871 are not substantial for any individual requirements statement I-D 872 since the responsibility for the majority of the work lies with the 873 rewg and pswg with an underlying assumption that the authors of the 874 requirements statement I-D will participate in the working group 875 process. 877 Therefore, provided that the number of requirements statement I-Ds is 878 not unreasonable there will be no significant impact on the IETF 879 process. The rate of arrival of requirements statement I-Ds may be 880 used by the IESG to detect denial of service attacks and the IESG 881 SHOULD act on such an event depending on the source of the 882 requirements statement I-D and the perceived relevance of the work. 883 The IESG might, for example, discuss the issue with the management of 884 external organizations. 886 9. Acknowledgements 888 The input given by Bert Wijnen has been useful and detailed. 890 Review feedback and discussions with various members of the ITU-T has 891 been helpful in refining the process described in this document. 892 Thanks in particular to the members of Question 14 of Study Group 15, 893 and to the management of Study Group 15. Important discussions were 894 held with the following participants in the ITU-T: Yoichi Maeda, 895 Greg Jones, Stephen Trowbridge, Malcolm Betts, Kam Lam, 896 George Newsome, Eve Varma, Lyndon Ong, Stephen Shew, Jonathan Sadler, 897 and Ben Mack-Crane. 899 10. IANA Considerations 901 This document makes no specific requests to IANA for action. The 902 procedures described in this document assume that IANA will adhere to 903 the allocation policies defined for the (G)MPLS codepoint registries 904 and that the IETF will not endorse allocation of codepoints from 905 those registries except where work has been carried out in accordance 906 with the procedures described in this document. 908 11. References 910 11.1 Normative References 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, March 1997. 915 [RFC4052] Daigle, L., "IAB Processes for Management of IETF Liaison 916 Relationships", BCP 102, RFC 4052, April 2005. 918 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 919 Handling Liaison Statements to and from the IETF", 920 BCP 103, RFC4053, April 2005. 922 [PROT-EXT] Bradner, S., and Carpenter, B., "Procedures for protocol 923 extensions and variations", draft-carpenter-protocol- 924 extensions, work in progress. 926 11.2 Informative References 928 [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task 929 Force and International Telecommunication Union - 930 Telecommunications Standardization Sector Collaboration 931 Guidelines", RFC 3356, August 2002. 933 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 934 Procedures", BCP 92, RFC 3932, October 2004. 936 Authors' Addresses 938 Loa Andersson 939 Acreo AB 940 Email: loa@pi.se 942 Adrian Farrel 943 Old Dog Consulting 944 Email: adrian@olddog.co.uk 945 George Swallow 946 Cisco Systems 947 Email: swallow@cisco.com 949 Deborah Brungard 950 AT&T 951 Email: dbrungard@att.com 953 Bill Fenner 954 AT&T 955 Email: fenner@research.att.com 957 Ross Callon 958 Juniper Networks 959 Email: rcallon@juniper.net 961 Kireeti Kompella 962 Juniper Networks 963 Email: Kireeti@juniper.net 965 Alex Zinin 966 Alcatel 967 Email: zinin@psg.com 969 Scott Bradner 970 Harvard University 971 Email: sob@harvard.edu 973 Intellectual Property Statement 975 The IETF takes no position regarding the validity or scope of any 976 Intellectual Property Rights or other rights that might be claimed to 977 pertain to the implementation or use of the technology described in 978 this document or the extent to which any license under such rights 979 might or might not be available; nor does it represent that it has 980 made any independent effort to identify any such rights. Information 981 on the procedures with respect to rights in RFC documents can be 982 found in BCP 78 and BCP 79. 984 Copies of IPR disclosures made to the IETF Secretariat and any 985 assurances of licenses to be made available, or the result of an 986 attempt made to obtain a general license or permission for the use of 987 such proprietary rights by implementers or users of this 988 specification can be obtained from the IETF on-line IPR repository at 989 http://www.ietf.org/ipr. 991 The IETF invites any interested party to bring to its attention any 992 copyrights, patents or patent applications, or other proprietary 993 rights that may cover technology that may be required to implement 994 this standard. Please address the information to the IETF at 995 ietf-ipr@ietf.org. 997 Disclaimer of Validity 999 This document and the information contained herein are provided on an 1000 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1001 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1002 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1003 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1004 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1005 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1007 Copyright Statement 1009 Copyright (C) The Internet Society (2006). This document is subject 1010 to the rights, licenses and restrictions contained in BCP 78, and 1011 except as set forth therein, the authors retain all their rights.