idnits 2.17.00 (12 Aug 2021) /tmp/idnits38314/draft-hardie-12-2-1-00.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: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 588 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hardie 3 Internet-Draft Qualcomm, Inc. 4 June 2003 6 Twelve heresies, two visions, and one belief 7 draft-hardie-12-2-1-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 The IETF brings together a technical community that shares a 37 common dedication to making the best possible engineering choices 38 and protocol standards for the Internet as whole. The community 39 shares a number of common beliefs, which create the basis of a 40 common work style and inform many of the decisions made within the 41 IETF. As in many communities of believers, some of these beliefs 42 have been elevated to the status of dogma. In the process of 43 considering reform, the treatment of these as unquestionable may 44 be hindering progress. This document challenges some of the 45 beliefs which the author believes have become dogmatic. It also 46 presents two visions for the evolution of the IETF and articulates 47 a single belief. 49 1. The Heresies 51 1.1 Rough consensus. 53 "rough consensus and running code" is a way to judge whether or 54 not an an idea will work, not a goal in and of itself. 56 Dave Clark's much-quoted credo for the IETF cites "rough consensus 57 and running code" as the key criteria for decision making in the 58 IETF. Aside from a pleasing alliteration, these two touchstones 59 provide a concise summary of the ideals which guide the IETF's 60 decision making. The first implies an open process in which any 61 technical opinion will be heard and any participant's concerns 62 addressed; the second implies a recognition that any decision must 63 be grounded in solid engineering and the known characteristics of 64 the network and its uses. As touchstones, they are excellent. 65 The aim of the IETF is to make the best possible engineering 66 choices and protocol standards for the Internet as a whole, and 67 these two statements should guide it in making its choices and 68 standards. 70 Note, though, that they should be guidelines, not inflexible 71 rules. We rely on this viewpoint as a way of judging things for 72 many situations, but we can't be hamstrung by it. There are times 73 when the IETF's need to make a decision on a technical point may 74 be greater than its need to use consensus as a process to reach 75 that goal. RFC 3127 documents one such occasion. There are 76 others where the failure to use other methods delayed or destroyed 77 important efforts, and these occasions should warn us not to treat 78 this advice as dogma. 80 1.2 Working group participation. 82 Working groups need to identify their participants. 84 The IETF uses an open process which allows technical contributions 85 from any one, regardless of affiliation or attendance. This is a 86 good thing. A bad thing which has arisen from that good thing is 87 a reluctance to identify the participants in a working group 88 effort, presumably out of fear that working group "members" will 89 ignore the input of those who are not members and that the 90 openness will thus be compromised. Openness is important, but the 91 result of this choice can be broken working group processes. 92 Chairs and document authors may have to make generic pleas for 93 participation or document review, rather than asking specific 94 individuals to undertake those tasks. Since some of those who 95 might be willing if asked instead assume someone else will take 96 the task, participation is reduced despite there being a pool of 97 participants who are fundamentally committed to the work. 99 Identifying working group participants acknowledges that the IETF 100 is much larger than the current pool of authors or slate of Area 101 Directors and working group chairs. Making participation more 102 explicit improves the ability of those outside a particular effort 103 to tap expertise in it and enables the organization to identify 104 those who may be ready to take on new roles as authors, chairs, or 105 mentors. Identifying participants should not exclude technical 106 comments from those outside an effort who review its work, and 107 checks and balance may, of course, still be needed to make sure 108 such exclusion does not occur. 110 1.3 Working group oversight. 112 Self-organizing working groups need oversight to ensure that the 113 decisions they reach are the best decisions for the Internet as a 114 whole. 116 A rational decision for a working group may not be the right 117 decision for the IETF as a whole. From some perspectives, it may 118 be rational to resist change to deployed clients, even though they 119 contribute to congestion or lack security. It may be rational to 120 avoid interoperability with competing systems, so that a larger 121 scope for the current effort may be planned. It may even be 122 rational for the working group to replicate at one layer a suite 123 of services developed or being developed at another, so as to 124 avoid dependencies. 126 At the moment, the IETF has poor mechanisms to deal with those 127 tensions, even though most IETF participants would agree that 128 congestion control, security, interoperability, and the reuse of a 129 common core set of services are all laudable design goals. The 130 community reviews charters and constrains them such that efforts 131 are expected to meet certain design goals. There can be pushback 132 during IETF Last Call or during the IESG's review. Fundamentally, 133 though, we trust that participants have internalized the issues 134 and that they, therefore, will handle the tension themselves. 136 That can and does work, but we need other mechanisms to reinforce 137 it: some of those may be training, some may be structural reviews 138 at periodic intervals, and some may be creating methods to ensure 139 that cross-speciality expertise is more consistently available. 140 Some form of oversight is required, though, to ensure that it has 141 worked. The current form, though, is not the only possibility. 142 The IETF might shift to a system in which working groups are not 143 entirely self-organizing but instead requires participation by 144 those with specific expertise or points of view (e.g. security, 145 operations), so that "oversight" is in fact part of normal working 146 group processes. It also might mean oversight by bodies other 147 than those currently handling the task, but with the same duty to 148 examine the working group's output from the broader perspectives 149 available outside the group or its area. 151 1.4 Interim meetings. 153 Interim meetings are not inherently a bad thing. 155 Working groups need to make progress throughout the year, not 156 just in the period immediately before and after an IETF plenary 157 meeting. While the IETF's main mode of operations, working on 158 mailing lists, supports this goal, face to face time can help. 159 Face to face meetings or open conference calls can help a group 160 make progress by helping focus the participant's efforts and by 161 providing for a quicker exchange of ideas than is possible on 162 mailing lists. Interim meetings can be just as open to those 163 doing the work as the plenary meetings, provided they are 164 well-advertised, planned sufficiently far in advance, and take 165 into account the need for fairness in travel budgeting when 166 selecting locations. 168 Interim meetings do not allow for the same level of interaction 169 outside the core participant group as is allowed by IETF plenary 170 meetings, but minuted results provide a reasonable degree of 171 openness for those not actively engaged in the work. 173 1.5 Areas. 175 It does make sense to group work together. 177 The existence of useful directorates outside the set of current 178 areas (e.g the LDAP directorate or XML directorate) indicates 179 that this grouping may in fact be valuable at multiple levels, 180 and that some groupings may intersect. The current set of areas 181 and interactions may or may not make sense and may or may not be 182 sufficient, but the idea is fundamentally sound. 184 1.6 Dependencies. 186 The work of one group must be able to depend on the work of another. 188 An organization with expected output of the IETF must be able to 189 have the work of one unit depend on the work of another. Working 190 groups commonly divide their work into multiple related documents, 191 rather than trying to create a single, monolithic specification. 192 The IETF as a larger community needs to be able to do the same 193 thing, by allowing specific groups' work to depend on that being 194 done at other layers or in other areas. One advantage the IETF 195 has in open review and input is that when one group's lack of 196 conclusive output is gating other work, those waiting can add 197 their energy to the working group they depend on. 199 1.7 One way. 201 There is no fundamental requirement that the IETF use a single way 202 to make decisions or progress standards. 204 While it is important to specify the ways decisions happen and 205 progress is made, there is no reason to assume that one single 206 process must be used in all cases. Having multiple ways of doing 207 things that fit different circumstances allows us to focus on the 208 output needed, rather than the process used to achieve it. As we 209 consider reform, we must recognize that replacing one single way 210 of doing the work with any other single way of doing the work will 211 move the pain, but may accomplish little else. 213 1.8 Legal fiction. 215 The IETF operates under a legal fiction that relates its work to 216 ISOC; that fiction needs to be replaced with a new legal fiction 217 that lets the IETF stand apart. 219 The legal fiction that the IETF is an organized activity of ISOC 220 grew out of the need for the IETF to have an organizational home 221 that could provide insurance, legal counsel, and related services. 222 The author believes that it also grew out of the reluctance of 223 many participants in the IETF to be pinned down as a membership 224 organization, for reasons articulated in 1.2, above. To restate 225 those reasons in an organizational form, the author believes that 226 there was considerable concern that those funding the IETF would 227 expect or receive treatment that limited the IETF's ability to 228 make the best engineering decisions for the Internet. Allowing 229 the IETF to exist as an activity, rather than an organization, put 230 it at one remove from direct funding and helped assuage those 231 fears. 233 The IETF existed prior to ISOC's formation, and has related to the 234 IAB, IRTF, RFC Editor and other organizations in ways very 235 different from those currently in place. The current legal 236 fiction has had a host of unintended consequences, and we find 237 ourselves at a moment when ending it makes sense. ISOC has a 238 stable income stream related to PIR's management of the .org TLD, 239 and it has itself created a new structure to refocus its 240 priorities. 242 The IETF, too, is considering reform and in so doing it has the 243 opportunity to put in place other mechanisms to ensure that it 244 retains the ability to make the best possible engineering 245 decisions while obtaining the ability to make more direct 246 decisions about its supporting organizations and external 247 relationships. 249 1.9 Paid staff. 251 The pride the IETF takes in having volunteer effort should not 252 blind the IETF to the opportunities that having paid staff may 253 represent. 255 There are already a number of critical services that the IETF 256 derives through Memoranda of Understanding or other contracts, and 257 the benefits in event planning, publication services, and related 258 capabilities are clear. There are other areas, such as working 259 group management, where the IETF does not use paid staff and where 260 doing so would represent a fundamental change in the nature of the 261 IETF. There are also, however, some grey areas where having paid 262 staff who worked directly for the IETF might be a significant 263 advantage. An IETF-employed executive director might logically 264 negotiate contracts on its behalf, for example, where one employed 265 via an MoU would be barred from negotiating at least that 266 contract, if not all contracts. 268 1.10 Document Series. 270 The existence of an independent, technical RFC editor is vital to 271 the ongoing dialog about what technologies and services will 272 improve the Internet. It is also best served by splitting the 273 document series so that IETF-produced documents and other 274 documents published by the RFC editor cannot be confused. 276 At the moment, there is a tension between the community's need and 277 desire for an open publication series which allows for 278 wide-ranging documents exploring the space of packet-switched 279 networking and the community's need for a clear set of 280 specifications for the protocols and practices it has developed. 281 Note, in particular, that the community needs for the set to be 282 clear as well as the documents themselves to be clear. This 283 tension means that attempts to publish the specifications which 284 have not been considered or selected by some working groups face 285 resistance that may derive from the need for a clear set, rather 286 than any inherent flaw in the ideas themselves. 288 The IETF has tried to assuage that tension by supplementary 289 marking, using the "standards track" and "Informational or 290 Experimental" as tags to indicate which documents do and do not 291 belong to the set. This effort has largely failed. It is blurred 292 partly by our own rules, which allow some IETF-produced or 293 set-relevant documents to use the same categories as those outside 294 the IETF set. It is also blurred by the ease of misunderstanding 295 the categories and the ease of elision of the supplementary 296 marking. 298 Further efforts to increase the supplementary marking, with "IESG 299 notes" and similar commentary take a great deal of time and increase 300 the tension between the two needs articulated above. There is also 301 no substantial indication that they are or will be more effective. 302 Eliminating these efforts and returning the others to primary markings 303 is both likely to be more effective and likely to increase the 304 freedom of the RFC editor to publish documents that, in its independent 305 judgement, should be part of the ongoing dialog on how to improve 306 the Internet. 308 1.11 Personalities. 310 The IETF community has consistently placed its trust in specific 311 individuals, trusting that they had the personal contacts, charisma, 312 or technical knowledge to resolve thorny problems. This trust is 313 a mistake. 315 It is not a mistake because the assessments of those individuals 316 are wrong; it is a mistake because it works around structural 317 problems with the effort and abilities of people who may not 318 always be available. To answer the question: "Should the reform 319 process be managed by the AD for the General area?" with "Sure, I 320 trust Harald to do the job." is confuse the personal abilities and 321 manner of the current person doing the job with the job itself. 322 To scale to a reasonable level, the IETF must be able to define 323 the work associated with specific roles. It can then recruit or 324 train people for those roles. Working the mechanism in reverse, 325 so that the individual's capacities are the primary gauge for 326 the scope of the job occupied, makes for serious succession problems. 328 1.12 Reform. 330 "If it ain't broke don't fix it" does not apply on a piecemeal 331 basis to complex systems. 333 In a reform process, ruling some items out of bounds for change 334 because they do not cause current pain is a mistake. If you 335 change any fundamental part of a system, you must consider whether 336 the other parts of a system need to be adjusted to handle new 337 load, tasks, or interactions. This does not mean that all change 338 must occur at once, but it does mean that the process of reform 339 must be open to change at all levels. 341 2. The Visions 343 2.1 New integration along traditional lines. 345 The author believes that the IETF has traditionally been 346 integrated in two different ways, one formal and one informal. 347 The formal integration relates to the steps of the standards 348 process and the precursor steps of working group formation and 349 chartering. The informal integration is an overlapping set of 350 personal relationships that allows participants to identify 351 skills, perspectives, or energy needed to complete the efforts 352 identified in the formal processes. During a period of rapid 353 growth and a follow-on period of contraction, the second system has 354 been strained to the point of failure. Though the IETF retains a 355 large pool of skilled professionals with energy and needed 356 perspectives, the overlap in personal networks is now not 357 sufficient to associate those with the efforts the IETF has taken 358 on. This has led to delay, lowered quality, and frustration, both 359 among those whose skills and perspectives are not appropriately 360 connected to salient efforts and among those whose efforts have 361 stalled for lack of energy or early input by those with relevant 362 expertise. 364 One path forward for the IETF is to retain much or all of its 365 current formal process, but take the traditionally informal lines 366 of integration and to increase its efforts to create and support 367 them. It may also have to shift some of those lines of 368 integration from the informal to the formal. The SIR proposal, 369 and especially its color-coded variant (SIRS), provides one 370 example of how the IETF might create a formal mechanism 371 (opportunity for early review by those outside an area) to replace 372 the informal mechanism of passing work back and forth among one's 373 colleagues. 375 Beyond that are a host of possible mechanisms. Having an 376 identifiable group of committed participants may create an esprit 377 de corps among those actively participating in a particular 378 working group that will carry on beyond the group's tasks. 379 Initial training sessions can create lines of contact both among a 380 cohort trained together and between those trained and the 381 trainers. That can be extended by fostering round table 382 discussions among participants from different groups, document 383 authors, and chairs. Cross-area and cross-working group 384 integration can be improved by setting up liaison roles. 385 Mentoring programs and peer review systems can be used to create 386 new lines of communication. The connection provided by 387 directorates can also be extended, both by having open-membership 388 directorates for some specific topics and by increasing the amount 389 of inter and intra-group communication expected. 391 None of the changes described above is a magic bullet, and none, 392 at first glance, creates much structural change in the IETF. Each 393 mechanism is, after all, an elaboration of something we already 394 do. It is, instead, a cultural change that suggests the real 395 strength of the IETF is that it brings together folks from 396 substantially different backgrounds who still share a common goal. 397 More importantly, it suggests that to retain that strength the 398 IETF needs to foster mechanisms that brings those folks together 399 early and often. It also presumes that with renewed strength in 400 this core area that the quality problems, delay, and frustration 401 can be addressed within the framework already established. 403 There is a long-held belief by some that the real work of any 404 organization gets done in hallways. For the IETF, the right 405 response to that may be to make sure that the networks of folks in 406 those hallways is vibrant, active, and just as open to new 407 membership and participation as its formal processes have always 408 been. That may mean moving some of those meetings out of the 409 hallway and into meeting rooms and mailing lists, but the 410 trade-off might be worth it. 412 2.2 Coordination as an alternate path. 414 The vision set out above presumes that the best result is an IETF 415 with approximately the same scope as it has now but an increased 416 effectiveness within that scope. More importantly, it presumes 417 that a tight integration among the different parts of the IETF 418 is of benefit to each of those parts. 420 One contrary view is that the right path may actually be to shift 421 to a model in which the different parts of the IETF are far more 422 loosely integrated than they are now. Under this view, the IETF 423 as a whole should become a coordinating body, which would create 424 and coordinate more focused organizations. To some extent, this 425 view recognizes that a great deal of the work of protocol 426 development and Internet engineering is done outside of the IETF 427 as it stands now, and that this is not likely to change. Rather 428 than attempting to change that fact, it suggests that the IETF 429 should evolve to be a coordinating body that can reconcile the 430 work both of its sub-organizations and those organizations outside 431 the current IETF which wish to be part of the larger framework. 432 It also answers the question of how to maintain informal personal 433 networks by suggesting that the natural size of an organization of 434 this type should be one in which the participants can or would 435 know each other personally. 437 Under such a system, the IETF would create individual 438 organizations for its areas or other suitable clusters of 439 activity, and it would then create a set of mechanisms to 440 coordinate the work in those activities. The individual 441 organizations might have working groups and directorates that 442 behave much as they do now, but the integration with other 443 organizations would be different. These mechanisms might include 444 liaisons, cross-cluster meetings and mailing lists, and periodic 445 review. That coordination could include organizations that have 446 historically been focused on specific applications of IETF 447 technology. 449 At the forefront of this vision of the IETF is the idea that the 450 field of protocol design and Internet engineering is very large 451 and getting larger, and that getting all of the work into a single 452 organization is unwieldy and unlikely. Rather than attempt it, it 453 suggests that the right answer is to create a group of smaller, 454 focused organizations that can take on specific roles. As a 455 coordinating body, the IETF's role would be both to charter new 456 organizations as needed and to coordinate them once chartered. 457 A critical part of that coordination would be ensuring that 458 work done in one organization is reviewed in other organizations 459 whose work would be effected. 461 To some extent, the IETF already holds this vision, since it does 462 not do all protocol design in a single working group or even a 463 single working group per area. Whether it wants to extend that 464 vision to clusters of working groups as a mechanism for scaling 465 may depend on how we balance the types of coordination. It would 466 also depend on the development of a host of subsidiary mechanisms 467 for coordination that we don't have now. Despite that dependence 468 on systems with no running code, there is an argument to be made 469 that this simply recognizes a reality--that groups spin off to 470 take on new tasks--and attempts to enable the IETF to retain a 471 coordination role after that has occurred. As the field expands, 472 this may well be one of the key ways that the IETF can help ensure 473 that engineering decisions take into account what's best for the 474 Internet as a whole. 476 3. The Belief. 478 The work is worth doing. 480 The IETF has no enforcement power. Every adherent to any standard 481 or engineering recommendation put forward by the IETF follows it 482 voluntarily. That makes clear that the work of the IETF is not to 483 manage the Internet, or even manage protocol development for the 484 Internet. The work of the IETF is to provide a community and set 485 of tools for those who want to see the Internet grow and develop; 486 nothing more. Nothing less. 488 That work is worth doing. 490 6. Security Considerations. 492 Any change to organizational structure creates risk that attackers 493 will be able to game the new system in ways they could not game the old. 495 7. IANA Considerations. 497 This document does contain any actions for IANA. 499 8. Normative References 501 None. 503 9. Non-Normative References 505 Mitton, D. et al. "Authentication, Authorization, and Accounting: 506 Protocol Evaluation", 507 RFC3127. (RFC3127) 509 Carpenter, B. et al. "Careful Additional Review of Documents (CARD) by 510 Senior IETF Reviewers (SIRS)" draft-carpenter-solution-sirs-01.txt 511 (SIRS) 513 10. Author's Address 515 Ted Hardie 516 Qualcomm, Inc. 517 675 Campbell Technology Parkway 518 Suite 200 519 Campbell, CA 520 U.S.A. 522 EMail: hardie@qualcomm.com 524 Full Copyright Statement 526 Copyright (C) The Internet Society (2003). All Rights Reserved. 528 This document and translations of it may be copied and furnished to 529 others, and derivative works that comment on or otherwise explain it 530 or assist in its implementation may be prepared, copied, published 531 and distributed, in whole or in part, without restriction of any 532 kind, provided that the above copyright notice and this paragraph are 533 included on all such copies and derivative works. However, this 534 document itself may not be modified in any way, such as by removing 535 the copyright notice or references to the Internet Society or other 536 Internet organizations, except as needed for the purpose of 537 developing Internet standards in which case the procedures for 538 copyrights defined in the Internet Standards process must be 539 followed, or as required to translate it into languages other than 540 English. 542 The limited permissions granted above are perpetual and will not be 543 revoked by the Internet Society or its successors or assigns. 545 This document and the information contained herein is provided on an 546 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 547 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 548 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 549 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 550 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Acknowledgement 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.