idnits 2.17.00 (12 Aug 2021) /tmp/idnits44172/draft-iesg-hardie-outline-01.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. ** Expected the document's filename to be given on the first page, but didn't find any == 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 1216 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 34 instances 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 2003) is 6786 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) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Internet-Draft Editor 3 October 2003 5 An Outline Proposal for the Means to Accomplish the IETF's Ends. 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2003). All Rights Reserved. 32 Abstract 34 This outline contains a short description of the IETF's core work 35 and a description of structures and processes which might be used 36 to accomplish it. Many of the elements described are already in 37 use either formally or informally. This document does, however, 38 propose some new mechanisms to support the work of the IETF. The 39 IESG does not believe that this document is complete, nor has it 40 decided on a course of action based on this or any other proposal. 41 The IESG does hope that presenting an outline set of mechanisms, 42 both old and new, will foster discussion. The IESG hopes community 43 will consider both whether the mechanisms described here would meet 44 the IETF's needs and, especially, whether the linkages among the 45 abstracted functions it describes are adequate and complete. 47 Table of Contents 49 The IETF community Section 1 50 The IETF's work Section 2 51 Investigation Section 2.1 52 Development Section 2.2 53 Review Section 2.3 54 Specification Section 2.4 55 Assessment Section 2.5 56 Reporting Section 2.6 57 Maintenance Section 2.7 58 Typical flows of activity Section 2.8 59 Working Group Structure and Activity Section 3 60 Specification Group. Section 3.1 61 IANA Team Section 3.2 62 Exploratory Group Section 3.3 63 Investigative Group Section 3.4 64 Working Group Activity Section 3.5 65 Area Board Structure and Activity Section 4 66 CREW Structure and Activity Section 5 67 IESG Structure and Activity Section 6 68 Directorate Structure and Activity Section 7 69 IAB Structure and Activity Section 8 70 The Nominating Committee Section 9 71 Ombudsperson Section 10 72 Business Management and Staffing Section 11 73 External Relationships Section 12 74 Document Series Section 13 75 Change Process Section 14 76 Educational Processes Section 15 77 Security Considerations Section 16 78 IANA Considerations Section 17 79 Normative References Section 18 80 References Section 19 81 Normative References Section 19.1 82 Informative References Section 19.2 83 Editor's Address Section 20 85 1. The IETF community. 87 The IETF is a community of active participants dedicated to producing 88 timely, high quality engineering work that describes protocols and 89 practices. These protocols and practices are expected to have secure 90 and scalable implementations. They are also expected to be 91 interoperable and widely deployed. The protocols and practices we 92 work on are either part of the infrastructure of the Internet or they 93 run on top of that infrastructure. 95 To foster interoperability and to further development, the IETF 96 maintains public access to its specifications and public registries 97 of its protocol parameters; it also encourages publication and 98 registration by those who have private extensions that fit within 99 the Internet framework. Where interoperability is served by making 100 this statement, the IETF designates specifications as Internet 101 standards, reflecting the IETF community's belief that the 102 specification is sufficiently advanced to allow for multiple, 103 interoperable implementations and to support widespread deployment 104 on the Internet. 106 The document below puts forward a revised set of structures as the 107 basis for change in the IETF; more importantly, though, it puts 108 forward a set of ongoing activities while will allow the community 109 to continue to adapt its behavior as new challenges arise. In 110 identifying these revisions and activities, the primary motivation 111 has been to enhance the IETF community's ability to produce 112 relevant, high-quality engineering work suitable for deployment on 113 the Internet. 115 The changes to the IETF's structure fall into five general 116 categories: functional differentiation of roles and 117 responsibilities; clarifications of how authority and 118 responsibility are distributed, especially to working group chairs; 119 a new set of named roles within the working group review process; a 120 renewed focus on cross-area review as a core value of the IETF; and 121 a change in the document series and its interlocking reference 122 structure. 124 It should be noted that the change in these structures is not meant 125 to change the purpose, scope, or activities of the IETF; in 126 protocol terms it is a change in syntax meant to clarify 127 operations, rather than a change in the semantics of those 128 operations. 130 132 The IETF has traditionally been integrated in two different ways, 133 one formal and one informal. The formal integration relates to the 134 steps of the standards process and the precursor steps of working 135 group formation and chartering. The informal integration is an 136 overlapping set of personal relationships that allows participants 137 to identify skills, perspectives, or energy needed to complete the 138 efforts identified in the formal processes. During a period of 139 rapid growth and a follow-on period of contraction, the second 140 system been strained to the point of failure. Though the IETF 141 retains a large pool of skilled professionals with energy and 142 needed perspectives, the overlap in personal networks is now not 143 sufficient to associate those with the efforts the IETF has taken 144 on. This has led to delay, lowered quality, and frustration, both 145 among those whose skills and perspectives are not appropriately 146 connected to salient efforts and among those whose efforts have 147 stalled for lack of energy or early input by those with relevant 148 expertise. These issues have been expressed in the problem 149 statement working group, but a broad range of the symptoms 150 expressed there derive from the same root cause: the IETF has 151 scaled in the past using personal trust networks as a critical part 152 of its infrastructure, and that system cannot meet the current 153 need. 155 This document proposes correcting that problem by shifting the 156 IETF's existing practice toward one in which process plays a larger 157 role. This does not mean that individuals will not be able to 158 contribute in a strongly varied set of ways; it means that IETF 159 will move toward a system in which specific roles have well defined 160 responsibilities, so that the IETF can train, recruit and fill 161 those roles more effectively. The current system, in which the 162 individual's capacities are the primary gauge for the scope of the 163 job occupied, makes for serious problems of scaling and succession. 165 167 2. The IETF's work. 169 Prior to describing the structures used to carry out the IETF's 170 activities, it may be useful to provide a short taxonomy of the 171 kinds of work the IETF takes on. The following list is not meant 172 to be exhaustive, and it probably can be visualized best as a set 173 of tasks that create a filter function--generating new ideas 174 related to IP-based technologies, refining a subset of those in 175 community dialog, and creating specifications for their 176 implementation and use. 178 2.1 Investigation. 180 This is usually limited to the investigation of known problems with 181 the existing Internet infrastructure or protocol suite, rather than 182 open-ended investigation. 184 2.2 Development. 186 This encompasses both the development of infrastructure protocols 187 and the development of protocols which the IETF believes meet a 188 need for the Internet's users or operators which has previously not 189 been met and for which an interoperable standard is critical or of 190 very significant value. 192 2.3 Review. 194 The IETF reviews protocols and practices which have been externally 195 developed, provides commentary on these, and may choose to adopt 196 them. 198 2.4 Specification. 200 The IETF creates specifications of the protocols it has developed 201 and of best practices which have been approved by community 202 consensus. 204 2.5. Assessment. 206 The IETF assesses the maturity of its specifications. 208 2.6 Reporting. 210 The IETF documents experiments and their results when those 211 experiments relate to the IETF's core concerns. 213 2.7 Maintenance. 215 The IETF maintains archives of its specifications, the parameters 216 and values assigned to protocols it has developed, and, as noted 217 above, the results of certain experiments. It also attaches its 218 assessments to specifications. 220 2.8 Typical flows of activity 222 Below are a few examples of typical activity flows; these are not 223 meant to be exhaustive, but they should serve to illustrate some of 224 the variability in process required to achieve the IETF's goals. 226 2.8.1 IETF-sponsored Protocol Development 228 Investigation--Development--Specification--Assessment--Maintenance 230 2.8.2 External Experiment 232 Review--Reporting--Maintenance 234 2.8.3 External Protocol adopted by the IETF 236 Review--Specification--Assessment--Maintenance 238 2.8.4 Assessment-derived Protocol Development 240 Assessment--Development--Specification--Assessment--Maintenance 242 2.8.5 Externally derived Protocol Parameter 244 Review--Maintenance. 246 248 This section (2.x) is meant to describe the semantics of the 249 operations before the document moves into syntax. This is a 250 100,000 foot view, and it is a big leap from there to the 251 specifications below. Nevertheless, including some abstract 252 semantics seemed useful as a starting place. 254 256 3. Working Group Structure and Activity. 258 Working Groups are the fundamental organizational structure for 259 participation in the IETF. This document describes four types of 260 Working Groups and examines how each fits into the work of the 261 IETF. These types are not immutable; the IETF can eliminate, 262 increase, or change the number of types available as needs arise. 263 These four fit well with common patterns of activity, but it should 264 be noted that those patterns of activity may not fit neatly into 265 these forms in the common case of a working group with multiple 266 projects related to a single goal. It will be common in that case 267 for one project to be, say, in a specification phase and another 268 under investigation. As noted below, different types of groups may 269 be chartered by different organizations within the IETF, and it is 270 requirement in multi-project cases for the primary chartering 271 organization to consult with those responsible for other areas when 272 approving or extending a charter. This is an extension of existing 273 practice, in which the IESG and IAB consult on working group 274 charter decisions. 276 All working groups share certain core attributes: they will have a 277 charter which describes the scope of the work and the tasks to be 278 completed; they will have one or more identified Chairs who are 279 responsible to the community for the group meeting the charter; 280 they will maintain open, public records of their mailing list 281 traffic, face-to-face meetings, and proposals. 283 285 Note that maintaining a public record of proposals is a new 286 requirement, as historically IETF Working Groups have used a naming 287 convention for Internet Drafts to indicate which proposals were 288 under active development by a Working Group. Since Internet Drafts 289 expire after six months, this record is not always available. In 290 order to maintain a consistent public record, the IETF would now 291 require that any document accepted as work item will be made part 292 of an archival series. This series is described in Section 13, 293 below. 295 An added benefit of this change is that it reduces the likelihood 296 that specifications which are incomplete will be published in the 297 existing archival series when a Working Group fails to complete a 298 work item. This currently occurs fairly frequently when there is a 299 desire to maintain a record of the work done even if it did not 300 complete successfully. 302 304 3.1) Specification Group. 306 Specification groups are chartered to develop documents which 307 describe particular protocols or domain-specific best practices for 308 use on the Internet. These charters will normally contain a 309 concise statement of the problem the Specification Group is 310 tackling, the documents expected as the output of the group, and a 311 set of dates by which each of the group's documents is expected. 312 The development of requirements, use cases, or scenarios is out of 313 scope for Specification Groups, as this work should be 314 substantially complete by the time the group is chartered. Note 315 that this does not imply that specific documents addressing each of 316 those points will be required prior to chartering a Specification 317 Group, only that the problem statement and proposed work plan must 318 be clear. 320 Specification groups are chartered by the IESG in consultation with 321 the community and management oversight is provided by the Area 322 Directors for the Area in which they fall. 324 326 The specification group is a narrower version of the existing 327 Working Group, in that they will not take on use cases, 328 requirements, or scenarios (Exploratory or Investigative Groups 329 might be used to develop those where institutional support is 330 required for that work). 332 334 3.2) IANA Team. 336 IANA Teams are Working Groups with very restricted charters, 337 composed of tasks that arise periodically in the extension or 338 maintenance of an existing standard. These teams may, for example, 339 serve as the review groups for IANA registries which require IETF 340 consensus for registration (and as working groups they may issue 341 last calls or otherwise request input from the broader community). 342 They may also serve as technical communities for review of 343 proposals which build upon an existing core technology, in cases 344 where that extension has been defined as a part of the core 345 protocol. Though it is theoretically possible for an IANA team to 346 be in place concurrently with a specification group related to the 347 same protocol or technology, this should arise only when there is 348 no overlap in scope. 350 Because the work of the IANA team is episodic in nature, it is 351 particularly important that it have a core group of committed 352 participants and that its Chair or Chair(s) be able to solicit 353 review from specific individuals; see below, Section 3.5, for 354 further discussion of this point. IANA Teams are chartered by the 355 Area Board for the Area in which they fall, in consultation with 356 the community, and management oversight is provided by the Area 357 Directors for that Area. See below, Section 4, for a description of 358 the Area Boards. 360 362 This is a new type of group, subsuming some work currently taken on 363 by the IANA review teams and extending it to work done by 364 subject-matter experts and directorates. Originally, this document 365 proposed that these be called "maintenance teams", but it became 366 clear that this constituted an attractive nuisance. Calling them 367 IANA teams eliminates that attraction and fits the core of the 368 role. In particular, it eliminates the possibility of extension by 369 an IANA team for a protocol not explicitly designed for such 370 extension. Again, the line has to be somewhere, and this got moved 371 into a fairly conservative place. 373 It should be noted that it should not be presumed that every 374 Specification Group will be succeeded by an IANAe team. These 375 should be chartered only if the technical work requires this type 376 of effort. Note also that IANA teams are chartered by the Area 377 Board. The underlying theory here is that new work (taken on by an 378 S.G, for example) requires extensive cross-area review, but that 379 the decision on whether existing work will require this type of 380 maintenance is best handled by subject matter experts. 382 384 3.3) Exploratory group 386 Exploratory groups are relatively informal groups which carry on 387 discussions about work which might require the attention of the 388 IETF. These groups are essentially self-organizing in the early 389 stages, as those interested in a particular topic or work item 390 informally identify others with similar interests. Those 391 organizing an exploratory group may at some point decide to open 392 the discussion to the IETF community as whole, typically by holding 393 a meeting at one of the IETF meetings sessions. 395 Doing so requires that the organizers provide details of how they 396 meet the basic Working Group requirements: where the archival 397 record of their discussions will be kept, an agenda describing the 398 scope of the discussion for the meeting, and a Chair or Chairs 399 responsible for running the meeting. Exploratory groups may 400 develop use cases, scenarios, or requirements documents as part of 401 their internal efforts to determine whether the work is ready for 402 standardization or a focused investigative activity. Since 403 exploratory groups do not have work plans approved by the IETF 404 community, their proposals are not expected to be archival, but 405 should be published as Internet Drafts so they are available for 406 public review. Approval of proposals for exploratory groups to 407 meet at IETF meetings may be given by the IESG, the IAB, or by any 408 four members of the Area Board of the area in which work will take 409 place. See below, Section 4, for a description of the Area Board. 410 Where there is contention over resources at an IETF meeting, the 411 Secretariat will prefer proposals by date of the confirmed proposal 412 while balancing the needs of different Areas. 414 416 The IESG has historically approved BoFs after consulting the IAB 417 and discussing the scope with the proposers. Since the right to 418 propose work is one of the most fundamental aspects of openness, 419 eliminating the restriction that the IESG be the single approver of 420 exploratory groups is an important method for distributing power 421 into the organization. It is equally important, of course, for the 422 IESG to be able to approve them as the predecessors to new work. 423 By distributing that right, this mechanism eliminates both the 424 possibility that the IESG will be a choke point and the perception 425 that it is one. This also eliminates the "max two BoFs" rule, by 426 allowing continued sponsorship. It is expected, though, that it 427 would get harder and harder to get sponsors when the work isn't 428 becoming a specification group or an investigative group. 430 432 3.4) Investigative Group 434 The IRTF (Internet Research Task Force) has research groups which 435 are focused on long term research related to the Internet. It has 436 the writ to explore topics which may or may not admit of solutions. 437 There are, however, cases where the IETF is considering a proposal 438 for work and is not yet sure that the proposal is workable within 439 the context of the Internet architecture. Investigative Groups are 440 short term task forces set up to explore proposals and determine 441 whether or not the work proposed merits further specification and 442 standardization. These groups are chartered by the IAB and 443 management oversight is provided by one or more domain experts 444 within the IAB, who will coordinate their work with the Area 445 Directors and Board(s) for the appropriate areas. These groups 446 should not produce specifications, but they may produce documents 447 describing use cases, requirements, or scenarios which motivate 448 work and help delineate its scope. 450 452 This mechanism is new and the management structure is new. It is 453 expected that these will be fairly rare, but there are cases where 454 continued investigation of a problem space is warranted but should 455 take place within the context of a strong focus on the Internet 456 Architecture. A large part of the effort in an Investigative Group 457 is likely to focus on how to get to an appropriate scope for a 458 Specification Group from an initial proposal. 460 462 3.5) Working Group Activity. 464 All Working Groups are open to participation by anyone, no matter 465 whether the group is a Specification Group, an Exploratory Group, 466 an IANA Team, or Investigative Group. Anyone may join a Working 467 Group mailing list at any time, and anyone may provide technical 468 commentary as input to a Working Group at any time. A subset of 469 those participating in the Working Group commit to taking on 470 specific roles: Working Group Chair, document editor, or technical 471 analyst. Each of the participants taking one of these special 472 roles will be identified on the working group pages and in 473 documents produced during their tenure. 475 Working Group Chairs are responsible for the Working Group meeting 476 its charter, and they have broad powers to accomplish this task. 477 They may select specific document editors, replace document editors 478 who are not meeting established milestones, and assign analysis 479 tasks to the working group's technical analysts. Most importantly, 480 they are responsible for determining whether work is sufficiently 481 advanced to be forwarded for community review as complete. This 482 means that they both gauge whether the Working Group has achieved 483 rough consensus on a document and provide a written technical 484 assessment of the work. The working group Chair or Chairs may 485 decline to forward a document for community review whenever they 486 believe it is technically incomplete, incorrect, or does not 487 reflect the Working Group's consensus. They must do so by stating 488 the basis of that decision in a written message to the group. This 489 decision is subject to appeal along the established appeal chain. 490 Because of the power inherent in this role, the same individual 491 must never serve as both Chair and document editor for the same 492 working group. The responsibilities of a Working Group Chair to 493 the Working Group and Area Board (See Section 4, below) represent a 494 significant outlay of time and energy. Chairs should expect to 495 spend about one day a week on these activities, though the actual 496 amount may vary from week to week. 498 500 This description of a Working Group's Chair role adds a substantial 501 technical role as technical reviewer, strengthens the ability of 502 the Chair to hire and fire within the group, and formalizes the 503 custom that a Working Group Chair should not be a document editor. 504 The "provide a written technical assessment of the work" is also 505 intended to take the place of the AD doing the write-up on a 506 document. 508 510 Document editors are responsible for merging the contributions of 511 the Working Group members into a coherent specification. 512 Typically, they are substantial contributors of text to the final 513 document, but they must be able to integrate the work of others in 514 order to reflect the view of the group. 516 518 This text moves away from the concept of author to the concepts of 519 editor/contributor. This may provide an opportunity to recognize 520 more folks involved in creating a spec, but it may also weaken the 521 recognition to those holding the pen. Watching this carefully will 522 be required. 524 526 There are two types of technical analysts; those associated with a 527 Working Group effort and those outside the Working Group, whose 528 views are solicited as an early indication of the likely results of 529 broader community review. For the second, see below, Section 5, for 530 a description of the CREW (Committed reviewers of early work). 532 534 This makes the working group responsible for the first stage of 535 cross-area review. 537 579 The role and function of the technical reviewers is a formalization 580 of the stuckee role, and much of the text of this section is lifted 581 from the stuckee draft. The aim here is to ensure that in-depth 582 technical review occurs by encouraging specific individuals to put 583 their names to such a review. 585 587 Typically, the work of the Working Group is done by the exchange of 588 contributions and reviews by email. Working Groups also commonly 589 hold face-to-face meetings at IETF meetings, and they may hold 590 conference calls either of the whole group or specific sub-groups. 591 All Working Group activity which does not take place on a mailing 592 list must be minuted within a reasonable period and is subject to 593 confirmation on the mailing list. 595 4. Area Board Structure and Activity 597 Each Area Board consists of at least the Area Directors and one 598 representative per group in the Area; current IAB members who have 599 served as Area Directors or Working Group Chairs in the Area may 600 choose to serve or may decline to serve at their own discretion. 601 The Chairs of each group choose who will sit on the Board for their 602 group, and they may make their choice by any method that is 603 mutually agreeable. Chairs may serve on the Area Board as the 604 representatives of the groups they chair (and this may initially be 605 common) but, in general, it is preferred that another member of the 606 group whose qualifications fit them to the review tasks of the Area 607 Board be selected. In cases where a chair does serve as Area Board 608 member, if a single individual serves as Working Group chair to 609 multiple groups, that individual may serve only on behalf of one of 610 those groups. Other members may be included for one year terms 611 after nomination by four current members and approval by majority 612 vote. 614 Each Board will have one Board Secretary, tasked with setting 615 agendas, arranging for minutes, and communicating results of the 616 Board's work. The Area Directors for the salient Area will solicit 617 candidates for this office from among the Board's members. The 618 Area Directors will forward a nominee to the Board, which may 619 confirm or decline the candidate by majority vote. Area Directors 620 may not serve as Board Secretaries of their own area, but may 621 fulfill their functions during short periods in which the role is 622 vacant. Board Secretaries will normally serve one year terms, but 623 the office may become vacant early if the incumbent's place on the 624 Board lapses and is not renewed. 626 628 This is all new. Part of the theory is to move some of those in the 629 Area into roles closer to that of an AD, as prep for their taking on 630 that role and/or as relief to the ADs. A main part of the theory, 631 though, is that the value of the IETF is in cross-area review and 632 consultation; this provides a new locus of review and consultation. 633 Concerns expressed that the Working Group chairs may not be the best 634 folks to hold these roles have been addressed by having Chairs 635 capable of nominating replacements without soliciting three other 636 nominations and by allowing their nominees to serve with majority 637 vote. 639 641 The Area Board has five main functions: it considers the need for 642 IANA teams within its area and charters them in consultation with 643 the community; it reviews Experimental and Informational documents 644 forwarded by the Area Director from the RFC Editor and makes 645 recommendations about their disposition to the RFC Editor; it 646 manages educational and mentoring programs specific to its area; 647 its members may approve the scheduling of an Exploratory Group 648 meeting ; and its members may recommend that a particular document 649 not produced within the IETF be considered as a candidate for 650 standardization. It is also consulted by the IAB during the 651 chartering of an Investigative Group and by the IESG during the 652 chartering of a Specification Group. 654 656 Note that the area board makes recommendations to the RFC Editor on 657 Informational or Experimental documents--not to the IESG. 659 661 For the review of documents, larger Boards may and should consider 662 forming small teams with expertise in specific areas, so that a 663 ready team of reviewers is available for related documents. Where 664 a document is not obviously associated with such a team, the Board 665 Secretary should ask for volunteers to review the document, setting 666 a minimum of four reviewers. If a Board has fewer than four 667 members, the whole Board should review all documents referred to 668 it. 670 Any four members of an Area Board may recommend that a document 671 produced outside the IETF Working Group process be considered for 672 standardization. The four members will commonly form or be part of 673 an expertise-specific review team within the Board, but this is not 674 required. 676 678 New stuff, but along the lines of formalizing the core groups of 679 existing areas; the hope is that by increasing recognition and 680 responsibility for these roles that support for them can be 681 increased. 683 685 Each Area Board is expected to carry out its activities largely 686 through mailing lists which are closed to external subscription but 687 maintain public archives. The Board Secretary may schedule 688 teleconferences to handle issues which require in-depth or 689 real-time discussion. Minutes from those meetings will be posted 690 to the public mailing list. These teleconferences may be supported 691 with IETF funds if the mechanisms to support them are not readily 692 available among the members. Each Area Board is also expected to 693 have a public meeting at each IETF to discuss the work of the Area 694 and solicit input on its direction from the community 696 698 This is intended to work as a cross between an Area open meeting 699 and a mini-plenary; giving opportunities for concerns to be raised 700 but also opportunities for cross-group fertilization and input. 702 704 5.) CREW structure and activity. 706 The CREW (Committed Reviewers of Early Work) is composed of 707 individuals who volunteer to provide early technical review of 708 documents for Working Groups in which they are not active 709 participants. Anyone who is serving or has served as a technical 710 analyst, document editor, or working group chair may volunteer to 711 serve as a CREW participant by providing a short description of her 712 or his technical areas of interest and agreeing to provide reviews 713 on request. A CREW participant may decline any specific request 714 for a review, but will be removed from the rolls of active 715 participants if he or she refuses three successive requests without 716 accepting a request, completes no reviews in a specific calendar 717 year, or fails on two occasions in a single year to complete 718 reviews which she or he has agreed to provide. Anyone completing 719 five reviews in a single calendar year is immune to removal for 720 that year, even if they decline further requests. The IETF 721 secretariat will provide in the appropriate formats an electronic 722 listing of reviewers along with their stated areas of interest and 723 copies of their previous reviews; it will also provide a mailing 724 list for the whole set of CREW participants, for use by those 725 working groups generally soliciting input rather than issuing a 726 targeted request. 728 The aim of this activity is to provide early access to a broader 729 community review of the work and an early gauge of the impact of 730 the Working Group's choices on other groups and areas. It is 731 expected that Working Group Chairs will solicit input from CREW 732 participants early in the development phase of documents, and they 733 may continue to solicit input over successive drafts. The input of 734 CREW participants is not automatically privileged over the input of 735 Working Group members, but Chairs may request changes to meet the 736 review comments when they believe that the expertise or perspective 737 contained in the review is not adequately represented by the 738 Working Group participants. 740 When a group is proposed, the chartering body may include 741 requirements for external review by those with specific technical 742 areas of expertise. The Chairs are responsible for determining 743 that these requirements have been met; they may meet them by 744 soliciting review by the CREW or, where available, through review 745 by a directorate or relevant maintenance team. See below, Section 746 7 for discussion of directorates and their functions. 748 Whether the CREW should have internal structure or should serve 749 only as a pool of committed reviewers is a matter under active 750 discussion. There are clear advantages to building review teams 751 which have experienced reviewers coaching new CREW members on the 752 points most likely to be useful in a cross-area review. A strictly 753 pool-based approach seems likely, in contrast, to make it easier 754 for individual members of the CREW to manage their load, by making 755 it possible to decide to accept or decline a review request on 756 a strictly individual basis. 758 As an initial step, it is proposed that the Chair of the IETF and 759 the Chair of the IAB jointly appoint a Crew Director, with the 760 intent that the Crew Director's initial function will be to help 761 staff the Crew and spread the load among the members. The Crew 762 Director will, however, monitor the success of the pool-based 763 approach and may implement internal structures to the Crew to 764 improve efficiency with the consent of the IAB Chair and the IETF 765 Chair. Further changes to the CREW may also be undertaken through 766 any of the general change process mechanisms set out below. 768 770 Very SIR-like (SIRS), obviously, but with an aim to leave 771 participation more open. The SIR mechanism seemed very unlikely to 772 garner potential implementors, while a more open mechanism seemed 773 likely to allow both for more senior reviewers and the work of 774 first timers actually working on implementations. 776 778 6) IESG Structure and Activity 780 Briefly, the Internet Engineering Steering Group (IESG) is the 781 group responsible for the IETF standards process. A BCP containing 782 a detailed description of its charter, is expected as part of the 783 ongoing definition of IETF roles. Its current charter is discussed 784 in (IESG-CHARTER), but this is not a normative description. 786 The IESG has the following members: the IETF Chair, who also 787 functions as the General Area Director when this area is active; 788 the Area Directors for the IETF Areas; and the IAB Chair, as an 789 ex-officio member. The IETF Chair and the Area Directors are 790 selected by the IETF NomCom according to the procedures of BCP 10 791 (NOMCOM). 793 795 This eliminates the Executive Director as ex-officio member, since 796 that is a position associated with a specific contractor 798 800 The IESG also has liaisons, who are members of the IESG mailing 801 list and may attend all IESG meetings. The Liaison positions exist 802 to facilitate the work of the IETF by expediting communication with 803 other entities involved in the IETF process; which positions to 804 have is decided by the IESG. The liaisons are selected as 805 appropriate by the bodies they represent. At the time of this 806 writing, the liaisons present represent the following bodies: the 807 RFC Editor; the IANA; and the IAB. In addition, members of the 808 IETF Secretariat are subscribed to the mailing list and present in 809 the IESG meetings as needed in order to serve as a support 810 function. 812 Decisions of the IESG are made by the IETF Chair and the Area 813 Directors. All IESG members can participate in the IESG's 814 discussions. 816 The IESG charters and terminates Specification Groups, selects the 817 Chairs of Specification Groups and IANA Teams, and monitors their 818 progress. While an Area's Directors and Board are the primary 819 engine of coordination within the Area, the IESG is responsible for 820 coordination across areas. It is also responsible, in consultation 821 with the IETF community, for the creation and termination of Areas. 822 As noted elsewhere, technical review of documents is done within 823 Working Groups and may be done by directorates or the CREW. The 824 IESG is, however, responsible for the final technical assessment of 825 all IETF specifications and the final decision to advance them as 826 IETF standards. It also assigns review of candidates for 827 publication outside the Standards track to specific Area Boards. 829 The IESG may divide the work of final assessment for documents 830 intended to be standards in any way which is consonant with its 831 charter and with this document. As of this writing, the IESG plans 832 to use a team-based approach. According to that plan, documents 833 forwarded as candidates for standardization are assigned to a team 834 by the IETF Chair in consultation with the responsible Area 835 Director. After assignment, the document is placed on the team 836 agenda for a specific week, and each member of the team is 837 responsible for providing an assessment of the document and reading 838 the reviews provided by the working group technical analysts, CREW, 839 and working group chairs by that date. A member of the team may, 840 however, request that the document be deferred for a single 841 meeting. 843 Team members record positions on the standardization of a document 844 in ways similar to that described in the current informational 845 charter (IESG-CHARTER), in that a member may choose to 846 raise no objection, may discuss an issue, and may approve. They 847 may not, however, abstain for any reason; if a member would need to 848 recuse herself or himself from reviewing a document, the other 849 reviewer for that area should provide the review. Note that this 850 internal plan does not change the appeals process, so that any 851 decision of the IESG appealed to the IESG is automatically 852 considered by the full IESG. 854 856 This is meant to make the IESG a manageable job again without 857 removing the final cross-area assessment. Note that the emphasis 858 on early cross-area review by the CREW is critical to making this 859 work, as is the Area Board review of non-Standards track documents. 860 This focuses on the IESG as _final_ technical assessment team, but 861 stresses the existence and importance of other review. It also 862 leaves open the idea that an AD may "provide an assessment" by 863 asking someone else to do that review if that is the best way to 864 get one done; that, unfortunately, requires a personal network that 865 is not specified here, but remains one of the ways forward. 867 It otherwise gives strong emphasis to the specification Working 868 Groups and cross-area coordination. Unlike other proposals, this 869 does not split the function of the IESG into document review and 870 technical leadership, but leaves the IESG pretty much as it is 871 currently constituted as the technical leadership team. Note also 872 the increased power given to Working Group Chairs above means that 873 the IESG will no longer have the sole authority to block; moving 874 the Chairs to use that new power when appropriate will take a 875 culture change. 877 879 The IESG has responsibility for the administration of IETF 880 logistics, including operation of the Internet-Draft and Candidate 881 Specification document series, as well as the IETF meeting event. 882 As noted elsewhere, the actual administration is delegated to the 883 Business Manager and Secretariat (see below, Section 11). 885 887 This diminishes the IESG role in the day-to-day administration 888 of the contracted services. 890 892 7) Directorate Structure and Activity 894 Directorates are groups of subject-matter experts convened by one 895 or more Area Directors to serve as a resource related to their 896 subject. They may give advice to the Area Director or to Working 897 Groups which solicit their input. Like comments from the CREW, 898 comments from a Directorate may be considered by the Working Group 899 Chair or Area Director as the basis for requirements to update a 900 document, but it is the responsibility of the Chair or Area 901 Director to impose those requirements. The names of the members of 902 a Directorate should be public, and any comments which become the 903 basis of requirements should be recorded either in the Working 904 Group archives or by the Area Director in the notes associated with 905 a document. 907 8) IAB Structure and Activity 909 The Charter of the IAB is set out in RFC 2850 (IAB-CHARTER). This 910 document updates that document by naming the IAB as the body which 911 charters investigative groups, as a group which may schedule 912 Exploratory Group meetings, and by designating its members as 913 potential participants in Area Boards. It also specifies that the 914 the IAB, with the IESG, votes to confirm a candidate as 915 Ombudsperson (See Section 10, below for a description of the 916 Ombudsperson's role). 918 9) The Nominating Committee. 920 The NomCom selects the members of the IESG and IAB according to the 921 system set out in (NOMCOM). This document does not update those 922 mechanisms, but it does introduce new responsibilities for the 923 individuals serving on the IESG and IAB and so should be considered 924 by the NomCom in its deliberations. This document also introduces 925 a new role for NomCom in carrying out the public solicitation of 926 potential candidates for Ombudsperson. This system is different 927 from the closed review of potential candidates for IAB and IESG, 928 both in that the nominations must be public and in that the 929 confirmation is carried out jointly by the IETF and IAB. See 930 below, section 10, for more details. 932 10) Ombudsperson. 934 The Ombudsperson acts to help ensure that IETF mechanisms are not 935 abused by providing independent oversight of IETF processes. Any 936 IETF participant may request that the Ombudsperson review the 937 public record of a Working Group, Area Board, IETF, or IESG 938 decision to determine whether the IETF processes functioned 939 correctly. The Ombudsperson has no power to conduct 940 investigations, but she or he may, at her or his discretion, 941 request time on the agenda of any body outside the NomCom in order 942 to put forward the concerns raised. If this is not sufficient to 943 resolve issues, the Ombudsperson will help the participant to 944 understand the appeals process. It remains the responsibility of 945 the concerned individual to file the appeal. 947 Public nominations for candidates to serve for a year in the role 948 of Ombudsperson are solicited by the NomCom Chair two months prior 949 to the Fall IETF meeting. The NomCom discusses the candidacies on 950 its closed list, and makes a nomination two weeks prior to the Fall 951 IETF meeting. A candidate must be confirmed by majority vote of 952 the IESG and IAB during their joint meeting. If the candidate 953 proposed by the NomCom is not confirmed, the NomCom must propose a 954 new candidate. The sitting Ombudsperson remains in office until a 955 candidate has been confirmed or, if that individual cannot serve, 956 the NomCom Chair serves in this role until confirmation is 957 complete. If an Ombudsperson leaves during the course of the one 958 year term, the NomCom will nominate a replacement to serve the 959 remainder of the term plus one year. 961 963 This is a role clearly desired by the community, but the scope of 964 the role has not been clear. In putting together text, the most 965 important aspect of the role seemed to the right to "be heard" and 966 that the right to have access to any agenda was therefor key. 967 Investigative powers, on the other hand, seemed likely to be 968 problematic so this document sticks to the public record as the 969 source of information. 971 973 11) Business management and staffing. 975 The IETF is largely a volunteer organization, but it does maintain 976 contracts with a number of external organizations who provide 977 support or other services. Work on updating the mechanisms by which 978 those relationships are managed is ongoing. This document assumes 979 that whatever mechanisms emerge, the business management role inside 980 the IETF will have no necessary connection to the IETF standards 981 process and so the day to day work of managing the contracts by 982 which support services are provided will not necessarily fall to 983 those with any specific role in the standards process. 985 987 This section originally outlined a new role, essentially a a 988 professional able to take on the "task requester" position of 989 managing contracts. Since there is work going on to update those 990 mechanisms, this section shifted to document the core assumption 991 that the new mechanism would not presume that the same people 992 managing the standards process managed the business relationships. 993 That seems both likely to help us in reducing the load on those 994 managing the standards process and likely to reduce the set of 995 skills required for those roles. Hopefully, both of those changes 996 will increase the pool of those able to serve. 998 1000 12) External relationships. 1002 The responsibility for handling external relations rests with the 1003 IAB, as described in the IAB Charter (IAB-CHARTER). However, when 1004 technical cooperation is required, it is essential that the work be 1005 coordinated with the relevant Areas. This often means that an Area 1006 Director or Board participant will function in a liaison role with 1007 other organizations. The IAB may decide, however, to appoint 1008 others to those tasks whenever it believes that this is more 1009 appropriate. 1011 13) Document Series. 1013 The requirement that Working Group documents be archival implies 1014 the creation of a new document series outside the current Internet 1015 Draft series. This series, called Candidate Specifications, is 1016 intended to be relatively lightweight in publication. The Chair of 1017 the salient Working Group must approve publication of the initial 1018 version of any Candidate Specification, but it may be updated by 1019 the Document Editor as required. Candidate Specifications may have 1020 normative references to any document, including Internet Drafts. 1022 1024 As noted above, C.S. is a new series, meant to be 1025 the archival equivalent of draft-ietf-wgname. 1027 1029 When a Specification Group believes that a Candidate Specification 1030 is ready to be considered for status as an IETF standard, its Chair 1031 completes the technical analysis described in Section 3.5 above and 1032 requests community review in an IETF Last Call. Following the 1033 completion of that Last Call, the IESG conducts a final review and 1034 either advances the document to Initial Standard or provides public 1035 feedback to the Working Group on issues raised during the IESG's 1036 review. An Initial Standard must have normative references only to 1037 archival documents, but this may include specific versions of 1038 Candidate Specifications. 1040 After an Initial Standard has been implemented and in use for six 1041 months, it may progress to Full Standard by demonstrating that 1042 there exist two interoperable implementations of every required 1043 feature of the specification. A Full Standard must have normative 1044 references only to archival documents, and it is preferred that 1045 these be at least at the level of Initial Standard or its 1046 equivalent. This requirement may be waived by the IESG if the 1047 archival document referenced is considered stable in the aspect 1048 referenced by the Full Standard. 1050 1052 By keeping this as a 3 stage process but with a lower initial 1053 requirements and a dropped requirement for lock step movement of 1054 normative references, we may be able to keep useful elements of the 1055 existing three stage system while improving the ability to move 1056 forward in a reasonable amount of time. Getting to Full and 1057 proving interoperability should be valuable, and reducing external 1058 dependencies may help us do that more often. 1060 1062 14) Change process 1064 As before, the IETF may choose to update its processes by forming a 1065 working group that will consider the needs or advantages of 1066 specific changes. A simplified mechanism is, however, presented 1067 here as a method for the adoption of new processes. Any member of 1068 an Area Board may propose that the Area Board consider a new 1069 process for adoption by the IETF as a whole. Such a proposal must 1070 be documented as an Internet Draft, and should indicate clearly the 1071 working of the proposal and the current documents which it updates 1072 or obsoletes. If a two-thirds majority of that Area Board concurs 1073 that the IETF should consider the new or updated process, the Board 1074 Secretary for that Board notes the action to the IESG. 1076 The Area Directors for the Areas that have not considered the 1077 process must then request that the process be considered by the 1078 other Area Boards. Other Area Boards then consider the document 1079 and vote on whether it should be approved; a two thirds majority is 1080 required in each case to approve. If all Area Boards approve the 1081 document, the process it documents becomes part of the IETF 1082 process. If a majority approve the document, but not all approve 1083 it, the Area Director for the General Area should strongly consider 1084 the formation of a Specification Team to propose new processes in 1085 the area; the Area Director for the General Area may also, however, 1086 recommend to the IAB that an Investigative Team be formed to 1087 consider the question. 1089 1091 All new, and designed to create a change process that has a low bar 1092 for proposal, a reasonable bar for full-fledged consideration, and 1093 a fairly high bar for change. Note, however, that every single 1094 Area Director could be against the proposal and it could still 1095 pass. Note also that a single Area objecting to a proposal can 1096 stall it in this process, but cannot stall it in the working group 1097 process, so there are two separate ways forward. 1099 1101 15) Educational processes 1103 As noted above, each Area Board has responsibility for educational 1104 processes supporting its Area. There is, however, also a need for 1105 a set of educational process which are more general (generally, 1106 orientation meetings for newcomers to the IETF or newcomers to 1107 specific roles in the IETF). Therefore, the General area will 1108 maintain a set of ongoing working groups, essentially maintenance 1109 teams, charged with managing, developing, and delivering those 1110 cross-area educational programs which are needed and appropriate. 1111 The exact set of those teams may vary at any one time but shall 1112 consist at least of one dedicated to the general orientation of 1113 newcomers to the IETF and one dedicated to the orientation of those 1114 taking on new roles as Chairs, members of Area Boards, technical 1115 reviewers, and members of the CREW. 1117 16. Security Considerations. 1119 Any change to organizational structure creates risk that attackers 1120 will be able to game the new system in ways they could not game the old. 1122 17. IANA Considerations. 1124 This document does contain any actions for IANA. 1126 18. Acknowledgments. 1128 This document lifts ideas, text, and explanations from a variety 1129 of sources, not always with their prior knowledge or consent. The 1130 work of Dave Crocker, Brian Carpenter, and the participants in the 1131 SiRS experiment informs the section on the CREW. The work of the 1132 problem statement working group and the solutions mailing list have 1133 both been instrumental in identifying scope and potential improvements. 1134 The Genera Area Directorate has given early comments on the work; 1135 Spencer Dawkins, in particular, provided extensive feedback. Leslie 1136 Daigle, John Klensin, April Marine, James Kempf, Melinda Shore, and 1137 Rob Austein also provided comments on early drafts. 1139 19. References 1141 19.1 Normative References 1143 Galvin, J. "IAB and IESG Selection, Confirmation, and Recall 1144 Process: Operation of the Nominating and Recall Committees". 1145 BCP 10. (NOMCOM) 1147 Carpenter, B. ed. "Charter of the Internet Architecture Board". 1148 BCP 39. (IAB-CHARTER). 1150 19.2 Non-Normative References 1152 Alvestrand, H. "An IESG Charter" draft-iesg-charter-03.txt 1153 (IESG-CHARTER) 1155 Carpenter, B. et al. "Careful Additional Review of Documents (CARD) 1156 by Senior IETF Reviewers (SIRS)" 1157 draft-carpenter-solution-sirs-01.txt (SIRS) 1159 20. Editor's Address 1161 Ted Hardie 1162 Qualcomm, Inc. 1163 675 Campbell Technology Parkway 1164 Suite 200 1165 Campbell, CA 1166 U.S.A. 1168 EMail: hardie@qualcomm.com 1170 Full Copyright Statement 1172 Copyright (C) The Internet Society (2003). All Rights Reserved. 1174 This document and translations of it may be copied and furnished to 1175 others, and derivative works that comment on or otherwise explain it 1176 or assist in its implementation may be prepared, copied, published 1177 and distributed, in whole or in part, without restriction of any 1178 kind, provided that the above copyright notice and this paragraph are 1179 included on all such copies and derivative works. However, this 1180 document itself may not be modified in any way, such as by removing 1181 the copyright notice or references to the Internet Society or other 1182 Internet organizations, except as needed for the purpose of 1183 developing Internet standards in which case the procedures for 1184 copyrights defined in the Internet Standards process must be 1185 followed, or as required to translate it into languages other than 1186 English. 1188 The limited permissions granted above are perpetual and will not be 1189 revoked by the Internet Society or its successors or assigns. 1191 This document and the information contained herein is provided on an 1192 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1193 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1194 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1195 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1196 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1198 Acknowledgment 1200 Funding for the RFC Editor function is currently provided by the 1201 Internet Society.