idnits 2.17.1 draft-ietf-problem-process-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (January 9, 2004) is 7385 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) ** Downref: Normative reference to an Informational draft: draft-ietf-problem-issue-statement (ref. '1') ** Obsolete normative reference: RFC 2727 (ref. '2') (Obsoleted by RFC 3777) -- Obsolete informational reference (is this intentional?): RFC 3160 (ref. '7') (Obsoleted by RFC 4677) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Problem Statement E. Davies, Ed. 3 Internet-Draft Nortel Networks 4 Expires: July 9, 2004 J. Hofmann, Ed. 5 Wissenschaftszentrum Berlin 6 January 9, 2004 8 IETF Problem Resolution Process 9 draft-ietf-problem-process-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 9, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document suggests processes to address some of the problems 40 identified in the IETF Problem Statement. 42 This document decomposes each of the problems described in the 43 problem statement into a few areas for improvement, categorizes them 44 either as problems affecting the routine processes used to create 45 standards or problems affecting the fundamental structure and 46 practices of the IETF, and suggests ways to address the problems with 47 the routine processes that can be implemented as soon as possible 48 without disrupting other areas of the IETF processes. 50 A number of ways to handle development of solutions for the structure 51 and practices problems have been proposed in Internet drafts, on the 52 Problems WG mailing list and at an IETF 57 plenary session in Vienna 53 during July 2003. This draft lists the various solutions that have 54 been proposed but neither the working group nor the wider IETF has 55 reached consensus on a recommendation for any of the proposals. 57 In this situation, this draft has no alternative but to suggest that 58 the search for structure and practices solutions is handed back to 59 the control of the IESG. 61 Status of the Content of this Memo 63 This Informational memo is being released to record the history of 64 discussions by the Problem WG in 2003. While there was working group 65 consensus on the portions of the document describing processes for 66 short-term and medium term improvements, there was no working group 67 consensus on the proposals for longer-term improvements. Those are 68 included in the document as a matter of record but must not be 69 regarded as recommendations from the working group. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 75 1.2 Major Changes between Versions 01 and 02 . . . . . . . . . . 5 76 1.3 Major Changes between Versions 02 and 03 . . . . . . . . . . 5 77 1.4 Changes between Versions 03 and 04 . . . . . . . . . . . . . 6 78 2. IETF Purpose and Core Values . . . . . . . . . . . . . . . . 6 79 2.1 Non-Core Values . . . . . . . . . . . . . . . . . . . . . . 6 80 3. Building on our Success . . . . . . . . . . . . . . . . . . 7 81 4. Problem Decomposition . . . . . . . . . . . . . . . . . . . 8 82 4.1 Decomposition of Mission Problem . . . . . . . . . . . . . . 9 83 4.2 Decomposition of the Engineering Practices Problem . . . . . 9 84 4.3 Decomposition of the Complex Problems Problem . . . . . . . 10 85 4.4 Decomposition of the Standards Hierarchy Problem . . . . . . 10 86 4.5 Decomposition of the Engagement Problem . . . . . . . . . . 11 87 4.6 Decomposition of the Management Scaling Problem . . . . . . 12 88 4.7 Decomposition of the Working Group Practices Problem . . . . 13 89 4.8 Decomposition of the Preparedness Problem . . . . . . . . . 13 90 5. Process Recommendations . . . . . . . . . . . . . . . . . . 14 91 5.1 Improvements to Routine Processes . . . . . . . . . . . . . 14 92 5.1.1 Suggestions to Improve WG Quality Processes . . . . . . . . 16 93 5.1.2 Suggestions to Increase the Use of Tools . . . . . . . . . . 16 94 5.1.3 Suggestions to Improve Training . . . . . . . . . . . . . . 16 95 5.1.4 Suggestions to Increase WG Chair Communication . . . . . . . 16 96 5.1.5 Suggestions to Improve Maintenance of Standards . . . . . . 17 97 5.2 Changing the Structure and Practices of the IETF . . . . . . 17 98 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 100 Normative References . . . . . . . . . . . . . . . . . . . . 20 101 Informative References . . . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 103 Intellectual Property and Copyright Statements . . . . . . . 22 105 1. Introduction 107 This document suggests processes to address several problems facing 108 the Internet Engineering Task Force (IETF) that have been described 109 in the IETF Problem Statement [1]. 111 This document begins with an outline of what are currently thought to 112 be the purpose and core values of the IETF, and it offers a reminder 113 of the good things about the IETF that we don't want to lose in the 114 process of solving our problems. 116 Each of the problems described in the problem statement is analyzed 117 and decomposed into a few areas for improvement. The areas for 118 improvement appear to fall into two categories: 120 o Areas that are essentially independent of the other problems and, 121 hence, can be addressed immediately, via discrete, minimally 122 disruptive changes or improvements to the 'routine' processes of 123 the IETF. 125 o Areas that are interdependent and are likely to affect structural 126 matters that characterize the way in which the IETF operates. 127 Addressing these areas will probably need a more integrated 128 approach, as they may require actions such as fundamental changes 129 to our organizational structure or standards-track processes. 131 It is suggested that the IETF work on these two classes of 132 improvements in parallel, so that we can enjoy some near-term 133 benefits while more structural improvements are being carefully 134 considered and executed. 136 Concrete suggestions are included for how we can begin or continue 137 work on the independent routine improvements. 139 Due to lack of consensus, no firm suggestions are included on how to 140 address the more structural changes that may be needed. The draft 141 lists the various proposals which have been considered by the working 142 group and the wider IETF at the IETF 57 plenary session in Vienna, 143 July 2003. This draft can only suggest, as some participants have 144 proposed, that the IESG itself control the development of any 145 solutions to the structural problems. 147 1.1 Acknowledgements 149 The contents of this document were greatly influenced by members of 150 the Problem Statement WG editorial team: Rob Austein, Dave Crocker, 151 Elwyn Davies, Spencer Dawkins, Avri Doria, Jeanette Hofmann, Melinda 152 Shore and Margaret Wasserman. 154 Previous versions of this document were edited by Margaret Wasserman, 155 who was responsible for the original structuring of the solution. 157 In addition to the editorial team, the following people have provided 158 useful feedback on earlier versions of this document: Harald 159 Alvestrand, Randy Bush, Brian Carpenter, Leslie Daigle, James Kempf, 160 John Klensin, John Loughney, Keith Moore. 162 1.2 Major Changes between Versions 01 and 02 164 o The commentary on the individual core values in Section 2 was 165 removed. This commentary was interesting but it did not appear to 166 be relevant to the process proposal but was rather part of the 167 solution process to the structural problems of the IETF. It was 168 also unbalancing the document, making the introductory text too 169 long. 171 o The acknowledgements section was moved forwards to the 172 introduction. 174 o At IETF 57 and on the mailing list, the WG decided that the 175 proposal for a WG to address 'long-term' structural issues was 176 inappropriate, but neither the WG at the meeting and on the 177 mailing list since, nor the wider IETF in the plenary discussion 178 at IETF 57 has been able to come to consensus on an acceptable 179 alternative. Accordingly the new version of the draft is only 180 able to document this situation and propose that IETF stakeholders 181 come up with some alternatives which can be debated, and hopefully 182 one of them agreed on. The abstract, introduction, Section 5.2 and 183 conclusion have been modified to reflect this state of affairs, 184 and the Appendix which offered a proposed WG charter has been 185 removed. 187 o In the light of comments about the change processes being 188 potentially too slow, the descriptions of the problems as 189 'near-term' and 'long(er)-term' have been replaced by 'routine' 190 and 'structural' although 'near-term' is still used where it is 191 appropriate to emphasize that immediate action can be taken. 193 1.3 Major Changes between Versions 02 and 03 195 The draft now lists the various suggestions that have been floated as 196 ways forward for the structural changes problems, documents the 197 inability of the community to achieve consensus around any of these 198 proposals and suggests that the problem is remitted to the control of 199 the IESG. 201 1.4 Changes between Versions 03 and 04 203 Added note to head matter indicating the status of the content of the 204 draft. Modified the abstract slightly to avoid referring to this memo 205 as a draft. 207 2. IETF Purpose and Core Values 209 As we consider how to address the problems with the IETF processes 210 and organizational structure, it is important to keep in mind the 211 things about the IETF that we don't want to change -- our sense of 212 purpose, and the core values that give the IETF its unique identity. 214 At two IESG plenary meetings in 2002, the chair of the IETF, gave 215 presentations outlining his view of the purpose and core values of 216 the IETF which may serve as a useful basis for focusing on our 217 mission and core values. 219 At the IESG plenary in London in July 2002, it was stated that the 220 purpose of the IETF is to "produce high quality, relevant, and timely 221 technical standards for the Internet". Our organizational structure 222 and processes should be judged by how well they help us to achieve 223 that mission. 225 At the following IESG plenary in Atlanta, Georgia in November 2002, 226 five core values of the IETF were presented [8]: 228 "Cares for the Internet" 229 "Technically Competent" 230 "Open Process" 231 "Volunteer Core" 232 "Rough Consensus and Running Code" 234 2.1 Non-Core Values 236 Understanding our core values will also help us to understand the 237 long-standing features of the IETF that we can change without 238 compromising our values or sacrificing our unique identity. 240 During the November 2002 IESG Plenary, the IETF chair also presented 241 the following "non-core values" [8]: 243 - The division into WGs and Areas 244 - The three-step standards process 245 - The ASCII format for RFCs and I-Ds 246 - The format of IETF meetings 247 - The structure of WG mailing lists 248 - The powers of the IESG and IAB 250 These things were designed to help us achieve our goals in a way that 251 is consistent with our core values. If they are no longer effective, 252 we can and should change them. 254 3. Building on our Success 256 While focusing on our operational problems, we shouldn't forget that 257 the IETF is a very successful organization. We are responsible for 258 some of the most widely used communications standards in the world, 259 and we have contributed to the creation and growth of the Internet, 260 one of the greatest technical and social achievements of our time. 262 In good times, it is easy to succeed despite operational 263 inefficiencies, so organizations tend to ignore operational problems 264 and focus on their success. In bad times, organizations can become 265 overly critical of their own structure and processes, blaming the 266 organization for problems that are actually caused by outside forces. 268 We are currently suffering difficult times in the IETF and throughout 269 the communications industry. The IETF should be careful not to 270 unjustly blame our own organizational structure or processes for the 271 effects of industry-wide changes such as: 273 o Economic issues in the global communications industry, which are 274 causing increased scrutiny regarding expenses and 275 return-on-investment. These same factors are causing job changes 276 and uncertainty for many IETF participants. 278 o The commercialization of the Internet, which has drastically 279 increased the financial impacts of standardization. 281 o The convergence of the datacom and telecom sectors of the 282 communications industry, which has led to an influx of experienced 283 people into the IETF with a different culture and industry 284 perspective. 286 Although it is important to recognize and correct the serious 287 organizational problems currently facing the IETF, many of these 288 problems have existed for years, and the IETF has been successful in 289 spite of these issues. We should not overreact to these issues with 290 sweeping revolutionary changes to the IETF structure and processes. 291 Instead, we should focus on developing a culture of continuous 292 operational improvement through which we can evolve our 293 organizational structure and processes to make them more scalable and 294 effective. We should take this opportunity to develop the mechanisms 295 and processes that we can use to continually monitor and improve our 296 organizational effectiveness, both in good times and bad times. 298 The IETF currently has a large amount of valuable work underway, and 299 care should be taken not to disrupt or delay that work while we 300 address our organizational problems. 302 The IETF is also fortunate to have a large number of extremely 303 talented and dedicated individuals that serve in formal and informal 304 leadership roles throughout the organization. We should be careful 305 not to alienate or disenfranchise the IETF's key contributors and 306 those who provide the driving force for the work while making 307 organizational or process changes. 309 4. Problem Decomposition 311 The problem statement document lists seven root cause problems 312 currently facing the IETF, without making any judgments about the 313 relative priority of the problems (apart from the first one): 315 o Participants in the IETF do not share a common understanding of 316 its mission; 318 o The IETF does not consistently use effective engineering 319 practices; 321 o The IETF has difficulty handling large and/or complex problems; 323 o The three stage standards hierarchy is not properly utilized; 325 o The IETF's workload exceeds the number of fully engaged 326 participants; 328 o The IETF management structure is not matched to the current size 329 and complexity of the IETF; 331 o Working group practices can make issue closure difficult; and 333 o IETF participants and leaders are inadequately prepared for their 334 roles. 336 Analysis of these problems indicates that they can be decomposed into 337 several areas for improvement, some of which can be addressed 338 immediately by independent actions while others require greater 339 consideration and a more structured approach to a solution. 341 It is also important to note that the problem statement lists 342 problems that have been reported by some members of the IETF. 343 Although all of these problems are believed to exist, not all of 344 these problems are present in all parts of the IETF, and some of 345 these problems may in fact be symptoms of other problems. 347 4.1 Decomposition of Mission Problem 349 In order to determine the best organization and processes for the 350 IETF to fulfill its mission and achieve its goals, the organization 351 needs to articulate a common understanding of its current mission and 352 goals. Although it should be possible to reach an understanding of 353 the mission and goals of the IETF as an independent action, with no 354 disruption to current processes, this effort would be most valuable 355 as part of an effort to align the organization and priorities of the 356 IETF with its mission. 358 As part of understanding our mission, the IETF will need to identify 359 our stakeholders and understand how we serve them. We will need to 360 define the scope of the IETF, so that it is possible to determine 361 what is in-scope and out-of-scope for the organization. We will also 362 need to define our goals and priorities, and learn how to recognize 363 and measure our own progress and success. 365 A continuing review of the mission and goals of the IETF needs to be 366 undertaken to ensure that they remain aligned with technology 367 developments as well as the needs of the industry in general and our 368 stakeholders in particular. 370 Once an understanding of the mission and goals of the IETF has been 371 articulated, we should train new participants on those principles, so 372 that they can become quickly acclimated to the IETF culture. 374 4.2 Decomposition of the Engineering Practices Problem 376 The IETF lacks effective engineering practices in four major areas: 378 1. Failure to clearly define the scope of the work, engineering 379 trade-offs and acceptance criteria for each project. 381 2. Lack of effective mechanisms for issue tracking and/or document 382 change control. 384 3. Lack of effective processes to ensure quality throughout the 385 development of IETF work items, such as intermediate acceptance 386 criteria or formal review processes. 388 4. Sufficient focus on milestones, and recognition or rewards for 389 individuals or groups that achieve timely, high quality 390 execution. 392 Some of these areas (issue tracking and revision control) would 393 require that tools are made available to WG chairs and editors, and 394 that IETF participants (at various levels) are educated in how to use 395 them. 397 The other areas concern the formation and process management of IETF 398 WGs, and would require documentation and adoption of effective 399 engineering processes within IETF WGs. 401 4.3 Decomposition of the Complex Problems Problem 403 The IETF has effective mechanisms for dealing with well-defined 404 problems of limited scope. These problems are well handled in IETF 405 WGs, where experts in a given technology can convene and solve the 406 problems specific to one technology area. However, we are much less 407 effective at resolving complex problems that affect more than one 408 IETF WG or area. 410 Today most communication between WG chairs, especially across area 411 boundaries, goes through the IESG. Some inter-WG or inter-area 412 communication problems could be alleviated by greater communication 413 and coordination directly between the chairs of related WGs. There 414 are some immediate efforts underway that are intended to increase 415 communication between WG chairs. 417 Other complex problems involve higher-level issues, such as unified 418 architecture or highly-coordinated multi-area efforts. As part of any 419 IETF reorganization, we should consider management structures that 420 will allow us to achieve a better focus on architectural and 421 cross-area issues. 423 4.4 Decomposition of the Standards Hierarchy Problem 425 There are several problems with the IETF's three-track standards 426 process. These problems can be grouped as follows: 428 o The three standards-track steps are not used effectively within 429 the IETF. 431 o The IETF standards-track is not well understood by the users of 432 IETF standards. 434 o The current standards process does not make it easy for users to 435 locate a set of related documents, such as an architectural 436 framework and associated protocols. 438 o The IETF does not have an effective way to maintain IETF 439 standards. 441 Major changes to the standards-track should only be considered as 442 part of an integrated structural review process that includes an 443 understanding of our mission and goals. 445 However, there may be immediate changes that we could make to better 446 maintain current IETF standards, or to make them more accessible to 447 users. 449 4.5 Decomposition of the Engagement Problem 451 The engagement problem can be decomposed into three primary issues: 453 o Some WGs do not have sufficient participation, and WG documents 454 are often produced by very small groups of people, perhaps with 455 limited expertise in some relevant areas. 457 o WG documents are not adequately reviewed by people outside of the 458 originating WG. 460 o People lose interest in longer-lived WGs, especially when 461 protocols take a very long time to develop. 463 When too few people, or people representing too few areas of 464 expertise, review WG documents this can result in poor quality 465 output. We need to find ways to increase the effectiveness of 466 document review at all levels. 468 Quality processes based entirely on a gatekeeper at the end, whether 469 that gatekeeper is the IESG or a WG review board, tend to result in a 470 lower focus on quality by other participants. So, it is likely that 471 instituting better quality processes throughout document development, 472 including acceptance criteria and review at several stages, would 473 increase the focus of WG participants on document quality. 475 When the interest of document editors or key contributors starts to 476 flag, this can cause serious problems for a WG. This most often 477 happens when WGs are floundering, or when charters are so loose that 478 WGs lose focus. It also happens when WG documents get delayed in AD 479 review and/or IESG review for long periods with little feedback, or 480 when the WG lacks consensus to progress its documents. Improvements 481 to our processes for chartering, tracking or managing WGs could help 482 to alleviate many of these problems. 484 We also need to better understand what motivates people to become 485 deeply engaged in the IETF and to remain engaged. It is possible that 486 expanding the number of formal leadership positions and/or coming up 487 with more effective ways to acknowledge our top technical 488 contributors could encourage more people to become, and remain, 489 deeply engaged in IETF 491 4.6 Decomposition of the Management Scaling Problem 493 There are several issues grouped into the concept that the management 494 structure of the IETF is not well matched to the size and complexity 495 of the organization. One or two of these problems might be addressed 496 by immediate solutions, but resolving the primary problem will 497 require some type of IETF reorganization. 499 There are four major areas for improvement that are grouped under 500 this problem: 502 o The current organization of the IETF does not scale. IESG members 503 are running too many WGs, reviewing too many documents, etc. Most 504 IESG members have dozens of direct reports (WG chairs, directorate 505 members, etc.). In its current form, there are very few people who 506 could do a good job as an IESG member, and the huge time 507 commitment and responsibilities of this role make it very 508 difficult to find qualified people who are willing to serve on the 509 IESG. 511 o Current IESG members and other IETF leaders are overloaded. 513 o The IETF selection processes have tended to select leaders (IESG, 514 IAB and WG chairs) from the same small pool of people. The IETF 515 needs to identify and develop additional leadership, and to 516 delegate real authority and influence to a larger group. 518 o The IETF is not effective at identifying and developing new 519 leaders, and we lack sufficient recognition for the contributions 520 of IETF participants. 522 o One or two IESG members can block WG documents indefinitely (in AD 523 review or IESG review). 525 Some level of IETF reorganization is needed to improve in the first 526 two areas. This should be undertaken as part of the structural 527 improvement effort. 529 In parallel with any more structural IETF reorganization, some relief 530 could be achieved by modifying IESG internal processes to remove the 531 potential for one or two IESG members to indefinitely delay a WG 532 document, either on purpose or due to work overload. The I-D tracker 533 has already resulted in some improvement in this area, as it has 534 created visibility regarding how and why a document is being delayed, 535 but it may not have resolved all of the issues in this area. 537 The IESG may also be able to take near-term steps, with community 538 visibility and agreement, to delegate more work to WG chairs, to 539 directorates, to the IAB, or to other to people in formal or informal 540 leadership positions. If additional leadership positions are needed 541 for this purpose, the IESG should consider creating them. 543 The IESG could also help to expand the leadership pool of the IETF by 544 actively seeking interested and qualified people for leadership 545 positions, and by using more open processes for the selection of WG 546 chairs and other influential positions. 548 4.7 Decomposition of the Working Group Practices Problem 550 Although "rough consensus" is considered a core value of the IETF, 551 consensus-based decision making works best in smaller groups with a 552 common viewpoint and common goals. Somehow we need to resolve the 553 apparent conflict between our core values regarding rough consensus, 554 and our desire to be an effective organization with several thousand 555 participants. 557 Although consensus-based decision making has some inherent issues, 558 there are some problems in the IETF that exacerbate these issues: 560 o WG chairs may lack the skills and training to deal with common 561 behavior problems that undermine or prevent consensus. 563 o IETF participants are often unaware of how the IETF 564 decision-making processes are intended to work. 566 o WG chairs and participants often lack good conflict resolution 567 skills. 569 Each of these issues could be addressed through training or other 570 educational resources. 572 4.8 Decomposition of the Preparedness Problem 574 The IETF could benefit from training and educational resources that 575 increase the preparedness of IETF participants and leaders at all 576 levels. 578 The IETF currently has formal training programs for new attendees and 579 for new working group chairs. However, our current training programs 580 could use some improvement. There are also several other groups who 581 could benefit from training or other forms of development (web 582 tutorials, on-line resources, references, mentoring, etc.), including 583 continuing attendees, experienced WG chairs, document editors and 584 IESG members. 586 There is an effort underway to improve the IETF's internal education 587 programs, and we recommend that it be continued. 589 5. Process Recommendations 591 It is the overall recommendation of this document that we pursue 592 near-term improvements to resolve IETF problems of routine in 593 parallel with an integrated effort to reorganize the IETF and improve 594 our standards processes. None of the efforts suggested in this 595 document should be blocked pending the completion and publication of 596 this document. Ongoing efforts should continue, and new efforts 597 should start as soon as there is IETF consensus that they are 598 worthwhile. 600 In our improvement processes, we should attempt to focus our 601 near-term improvements on areas of routine that are less likely to be 602 substantially modified by any proposed structural changes, thus 603 minimizing the likelihood of double changes. 605 5.1 Improvements to Routine Processes 607 Many of the problems currently facing the IETF can be resolved, or 608 mitigated, through near-term improvements to our current IETF 609 organization and routine processes. Many of these improvements are 610 completely separable, and there is no reason to aggregate these 611 efforts into a single IETF WG. It is also unnecessary that all of 612 these changes be directed by the (already overworked) IESG. 614 However, in order to prevent the chaos and confusion that could be 615 caused by trying to change everything at once, it is recommended that 616 we choose a few high priority areas for improvement and focus on 617 making improvements in those areas. 619 In choosing which areas to pursue first, we should consider the 620 following criteria: 622 o We should address our most urgent, important problems. 624 o The areas chosen should be cleanly separable, to allow multiple 625 improvements to be carried out in parallel with minimal 626 interference. 628 o We should maximize the benefit vs. the cost of making the 629 improvements (i.e. look for low hanging fruit). 631 o As much as possible, we should focus on improvements that are less 632 likely to be completely invalidated by an overhaul of the IETF 633 management structure. This might be accomplished by focusing on 634 improvements at the WG and participant levels, rather than at the 635 IESG/IAB level. 637 In the sections above, we have identified several areas of routine 638 that could benefit from near-term improvements, including: 640 1. Improve WG quality processes and the effectiveness of document 641 reviews at all levels. 643 2. Increase the availability and use of issue tracking and document 644 sharing/revision control software in the IETF. 646 3. Improve training and resources for IETF leaders and participants 647 at all levels. 649 4. Improved communication between WG chairs to identify and resolve 650 inter-WG and inter-area problems. 652 5. Consider IETF processes or structures to better maintain IETF 653 standards. 655 6. Modify IESG-internal processes to make it impossible for one or 656 two IESG members to indefinitely delay a document. 658 7. Modify IESG processes to delegate more responsibility to WG 659 chairs, to directorates, to the IAB or to people in other formal 660 or informal leadership positions. 662 8. Modify the WG chair selection processes to widen the group of 663 people considered, and consider ways to develop more leaders for 664 the IETF. 666 9. Initiate regular AD review of WG milestones and progress. 668 Applying the criteria outlined above, it would make the most sense to 669 address areas 1, 2, 3, 4 and 5 through immediate near-term efforts. 670 These are high-priority issues, they are sufficiently separable to be 671 pursued in parallel, they place minimal additional burden on the 672 IESG, and they are the least likely to be affected by an IESG/ 673 IAB-level reorganization of the IETF, or by changes to the 674 standards-track document maturity level classification and process. 675 Specific recommendations for how to proceed in each of these areas 676 are made in the following sections. 678 The IESG should consider internal changes to address areas 6, 7 and 679 8. Area 9 would require a substantial time commitment from IESG 680 members, so it is not suggested that near-term improvements be 681 pursued in this area, unless the IESG believes that the near-term 682 benefits would justify the effort. 684 5.1.1 Suggestions to Improve WG Quality Processes 686 A working group should be formed in the General Area of the IETF to 687 oversee improvements to the WG quality processes, including: The WG 688 (re-)chartering process, the quality processes used by IETF WGs, and 689 the effectiveness of IETF reviews at all levels. It should be the 690 goal of this WG to improve the quality and timeliness of WG work 691 output. This WG would be chartered to resolve the non-tools- related 692 portions of the Engineering Practices problem (Section 4.2) the 693 WG-related portions of the Engagement Problem (Section 4.5), and the 694 non-training-related portions of the WG Practices problem (Section 695 4.7). 697 A great deal of efficiency and synergy can be achieved by adopting 698 common processes throughout an organization. However, it is a 699 strength of the IETF that WG chairs are given a great deal of 700 latitude to choose their own processes and tools, based on the size 701 and nature of their WGs. So, in general, processes and tools should 702 be made available to WGs and WG chairs, not forced upon them. 704 5.1.2 Suggestions to Increase the Use of Tools 706 Ideally, the proliferation of tools within the IETF would be 707 accomplished via grass-roots efforts, organized by participants 708 within the IETF. One example of this type of effort is the recent 709 adoption of Jabber for use during IETF meetings. 711 However, it is also possible that the IESG could designate functional 712 leaders for specific tools-related efforts and support those leaders 713 in organizing those efforts. It also might be helpful for the IETF to 714 set-aside some technical and systems resources, to make useful tools 715 available to WGs and participants throughout the IETF. 717 These efforts should resolve the tools-related portions of the 718 Engineering Practices problem (Section 4.2). 720 5.1.3 Suggestions to Improve Training 722 The current WG chairs and newcomer's training efforts should be 723 continued and expanded as possible to cover training for other 724 groups. This effort is expected to address the Preparedness problem 725 (Section 4.8), and the training-related portions of the Mission 726 Problem (Section 4.1) and the WG Practices problem (Section 4.7). 728 5.1.4 Suggestions to Increase WG Chair Communication 729 Some efforts are already underway to allow WG chairs to meet each 730 other, and to given them opportunities to establish communication 731 channels. These efforts include WG chair socials and training 732 sessions for experienced WG chairs. These efforts should be 733 continued. 735 The IESG could help to promote chair-to-chair communication by 736 encouraging direct communication between WG chairs when multi-WG 737 issues arise. 739 However, most of the responsibility for establishing effective 740 chair-to-chair communications channels lies with the individual WG 741 chairs. We should stop relying on the IESG to resolve inter-WG 742 issues, and start communicating with each other directly regarding 743 inter-WG issues. 745 These efforts may help to alleviate the Complex Problems problem 746 (Section 4.3), although a comprehensive solution to that problem 747 would probably require some changes to the IETF management 748 structures. 750 5.1.5 Suggestions to Improve Maintenance of Standards 752 The IETF should consider proposals to improve the way that IETF 753 standards are maintained. It might be possible for the IESG to 754 document and implement a mechanism to maintain IETF standards without 755 the need for a WG to enact this change. 757 This effort should address the maintenance-related portions of the 758 Standards Hierarchy problem (Section 4.4). 760 5.2 Changing the Structure and Practices of the IETF 762 A significant number of the issues that were identified in the IETF 763 Problem Statement appear to require alterations to the structure of 764 the IETF and/or the core practices which effectively characterize the 765 IETF. From the analysis in Section 4 the problems which might require 766 such alterations include: 768 o The Mission Problem (Section 4.1, [7]), 770 o the Complex Problems problem (Section 4.3, [3], [6]), 772 o the Standards Hierarchy problem (Section 4.4, [4]), 774 o the Management Scaling problem (Section 4.6, [6], [3], [2]), and 776 o The longer-term portions of the Engagement Problem (Section 4.5, 778 [5]) 780 (Additional references on each item indicate associated documents 781 that may need to be updated as a result of this process). 783 Poorly thought through changes to these areas could result in 784 irretrievable damage to the nature and effectiveness of the IETF, but 785 it seems essential that the necessary changes are identified and 786 accepted by the IETF community as quickly as possible. To achieve 787 acceptance by the largest possible number of IETF stakeholders, as 788 many of them as possible should be involved in the development of the 789 changes; the development and acceptance processes must be as open as 790 possible in line with normal IETF principles. 792 Development of the required changes under the aegis of a General Area 793 Working Group was extensively debated and a proposal was floated in a 794 previous version of this document. The proposal included a draft 795 charter for the working group. This way forwards has now been 796 rejected by the Problem working group because of 798 the perceived slow progress of such groups, 800 the difference in the nature of the problem from the usual 801 technical problems solved by IETF working groups and 803 the difficulty in achieving acceptance by all segments of the 804 community for work driven by a small group. 806 A proposal for coordination of the development of the structural 807 changes by a 'Strategy and Answers Panel' composed of delegates from 808 IESG, IAB and ISOC plus a number of members from the wider IETF 809 community (forming a small majority of the panel) selected using the 810 nomcom selection process can be found in [9]. The selection process 811 was intended to create a panel which would represent the interests of 812 the whole IETF community and so build solutions that would be 813 acceptable to the whole community. This proposal has not received 814 extensive support from the Problem working group either. 816 Other proposals advanced in discussions are: 818 o Delegation of the development of solutions to a team of 'wise men' 819 appointed by the IESG. 821 o Development of solutions by a design team with final approval by 822 the IESG. 824 o Development and implementation of the solutions by the IESG. 826 Discussions of alternative processes on the mailing list, at the 827 Problem WG meeting at IETF 57 and in the IETF 57 plenary did not 828 reach a consensus. Indeed some contributors took the view that the 829 problems could be overcome without (major) structural changes. 831 Given the lack of consensus and the lack of additional responses to a 832 previous appeal for alternative suggestions, this document has to 833 fall back to asking the IESG to take responsibility for controlling 834 the development of solutions to the structural problems identified 835 where it believes they are necessary. 837 6. Conclusion 839 The IETF has problems, and we need to work to solve those problems, 840 both via focused immediate improvements and possibly via an 841 integrated effort to build an IETF organizational structure and 842 develop processes that can better handle our current size and 843 complexity. 845 However, the IETF is also an effective organization with a long 846 tradition of excellence, and core values that we don't want to 847 compromise in the course of improving our organization and processes. 848 So, any major changes undertaken in the IETF should include an 849 articulation of the IETF's mission and our core values, so that we 850 can ensure that we build an organization that can carry out our 851 mission working in line with our core values. 853 The Problem WG has not been able to come to a consensus on a process 854 that could address the structural changes that may or may not be 855 needed. This is perhaps in line with previous experience of the 856 discussion of high level concepts in the IETF - the organization is 857 in general much better at discussion of and achieving consensus on 858 detailed concrete proposals. This document has little alternative 859 but to suggest that the IESG control the development of solutions to 860 any of the structural problems where they feel that changes are 861 necessary. 863 In the meantime, this should not be seen as gating discussions on 864 actual solutions for these problems - for example, the active 865 discussions that are in progress on alternatives to the current 866 maturity level system for IETF standards. Authors of solutions 867 should bear in mind the points made in Section 3: Evolutionary 868 rather than revolutionary proposals are more likely to be acceptable, 869 and an orderly transition must be possible. 871 Working together, we can resolve the problems currently facing the 872 IETF and make the IETF an even more effective, successful and fun 873 place to work. 875 7. Security Considerations 877 This document contains suggestions for processes that the IETF could 878 use to resolve process-related and organizational problems with the 879 IETF. Although the structure and quality of the IETF's processes may 880 have an affect on the quality of the IETF's security- related work, 881 there are no specific security-related issues raised in this 882 document. 884 Normative References 886 [1] Davies, E., "IETF Problem Statement", 887 draft-ietf-problem-issue-statement-05 (work in progress), Oct 888 2003. 890 [2] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall 891 Process: Operation of the Nominating and Recall Committees", RFC 892 2727, Feb 2000. 894 Informative References 896 [3] Alvestrand, H., "An IESG charter", draft-iesg-charter-03 (work 897 in progress), Apr 2003. 899 [4] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 900 2026, Oct 1996. 902 [5] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 903 25, RFC 2418, September 1998. 905 [6] Carpenter, B., "Charter of the Internet Architecture Board 906 (IAB)", RFC 2850, May 2000. 908 [7] Harris, S., "The Tao of IETF - A Novice's Guide to the Internet 909 Engineering Task Force", RFC 3160, August 2001. 911 [8] IETF, "Minutes of IESG Plenary at IETF55, Atlanta, GA, USA", , 912 Nov 2002, . 915 [9] Davies, E., Doria, A. and J. Hofmann, "IETF Structural Problems 916 Improvement Process", draft-davies-structural-rev-process-00 917 (work in progress), September 2003. 919 Authors' Addresses 921 Elwyn B. Davies (editor) 922 Nortel Networks 923 Harlow Laboratories 924 London Road 925 Harlow, Essex CM17 9NA 926 UK 928 Phone: +44 1279 405 498 929 EMail: elwynd@nortelnetworks.com 931 Jeanette Hofmann (editor) 932 Wissenschaftszentrum Berlin 933 Reichpietschufer 50 934 Berlin 10785 935 Germany 937 Phone: +49 30 25491 288 938 EMail: jeanette@wz-berlin.de 940 Intellectual Property Statement 942 The IETF takes no position regarding the validity or scope of any 943 intellectual property or other rights that might be claimed to 944 pertain to the implementation or use of the technology described in 945 this document or the extent to which any license under such rights 946 might or might not be available; neither does it represent that it 947 has made any effort to identify any such rights. Information on the 948 IETF's procedures with respect to rights in standards-track and 949 standards-related documentation can be found in BCP-11. Copies of 950 claims of rights made available for publication and any assurances of 951 licenses to be made available, or the result of an attempt made to 952 obtain a general license or permission for the use of such 953 proprietary rights by implementors or users of this specification can 954 be obtained from the IETF Secretariat. 956 The IETF invites any interested party to bring to its attention any 957 copyrights, patents or patent applications, or other proprietary 958 rights which may cover technology that may be required to practice 959 this standard. Please address the information to the IETF Executive 960 Director. 962 Full Copyright Statement 964 Copyright (C) The Internet Society (2004). All Rights Reserved. 966 This document and translations of it may be copied and furnished to 967 others, and derivative works that comment on or otherwise explain it 968 or assist in its implementation may be prepared, copied, published 969 and distributed, in whole or in part, without restriction of any 970 kind, provided that the above copyright notice and this paragraph are 971 included on all such copies and derivative works. However, this 972 document itself may not be modified in any way, such as by removing 973 the copyright notice or references to the Internet Society or other 974 Internet organizations, except as needed for the purpose of 975 developing Internet standards in which case the procedures for 976 copyrights defined in the Internet Standards process must be 977 followed, or as required to translate it into languages other than 978 English. 980 The limited permissions granted above are perpetual and will not be 981 revoked by the Internet Society or its successors or assignees. 983 This document and the information contained herein is provided on an 984 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 985 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 986 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 987 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 988 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 990 Acknowledgement 992 Funding for the RFC Editor function is currently provided by the 993 Internet Society.