idnits 2.17.1 draft-ietf-iesg-wgguidelines-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. INTRODUCTION' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. SECURITY CONSIDERATIONS' ) ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 113 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [1,5,6,7], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 4 has weird spacing: '...SURFnet bv...' == Line 224 has weird spacing: '...of this docum...' == Line 245 has weird spacing: '...sent of the a...' == Line 292 has weird spacing: '...ed. The docum...' == Line 580 has weird spacing: '...ed over time,...' == 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 (June 1993) is 11266 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) -- Missing reference section? '1' on line 965 looks like a reference -- Missing reference section? '3' on line 1075 looks like a reference -- Missing reference section? '8' on line 229 looks like a reference -- Missing reference section? '9' on line 230 looks like a reference -- Missing reference section? '4' on line 976 looks like a reference -- Missing reference section? '5' on line 965 looks like a reference -- Missing reference section? '6' on line 965 looks like a reference -- Missing reference section? '7' on line 965 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group IESG 3 INTERNET-DRAFT Erik Huizer 4 SURFnet bv 5 D. Crocker 6 Silicon Graphics, Inc. 7 June 1993 9 IETF Working Group 10 Guidelines and Procedures 12 STATUS OF THIS MEMO 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its 16 Areas, and its Working Groups. Note that other groups may also 17 distribute working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use 22 Internet Drafts as reference material or to cite them other than 23 as a ``working draft'' or ``work in progress.'' 25 Please check the 1id-abstracts.txt listing contained in the 26 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 27 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 28 current status of any Internet Draft. 30 When finalized the draft document will be submitted to the RFC 31 editor as an informational document. Distribution of this memo is 32 unlimited. Please send comments to the author. 34 ABSTRACT 36 The Internet Engineering Task Force (IETF) has the primary 37 responsibility for developing and review of specifications 38 intended as Internet Standards. IETF activities are organized 39 into Working Groups (WG). This document describes the guidelines 40 and procedures for formation and operation of an IETF Working 41 Groups. It describes the formal relationship between a WG and the 42 Internet Engineering and Steering Group (IESG). The basic duties 43 of a WG chair and an IESG Area Director are defined. 45 IESG 1 46 The expiration date of this Internet Draft is December 1993. 48 TABLE OF CONTENTS 50 1. INTRODUCTION 51 1.1. IETF Approach to Standardization 52 1.2. Acknowledgments 54 2. GROUP PROCESS 55 2.1. Working Group Purpose & Scope 56 2.2. Wg Policies And Procedures 57 2.3. Birds Of A Feather (Bof) 58 2.4. WG Formation 59 Criteria for Formation 60 Charter 61 Charter Review & Approval 62 2.5. Working Group Sessions 63 2.6. Termination Of A WG 65 3. MANAGEMENT 66 3.1. WG Chair Duties 67 3.2. Area Director Duties 68 3.3. Contention And Appeals Overview 70 4. DOCUMENT PROCEDURES 71 4.1. Internet Drafts 72 4.2. Request For Comments (RFC) 73 4.3. Submission Of Documents 74 4.4. Review Of Documents 76 5. SECURITY CONSIDERATIONS 78 6. REFERENCES 80 7. AUTHORS ADDRESS 82 APPENDIX: Sample Working Group charter 84 1. INTRODUCTION 86 This document defines guidelines and procedures for Internet 87 Engineering Task Force Working Groups. The Internet, a loosely- 88 organized international collaboration of autonomous, 89 interconnected networks, supports host-to-host communication 90 through voluntary adherence to open protocols and procedures 92 IESG 2 93 defined by Internet Standards, a collection of which are commonly 94 known as "the TCP/IP protocol suite". The Internet Standards 95 Process is defined in RFC 1310bis [1]. The primary 96 responsibility for the development and review of potential 97 Internet Standards from all sources is conducted by the Internet 98 Engineering Task Force (IETF). The goals, structures and 99 procedures of the IETF can be found in it's charter [3]. 101 The IETF is a large, open community of network designers, 102 operators, vendors, and researchers concerned with the Internet 103 and the technology used on it. The IETF is managed by its 104 Internet Engineering Steering Group (IESG) whose membership 105 includes an IETF Chair, responsible for oversight of general IETF 106 operations, and Area Directors, each of whom is responsible for a 107 set of IETF activities and working groups. At present there are 108 10 areas, though the number and purview of Areas changes over 109 time: 111 <> 113 1) User Services 114 2) Applications 115 3) Service Applications 116 4) Transport Services 117 5) Internet Services 118 6) Routing 119 7) Network Management 120 8) Operational Requirements 121 9) Security 122 10) Standards & Processes 124 Most Areas have an advisory group, called the Area Directorate, 125 to assist the Area Directors, e.g., with the review of 126 specifications produced in the area. The Area Directorate is 127 formed by the Area Director(s) from senior members of the 128 community represented by the Area. A small IETF Secretariat 129 provides staff and administrative support for the operation of 130 the IETF. 132 The primary work of the IETF is performed by subcommittees known 133 as Working Groups. There are currently more than 60 of these. 134 Working Groups tend to have a narrow focus and a lifetime bounded 135 by completion of a specific task, although there are exceptions. 137 Membership in the IETF is established simply by the fact of 138 participation in its activities. This participation may be by on- 139 line contribution, attendance at face-to-face sessions, or both. 140 No formal rules govern this membership. Any member of the 141 Internet community with the time and interest is urged to 143 IESG 3 144 participate in IETF meetings and any of its on-line working group 145 discussions. Participation is by individual technical 146 contributors, rather than by formal representatives of 147 organizations. 149 This document defines procedures and guidelines for formation and 150 operation of Working Groups in the IETF. It defines the relations 151 of Working Groups to other bodies within the IETF. The duties of 152 Working Group Chairs and Area Directors with respect to the 153 operation of the Working Group are also defined. The document 154 uses words like: "shall", "will", "must" and "is required" where 155 it describes steps in the process that are essential. Words like 156 "suggested", "should" and "may" are used where guidelines are 157 described that are not essential, but are strongly recommended to 158 help smooth WG operation. 160 1.1. IETF Approach to Standardization 162 The reader is encouraged to read The IETF Charter [3] and The 163 Internet Standards Process [1]. Familiarity with these documents 164 is essential for a complete understanding of the philosophy, 165 procedures and guidelines described in this document. The goals 166 of the process are summarized in [1]: 168 In general, an Internet Standard is a specification that is 169 stable and well-understood, is technically competent, has 170 multiple, independent, and interoperable implementations 171 with operational experience, enjoys significant public 172 support, and is recognizably useful in some or all parts of 173 the Internet. 175 ... 177 In outline, the process of creating an Internet Standard is 178 straightforward: a specification undergoes a period of 179 development and several iterations of review by the Internet 180 community and perhaps revision based upon experience, is 181 adopted as a Standard by the appropriate body (see below), 182 and is published. 184 In practice, the process is somewhat more complicated, due 185 to (1) the number and type of possible sources for 186 specifications; (2) the need to prepare and revise a 187 specification in a manner that preserves the interests of 188 all of the affected parties; (3) the importance of 189 establishing widespread community agreement on its technical 191 IESG 4 192 content; and (4) the difficulty of evaluating the utility of 193 a particular specification for the Internet community. 195 ... 197 These procedures are explicitly aimed at developing and 198 adopting generally-accepted practices. Thus, a candidate 199 for Internet standardization is implemented and tested for 200 correct operation and interoperability by multiple, 201 independent parties, and utilized in increasingly demanding 202 environments, before it can be adopted as an Internet 203 Standard. 205 The IETF standardization process has been marked by informality. 206 As the community of participation has grown it has become 207 necessary to document procedures, while continuing to avoid 208 unnecessary bureaucracy. This goals of this balancing act are 209 summarized in [1] as: 211 The procedures that are described here provide a great deal 212 of flexibility to adapt to the wide variety of circumstances 213 that occur in the Internet standardization process. 214 Experience has shown this flexibility to be vital in 215 achieving the following goals for Internet standardization: 217 * high quality, 218 * prior implementation and testing, 219 * openness and fairness, and 220 * timeliness. 222 1.2. Acknowledgments 224 Much of this document is due to the copy-and-paste function of a 225 word processor. Several passages have been taken from the 226 documents cited in the reference section. The POISED WG provided 227 discussion and comments. Three people deserve special mention, as 228 especially large chunks of their documents have been integrated 229 into this one: Vint Cerf [8] from whom we borrowed the 230 description of the IETF. And Greg Vaudreuil and Steve Coya [9] 231 who provided several paragraphs. All the errors you'll find are 232 probably ours. 234 IESG 5 235 2. GROUP PROCESS 237 2.1. Working Group Purpose & Scope 239 IETF working groups (WGs) are the primary mechanism for 240 development of IETF specifications and guidelines, many of which 241 are intended as standards or recommendations. A working Group may 242 be established at the instigation of an Area Director (AD), or 243 its creation may be initiated by an individual or group of 244 individuals. Anyone interested in creating an IETF working group 245 must obtain the advise and consent of the appropriate IETF Area 246 Director under whose direction the working group would fall. 248 A working group is typically created to address a specific 249 problem or produce a specific deliverable (guideline, standard, 250 etc.), and is expected to be short-lived in nature. Upon 251 completion of its goals and achievement of its objectives, the 252 working group as a unit is terminated. Alternatively, at the 253 discretion of the Area Director and the working group chair and 254 membership, the objectives or assignment of the working group may 255 be extended by enhancing or modifying the working group's 256 statement of objectives 258 2.2. Wg Policies And Procedures 260 The IETF has basic requirements for open and fair participation 261 and for thorough consideration of technical alternatives. Within 262 those constraints, working groups are autonomous and each 263 determines the details of its own operation with respect to 264 session participation, reaching closure, etc. The core rule for 265 operation is that acceptance or agreement is achieved via working 266 group "rough" consensus. 268 A number of procedural questions and issues will arise over time, 269 and it is the function of the working group chair to manage the 270 group process, keeping in mind that the overall purpose of the 271 group is to make progress towards reaching "rough" consensus in 272 realizing the working group's goals and objectives. 274 There are no hard and fast rules on organizing or conducting 275 working group activities, but a set of guidelines and practices 276 have evolved over time that have proven successful. Some of these 278 IESG 6 279 are listed here, with actual choices typically determined by the 280 working group members and the chair. 282 1. For face-to-face sessions, the chair should publish a 283 draft WG-agenda well in advance of the actual session. 284 The agenda needs to contain at least: 286 - The items for discussion; 288 - The estimated time necessary per item; and 290 - A clear indication of what documents the participants 291 will need to read before the session in order to be 292 well prepared. The documents should be publicly 293 available (preferably as Internet drafts; see next 294 section) with information needed to access them. 296 2. All relevant documents for a session (including the 297 final agenda) should be published and available at least 298 two weeks before the session starts. 300 3. It is strongly suggested that the WG chair makes sure 301 that an anonymous FTP directory be available for the 302 upcoming session. All relevant documents (including the 303 final WG-agenda and the minutes of the last session) 304 should be placed in this directory. This has the 305 advantage that all participants can ftp all files in 306 this directory and thus make sure they have all relevant 307 documents. Also, it will be helpful to provide 308 electronic mail- based retrieval for those documents. 310 4. While open discussion and contribution is essential to 311 working group success, the chair is responsible for 312 ensuring forward progress. As appropriate it may be 313 acceptable to have restricted participation (not 314 attendance!) at IETF working group sessions for the 315 purpose of achieving progress. The working group chair 316 usually has the authority to refuse to grant the floor 317 to any individual who is unprepared or otherwise 318 covering inappropriate material. 320 5. The detailed specification effort within a working group 321 may be assigned to self-selecting sub-groups, called 322 Design Teams. They may hold closed sessions for 323 conducting the specification effort. In some cases 324 Design Teams are necessary to make forward progress when 325 preparing a document. All work conducted by a Design 326 Team must be available for review by all working group 328 IESG 7 329 members and the DT must be responsive to the direction 330 of the working group's "rough" consensus. 332 6. Many working group participants hold that mailing list 333 discussion is the best place to consider and resolve 334 issues and make decisions, while others maintain that 335 such work should be accomplished primarily at IETF 336 meetings. Choice of operational style is made by the 337 working group itself. It is important to note, however, 338 that Internet email discussion is possible for a much 339 wide base of interested persons than is attendance at 340 IETF meetings, due to the time and expense required to 341 attend. 343 7. It can be quite useful to conduct email exchanges in the 344 same manner as a face to face session, with published 345 schedule and agenda, as well as on-going summarization 346 and consensus polling. 348 8. Consensus can be determined by balloting, humming, or 349 any other means the WG agrees on (by rough consensus, of 350 course). IETF consensus does not require that all 351 members agree, although this is of course preferred. In 352 general the "dominant" view of the working group shall 353 prevail. (However it must be noted that "dominance" is 354 not to be determined on the basis of volume or 355 persistence, but rather a more general sense of 356 agreement.) 358 9. It is occasionally appropriate to re-visit a topic, to 359 re-evaluate alternatives or to improve the group's 360 understanding of a relevant decision. However, 361 unnecessary repeated discussions on issues can be 362 avoided if the chair makes sure that the main arguments 363 in the discussion (and the outcome) are summarized and 364 archived, after a discussion has come to conclusion. It 365 is also good practice to note important 366 decisions/consensus reached by E-mail in the minutes of 367 the next 'live' session, and to briefly summarise 368 decision making history in the final documents the WG 369 produces. 371 10. To facilitate making forward progress, a working 372 group chair may wish to direct a discussion to reject 373 the input from a member, based upon the following 374 criteria: 376 (old) The input pertains to a topic that already 378 IESG 8 379 has been resolved and is redundant with 380 information previously available; 382 (minor) The input is new and pertains to a topic that 383 has already been resolved, but it is felt to 384 be of minor import to the existing decision; 385 or 387 (not yet) The input pertains to a topic that the 388 working group has not yet opened for 389 discussion. 391 2.3. Birds Of A Feather (Bof) 393 For an individual, or small group of individuals, it is often not 394 clear if the issue(s) at hand merit the formation of a WG. To 395 alleviate this problem the IETF offers the possibility of a Birds 396 of a Feather (BOF) session, as well as the early formation of an 397 email list for preliminary discussion. 399 A BOF is a session at an IETF meeting which permits "market 400 research" and technical "brainstorming". Any individual may 401 request permission to hold a BOF on a subject. The request has to 402 be filed with the relevant Area Director. The person who requests 403 the BOF is usually appointed as chair of the BOF. The chair of 404 the BOF is also responsible for providing a report on the outcome 405 of the BOF. 407 Usually the outcome of a BOF will be one of the following: 409 - There was enough interest and focus in the subject to 410 warrant the formation of a WG; 412 - The discussion came to a fruitful conclusion, with 413 results to be written down and published; however there 414 is no need to establish a WG; 416 - There was not enough interest in the subject to warrant 417 the formation of a WG. 419 There is an increasing demand for BOF sessions at IETF meetings. 420 Therefore the following rules apply for BOFs: 422 1. All BOFs wishing to meet during an IETF meeting must 423 have the approval of the appropriate Area Director. The 424 Secretariat will NOT schedule or allocate time slots 425 without the explicit approval of the Area Director. 427 IESG 9 428 2. The purpose of a BOF is to conduct a single, brief 429 discussion or to ascertain interest and establish goals 430 for a working group. All BOF organizers are required to 431 submit a brief written report of what transpired during 432 the BOF session together with a roster of attendees to 433 the IETF Secretariat for inclusion in the proceedings. 435 3. A BOF may be held only once (ONE slot at one IETF 436 Plenary meeting). 438 4. Under unusual circumstances an Area Director can, at 439 his/her discretion, allow a BOF to meet for a second 440 time. Typically (though not a requirement) this is to 441 develop a charter to be submitted to the IESG. 443 5. BOFs are not permitted to meet three times. 445 6. Non-IETF groups wishing to participate in IETF meetings 446 may hold a BOF for single-event discussion, or may 447 pursue creation of normal IETF working groups for on- 448 going interactions and discussions. The rules governing 449 such BOFs are the same as for all other IETF BOFs and 450 working groups. 452 7. When necessary, IETF WGs will be given priority for 453 meeting space over IETF BOFs. 455 2.4. WG Formation 457 Criteria for Formation 459 When determining if creating a working group is appropriate, the 460 Area Director will consider several issues: 462 - Are the issues that the working group plans to address 463 clear and relevant for the Internet community? 465 - Are the goals specific and reasonably achievable, and 466 achievable within the time frame specified by the 467 milestones? 469 - Do the working group's activities overlap with those of 470 another working group? If so, it may still be 471 appropriate to create another working group, but this 472 question must be considered carefully by the Area 474 IESG 10 475 Directors as subdividing efforts often dilutes the 476 available technical expertise. 478 - Are there several people clearly interested in the 479 working group's topic and willing to expend the effort 480 to produce the desired result (e.g., a protocol 481 specification)? Working groups require considerable 482 effort: a chair is needed to run sessions, an editor to 483 maintain the working document(s), and contributors to 484 write the text. IETF experience suggests that these 485 roles typically cannot all be handled by one person; 486 four or five active members are typically required. If 487 the necessary staffing is lacking, the person interested 488 in creating the working group might consider actually 489 writing the specification alone and submitting it for 490 review, rather than attempting to create a working 491 group. 493 - Does a base of interested consumers appear to exist for 494 the planned work? Consumer interest can be measured by 495 participation of end-users within the IETF process, as 496 well as less direct indications. 498 Considering the above criteria, the Area Director will decide 499 whether to pursue the formation of the group through the 500 chartering process. 502 Charter 504 The formation of a working group requires a charter which is 505 negotiated between a prospective working group chair and the 506 relevant Area Director and which: 508 1) Lists relevant administrative aspects of the working 509 group, such as identifying the WG Chair or co-Chairs, 510 the WG secretary (who may also be the WG chair), and the 511 addresses of the mailing list and any archive. 513 2) Specifies the direction or objectives of the working 514 group and describes the approach that will be taken to 515 achieve the goals; and 517 3) Enumerates a set of goals and milestones together with 518 time frames for their completion. 520 3) Lists the milestones and dates for intermediate goals, 521 and 523 IESG 11 524 When both the prospective chair and the Area Director are 525 satisfied with the charter text, it becomes the basis for forming 526 a working group. The charter document may be similarly 527 renegotiated or modified at any time during the course of the 528 working group's effort to reflect the changing goals of the 529 group. 531 Charters are reviewed and approved by the IESG. They may be re 532 negotiated periodically to reflect the current status, 533 organization or goals of the working group. Hence, a working 534 group charter is a contract between the IETF and the working 535 group which is committing to meeting explicit milestones and 536 delivering concrete "products". 538 Specifically, each charter consists of five sections: 540 1. Working Group Name: 542 A working group name should be reasonably descriptive or 543 identifiable. Additionally, the group shall define an 544 acronym (maximum 8 printable ASCII characters) to reference 545 the group in the IETF directories, mailing lists, and 546 general documents. 548 2. Working Group Chair(s): 550 The working group may have one or two chair(s) to perform 551 the administrative functions of the group. The chair(s) 552 shall be reachable by Email. 554 3. Area and Area Director(s) 556 The name of the IETF area with which the working group is 557 affiliated and the name and electronic mail address of the 558 associated Area Director. 560 4. Working Group Description: 562 In one to two paragraphs, the focus and intent of the group 563 shall be set forth. By reading this section alone, an 564 individual should be able to decide whether this group is 565 relevant to their own work. The first paragraph must give a 566 brief summary of the basis, goal(s) and approach(es) planned 567 for the working group. This paragraph will frequently be 568 used as an overview of the working group's effort. 570 Recognizing the importance of security and network 571 management in the Internet Architecture, this description of 573 IESG 12 574 the work of the group must specifically address the impact 575 of the work on these two issues. 577 5. Goals and Milestones: 579 The working group charter must establish a timetable for 580 work. While this may be re-negotiated over time, the list 581 of milestones and dates facilitates the Area Director's 582 tracking of working group progress and status, and it is 583 indispensable to potential participants identifying the 584 critical moments for input. Milestones shall consist of 585 deliverables that can be qualified as such; e.g. 'Internet- 586 draft finished' is fine, but 'discuss via E-mail' is not. 587 This milestone list is expected to be updated periodically. 588 Updated milestones are re-negotiated with the Area Director 589 and the IESG, as needed and then are submitted to the IETF 590 Secretariat 592 ietfadm@cnri.reston.va.us 594 6. Mailing Lists: 596 Most of the work of an IETF working group is conducted on 597 Internet mailing lists. It is required that an IETF working 598 group have a general discussion list. An individual needs to 599 be designated as the list service postmaster, usually 600 through a list-request alias mechanism. A message archive 601 should be maintained in a public place which can be accessed 602 via FTP. The address 604 IETF-archive@cnri.reston.va.us 606 shall be included on the mailing list. Retrieval from the 607 archive via electronic mail requests also is recommended. 609 NOTE: It is strongly suggested that the mailing list be on a 610 host directly connected to the IP Internet to facilitate use of 611 the SMTP expansion command (EXPN) and to allow access via FTP to 612 the mail archives. If this is not possible, the message archive 613 and membership of the list must be made available to those who 614 request it by sending a message to the list-request alias. The 615 list maintainer or archiver need not be the working group chair 616 or secretary, but may be a member of the working group itself. 618 An example of a WG charter is in appendix A. 620 IESG 13 621 Charter Review & Approval 623 Once the Area Director has approved the Working Group charter, 624 the charter is submitted to the Internet Engineering and Steering 625 Group and Internet Architecture Board for review and approval. 626 The IESG will primarily consider whether : 628 - There is sufficient expertise in the IETF to produce the 629 desired results of the WG; 631 - There is a good indication that the intended user 632 population wants this work; 634 - The risks and urgency of the work are specified, to 635 determine the level of attention required, and 637 - The extent to which the work will affect an installed 638 base of users is taken into account. 640 - The WG has overlap with WGs in other areas; 642 - Related work by other groups will be affected or will be 643 sufficiently coordinated with the work of this group 645 The Internet Architecture Board (IAB) will review the charter of 646 the proposed WG to determine the relationship of the proposed 647 work to the overall architecture of the Internet Protocol Suite. 649 The approved charter is submitted to the IESG Secretary who 650 records and enters the information into the IETF tracking 651 database and returns the charter in a form formatted by the 652 database. The working group is announced by the IESG Secretary 653 to the IETF mailing list, by the IESG secretary. 655 2.5. Working Group Sessions 657 All working group actions shall be public, and wide participation 658 encouraged. A working group will conduct much of its business 659 via electronic mail distribution lists, but may meet periodically 660 to discuss and review task status and progress, and to direct 661 future activities. It is common, but not required that a working 662 group will meet at the trimester IETF plenary meetings. 663 Additionally, interim sessions may be scheduled for telephone 664 conference, video teleconference, or by actual face to face 665 sessions. 667 As noted in the earlier section on Working Group Policies and 669 IESG 14 670 Procedures, each working group will determine the balance of 671 email and face-to-face sessions that is appropriate for achieving 672 its milestones. Electronic mail permits the widest 673 participation; face-to-face meetings often permit better focus 674 and therefore can be more efficient for reaching consensus and 675 ensuring consensus among a core of the working group members. 677 Sessions must be publicized widely and well in advance and must 678 take place at a convenient location. The time and location of a 679 session must be announced on the working group mailing list, 680 through any other mechanisms that are appropriate, and must 681 include the IETF mailing list: 683 ietf@cnri.reston.va.us 685 All working group sessions (including those held outside of the 686 IETF meetings) shall be reported by making minutes available. 687 These minutes should include the agenda for the session, an 688 account of the discussion including any decisions made, and a 689 list of attendees. The working group chair is responsible for 690 insuring that session minutes are written and distributed, though 691 the actual task may be performed by the working group secretary 692 or someone designated by the working group chair. The minutes 693 shall be submitted in printable ASCII text for publication in the 694 IETF Proceedings, and for posting in the IETF Directories. 696 If a WG needs a session at an IETF meeting, the chair must apply 697 for one or more time-slots as soon as the first announcement of 698 that IETF meeting is made by the IETF secretariat to the 699 wg-chairs list. Session time is a scarce resource at IETF 700 meetings, so placing requests early will facilitate schedule 701 coordination for WGs requiring the same set of experts. 703 The application for a WG session at an IETF meeting shall be made 704 to the IETF secretariat. Alternatively some Area Directors may 705 want to coordinate WG sessions in their area and request that 706 time slots be coordinated through them. After receiving all 707 requests for time slots by WGs in the area, the Area Director(s) 708 form a draft session-agenda for their area, which is then sent to 709 the WG chairs of the area. After approval it will be sent to the 710 IETF secretariat. 712 An application must contain: 714 - The amount of time requested; 716 - The rough outline of the WG-agenda that is expected to 717 be covered; 719 IESG 15 720 - The estimated number of people that will attend the WG 721 session; 723 - Related wgs that must not be scheduled for the same time 724 slot(s). 726 The Secretariat allots time slots on the basis of the session- 727 agenda made by the Area director(s). If the proposed session- 728 agenda for an area does not fit into the IETF meeting-agenda, the 729 IETF secretariat will adjust it to fit, after consulting the Area 730 director(s) and the relevant chairs. The Secretariat will then 731 form a draft session-agenda and distribute it among the wg-chairs 732 for final approval. 734 2.6. Termination Of A WG 736 Working groups are typically chartered to accomplish a specific 737 task. After that task is complete, the group will be disbanded. 738 However, if the work of a WG results in a Proposed Standard, the 739 WG will go dormant rather than disband (i.e., the WG will no 740 longer conduct formal activities, but the mailing list and the 741 membership will remain available to review the work as it moves 742 to Draft Standard and Standard status). 744 If, at some point, it becomes evident that a Working Group is 745 unable to complete the work outlined in the charter, the group, 746 in consultation with its Area Director can either: 748 1) Recharter to refocus on a smaller task, 750 2) Choose new chair(s), or 752 3) Disband. 754 When the working group chairperson and the Area Director disagree 755 about the steps required to refocus the group or the need to 756 disband the group, the IESG will make a determination with input 757 from the Area Director and the working group chair(s). 759 IESG 16 760 3. MANAGEMENT 762 3.1. WG Chair Duties 764 The Working Group chair(s) have wide discretion in the conduct of 765 business. The WG chair has to make sure that the WG operates in a 766 reasonably efficient and effective way towards reaching the goals 767 and results described in the WG charter. This very general 768 description encompasses at the very least the following detailed 769 tasks: 771 - Moderate the WG distribution list 773 The chair should attempt to ensure that the discussions on 774 this list are relevant and that they converge. The chair 775 should make sure that discussions on the list are summarized 776 and that the outcome is well documented (to avoid 777 repetition). The chair also may choose to schedule 778 organized on-line "session" with agenda and deliverables. 780 - Organize, prepare and chair face-to-face sessions 782 The chair should plan and announce sessions well in advance. 783 (See section on WG Sessions for exact procedures.) The 784 chair should make sure that relevant documents and the final 785 WG-agenda are ready at least 2 weeks in advance of the 786 session. It is strongly suggested that the WG chair creates 787 an anonymous FTP directory for the working group's 788 documents. All relevant documents should be placed in this 789 directory. 791 - Communicate results of session 793 The chair must ensure that minutes of the session are taken 794 and that an attendance list is circulated. After screening 795 the minutes the final version will be sent to the Area 796 Director(s) and the IETF secretariat, in time for 797 publication in the IETF proceedings. The WG chair should 798 provide the Area Directors with a very short report (via E- 799 mail) on the session directly after it takes place. These 800 reports will be used for the Area Report as presented in the 801 proceedings of each IETF meeting. 803 - Distribute the work 805 Of course each WG will have members who may not be able to 806 (or want to) do any work at all. Most of the time the bulk 808 IESG 17 809 of the work is done by a few dedicated members. It is the 810 task of the chair to motivate enough experts to allow for a 811 fair distribution of the workload. 813 - Progress documents 815 The chair will make sure that authors of WG documents 816 incorporate changes as discussed by the WG. Once a document 817 is approved by the WG the chair reports to the Area 818 Director(s) and the IESG secretary. The chair indicates (per 819 E-mail) which document has been approved, and asks the IESG 820 to review it for publication (specify Experimental, Proposed 821 STD, etc.). The Area Director will acknowledge receipt of 822 the E-mail, and from then on action is the responsibility of 823 the IESG. See the section on Review of Documents for 824 possible further involvement of the chair in progressing 825 documents. 827 3.2. Area Director Duties 829 The Area Directors are responsible for ensuring that working 830 groups in their area produce coherent, coordinated and 831 architecturally consistent output from the Working Groups in 832 their area as a contribution to the overall results of the IETF. 833 This very general description encompasses at the very least the 834 detailed tasks related to the Working Groups: 836 - Coordination of WGs 838 The Area director(s) coordinate the work done by the various 839 WGs within (and sometimes even outside) the relevant Area. 840 The Director(s) try to coordinate sessions in such a way 841 that experts can attend the relevant sessions with a minimum 842 of overlap and gaps between sessions. (See section on WG 843 sessions for details) 845 - Reporting 847 The Area Director(s) report to the IETF on progress in the 848 Area. 850 - Reviewing 852 The Area Directors may appoint independent reviewers prior 853 to document approval. The Area Director(s) track the 855 IESG 18 856 progress of documents from the Area through the IESG review 857 process, and report back on this to the WG Chair(s). 859 - Progress tracking 861 The Area Directors track and manage the progress of the 862 various WGs with the aid of a regular status report 863 generated by the IESG secretary. The Area directors forward 864 this regular status reports on documents and milestones made 865 by the IESG Secretary to the WG chairs. This in turn helps 866 the chairs to manage their WGs. 868 - Area Directorate 870 The Area Director(s) chairs the Area Directorate. They are 871 responsible for regular sessions of the directorate. 873 3.3. Contention And Appeals Overview 875 Formal procedures for requesting review and conducting appeals 876 are documented in The Internet Standards Process [1]. A brief 877 summary is provided, here. 879 In fact, the IETF approach to reviews and appeals is quite 880 simple: When an IETF member feels that matters have not been 881 conducted properly, they should state their concern to a member 882 of IETF management. In other words, the process relies upon 883 those who have concerns raising them. If the result is not 884 satisfactory, there are several levels of appeal available, to 885 ensure that review is possible by a number of people uninvolved 886 in the matter in question. 888 Reviews and appeals step through three levels: 890 - Area 892 This includes the Working Group review and Area Director 893 review. No appeal should come to the IESG before the Area 894 Director has reviewed the point of contention. 896 - IESG 898 If the offended party is not happy with the Area-level 899 review, then they may bring them to the IESG chair and the 900 Area Director for Standards Management. The IESG chair has to 901 be in this loop on this. The IESG chair and the Standards 903 IESG 19 904 Area Director will bring the issue before the IESG for 905 discussion and take the resolution back to the parties. 907 - IAB 909 If the offended party is still not happy with the outcome at 910 the IESG level, then they may take their concern to the IAB. 912 Concerns entail either a disagreement with technical decisions by 913 the working group or with the process by which working group 914 business has been conducted. Technical disagreements may be 915 about specific details or about basic approach. When an issue 916 pertains to preference, it should be resolved within the working 917 group. When a matter pertains to the technical adequacy of a 918 decision, review is encouraged whenever the perceived deficiency 919 is noted. For matters having to do with preference, working 920 group rough consensus will dominate. 922 When a matter pertains to working group process, it is important 923 that those with a concern be clear about the manner in which the 924 process was not open or fair and that they be willing to discuss 925 the issue openly and directly. In turn, the IETF management will 926 make every effort to understand how the process was conducted, 927 what deficiencies were present (if any) and how the matter should 928 be corrected. The IETF functions on the good will and mutual 929 respect of its members; continued success requires continued 930 attention to working group process. 932 4. DOCUMENT PROCEDURES 934 4.1. Internet Drafts 936 The Internet Drafts directory is provided to working groups as a 937 resource for posting and disseminating early copies of working 938 group documents. This repository is replicated at various 939 locations around the Internet. It is encouraged that draft 940 documents be posted as soon as they become reasonably stable. 942 It is stressed here that Internet Drafts are working documents 943 and have no official status whatsoever. They may, eventually, 944 turn into a standards-track document or they may sink from sight. 946 IESG 20 947 4.2. Request For Comments (RFC) 949 The work of an IETF working group usually results in publication 950 of one or more documents, published as a Request For Comments 951 (RFCs) [4]. This series is the journal of record for the Internet 952 community. A document can be written by an individual in a 953 working group, by a group as a whole with a designated editor, or 954 by others not involved with the IETF. The designated author need 955 not be the group chair(s). 957 Note: The RFC series is a publication mechanism only and 958 publication does not determine the IETF status of a document. 959 Status is determined through separate, explicit status labels 960 assigned by the IETF. In other words, the reader is reminded 961 that all Internet Standards are published as RFCs, but NOT all 962 RFCs specify standards! 964 For a description on the various subseries of RFCs the reader is 965 referred to [1,5,6,7]. 967 4.3. Submission Of Documents 969 When a WG decides that a working document is ready for 970 publication, the following must be done: 972 - The relevant document as approved by the WG must be in 973 the Internet-Drafts directory; 975 - The relevant document must be formatted according to RFC- 976 rules (see RFC-1111 [4]). 978 - The WG chair sends email to the relevant Area 979 Director(s), with a copy to the IESG Secretary. The 980 mail should contain the reference to the document, and 981 the request that it be progressed as an Informational, 982 Experimental, Prototype or standards-track (Proposed, 983 Draft or Full -- STD) RFC. 985 The Area Director(s) will acknowledge receipt of the E-mail. From 986 then onwards the progressing of the document is the 987 responsibility of the IESG. 989 4.4. Review Of Documents 991 In case the submission is intended as an Informational RFC only 993 IESG 21 994 no review is necessary. However if the WG or the RFC editor 995 thinks that a review is appropriate, the AD may be asked to 996 provide one. In case of submission as an Experimental RFC, the 997 document will always be reviewed by the IESG. This review can 998 either be done by the AD and other IESG members or the IESG may 999 ask for an independent reviewer (i.e., by someone not part of the 1000 WG in question) from the Area Directorate or elsewhere. 1002 A review will lead to one of three possible conclusions: 1004 1. The document is accepted as is. 1006 This fact will be announced by the IESG to the IETF 1007 mailing list and to the RFC Editor. Publication is then 1008 further handled between the RFC editor and the 1009 author(s). 1011 2. Changes regarding content are suggested to the 1012 author(s)/WG. 1014 Suggestions must be clear and direct, so as to 1015 facilitate working group and author correction of the 1016 specification. Once the author(s)/WG have made these 1017 changes or have explained to the satisfaction of the 1018 reviewers why the changes are not necessary, the 1019 document will be accepted for publication as under point 1020 1, above. 1022 3. The document is rejected. 1024 This will need strong and thorough arguments from the 1025 reviewers. The whole IETF and working group process is 1026 structured such that this alternative is not likely to 1027 arise for documents coming from a Working Group. After 1028 all, the intentions of the document will already have 1029 been described in the WG charter, and reviewed at the 1030 start of the WG. 1032 If any individual or group of individuals feels that the review 1033 treatment has been unfair, there is the opportunity to make a 1034 procedural complaint. The mechanism for procedural complaints is 1035 described in the section on Contention and Appeal. 1037 Before making a final decision on a standards-track document, the 1038 IESG will issue a "Last Call" to the IETF mailing list. This Last 1039 Call will announce the intention of the IESG to consider the 1040 document, and it will solicit final comments from the IETF within 1041 a period of two weeks. It is important to note that a Last Call 1042 is intended as a brief, final check with the Internet community, 1044 IESG 22 1045 to make sure that no important concerns have missed or 1046 misunderstood. Last Call cannot serve as a more general, in- 1047 depth review. 1049 5. SECURITY CONSIDERATIONS 1051 Security issues are not addressed in this memo. 1053 6. REFERENCES 1055 [1]RFC1310bis, The Internet Standards Process 1057 [2]Charter Internet Society 1059 [3]New charter IETF 1061 [4]RFC 1111 Request for Comments on Request for Comments, J. 1062 Postel, August 1990. 1064 [5]RFC 1150 F.Y.I. on F.Y.I., G. Malkin and J. Reynolds, March 1065 1990 1067 [6]RFC 1311 Introduction to the Standards Notes, ed. J. Postel, 1068 March 1992. 1070 [7]RFC 1360 IAB Official Protocol Standards, ed. J. Postel, 1071 Sept. 1992. 1073 [8]RFC 1160, The Internet Activities Board, V.Cerf, may 1990 1075 (This should be OBE by [3] by the time this gets published) 1077 [9]Guidelines to Working Group Chair(s), S. Coya, IESG 1078 distribution only. 1080 7. AUTHORS ADDRESS 1082 Erik Huizer 1083 SURFnet bv 1084 P.O. Box 19035 Phone: +31 30 310290 1085 3501 DA Utrecht Fax: +31 30 340903 1086 The Netherlands Email: 1087 Erik.Huizer@SURFnet.nl 1089 IESG 23 1090 Dave Crocker 1091 Silicon Graphics, Inc. 1092 2011 N. Shoreline Blvd. Phone: +1 415 390 1804 1093 P.O. Box 7311 Fax: +1 415 962 8404 1094 Mountain View, CA 94039 Email: dcrocker@sgi.com 1096 APPENDIX: Sample Working Group charter 1098 Integrated Directory Services (ids) 1100 Charter 1102 Chair(s): 1103 Chris Weider 1104 Tim Howes 1106 User Services Area Director(s) 1108 Joyce Reynolds 1110 Mailing lists: 1111 General Discussion:ids@merit.edu 1113 To Subscribe: ids-request@merit.edu 1115 Archive: merit.edu:~/pub/ids-archive 1117 Description of Working Group: 1119 The Integrated Directory Services Working Group (IDS) is 1120 chartered to facilitate the integration and interoperability of 1121 current and future directory services into a unified directory 1122 service. This work will unite directory services based on a 1123 heterogeneous set of directory services protocols (X.500, 1124 WHOIS++, etc.). In addition to specifying technical requirements 1125 for the integration, the IDS Group will also contribute to the 1126 administrative and maintenance issues of directory service 1127 offerings by publishing guidelines on directory data integrity, 1128 maintenance, security, and privacy and legal issues for users and 1129 administrators of directories. IDS will also assume 1131 IESG 24 1132 responsibility for the completion of the outstanding Directory 1133 Information Services Infrastructure (DISI) Internet-Drafts, which 1134 are all specific to the X.500 protocol, and for the maintenance 1135 of FYI 11, ``A catalog of available X.500 implementations''. IDS 1136 will need to liase with the groups working on development and 1137 deployment of the various directory service protocols. 1139 The IDS Working Group is a combined effort of the Applications 1140 Area and the User Services Area of the IETF. 1142 Goals and Milestones: 1144 Ongoing Track emerging directory service protocols to 1145 specify standards for interoperation with existing 1146 protocols. 1148 Ongoing Liase with groups working on deployment and 1149 development of directory services to locate and 1150 fix interoperability problems. 1152 Ongoing Identify unfilled needs of directory service 1153 offerers, administrators, and users. 1155 Mar 93 Submit to the IESG the DISI ``Advanced Usages of 1156 X.500'' paper as an informational document. 1158 Mar 93 Submit to the IESG the DISI ``X.500 Pilot 1159 Project Catalog'' paper as an informational 1160 document. 1162 Mar 93 Submit to the IESG the 1993 revision of FYI 11, 1163 ``A catalog of available X.500 implementations'' 1164 as an informational document. 1166 Mar 93 Submit as an Internet-Draft a ``Specifications 1167 for interoperability between WHOIS++ and X.500''. 1169 Jul 93 Submit as an Internet-Draft a ``Guide to 1170 administering a directory service'', which covers 1171 data integrity, maintenance, privacy and legal 1172 issues, and security. 1174 Jul 93 Submit as an Internet-Draft a ``Catalog of 1175 available WHOIS++ implementations''. 1177 Nov 93 Submit to the IESG the ``Specifications for 1178 interoperability between WHOIS++ and X.500'' as a 1179 standards document. 1181 IESG 25 1182 Nov 93 Submit as an Internet-Draft a ``User's guide to 1183 directory services on the Internet''. 1185 Mar 94 Submit to the IESG the ``Guide to administering 1186 a directory service'' as an informational 1187 document. 1189 Mar 94 Submit to the IESG the 1994 revision of FYI 11. 1191 Mar 94 Submit to the IESG the ``Catalog of available 1192 WHOIS++ implementations'' as an informational 1193 document.