idnits 2.17.00 (12 Aug 2021) /tmp/idnits33128/draft-ietf-poisson-wg-guide-03.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 (2022-05-14) 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) 2022 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 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...ay also distr...' == Line 901 has weird spacing: '.../WG can expla...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 8673 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2027 (ref. '3') (Obsoleted by RFC 2282) ** Downref: Normative reference to an Informational RFC: RFC 1796 (ref. '4') ** Obsolete normative reference: RFC 1543 (ref. '5') (Obsoleted by RFC 2223) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bradner 3 Internet-Draft Harvard University 4 Editor 5 August 1998 7 IETF Working Group 8 Guidelines and Procedures 10 12 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 30 The Internet Engineering Task Force (IETF) has responsibility for 31 developing and reviewing specifications intended as Internet 32 Standards. IETF activities are organized into working groups (WGs). 33 This document describes the guidelines and procedures for formation 34 and operation of IETF working groups. It also describes the formal 35 relationship between IETF participants WG and the Internet 36 Engineering Steering Group (IESG) and the basic duties of IETF 37 participants, including WG Chairs, WG participants, and IETF Area 38 Directors. 40 Table of Contents 42 Status of this Memo.................................................1 43 Abstract............................................................1 44 1. Introduction.....................................................2 45 1.1. IETF approach to standardization.............................4 46 1.2. Roles within a Working Group.................................4 47 2. Working group formation..........................................4 48 2.1. Criteria for formation.......................................4 49 2.2. Charter......................................................5 50 2.3. Charter review & approval....................................8 51 2.4. Birds of a feather (BOF).....................................8 52 3. Working Group Operation..........................................9 53 3.1. Session planning.............................................9 54 3.2. Session venue...............................................10 55 3.3. Session management..........................................12 56 3.4. Contention and appeals......................................13 57 4. Working Group Termination.......................................13 58 5. Rechartering a Working Group....................................13 59 6. Staff Roles.....................................................14 60 6.1. WG Chair....................................................14 61 6.2. WG Secretary................................................16 62 6.3. Document Editor.............................................16 63 6.4. WG Facilitator..............................................16 64 6.5. Design teams................................................16 65 6.6. Working Group Consultant....................................16 66 6.7. Area Director...............................................17 67 7. Working Group Documents.........................................17 68 7.1. Session documents...........................................17 69 7.2. IETF meeting documents......................................17 70 7.3. Internet-Drafts (I-D).......................................17 71 7.4. Request For Comments (RFC)..................................18 72 7.5. Working Group Last-Call.....................................18 73 7.6. Submission of documents.....................................18 74 8. Review of documents.............................................18 75 9. Security Considerations.........................................20 76 10. Acknowledgments................................................20 77 11. References.....................................................20 78 12. Authors' Address...............................................20 79 Appendix: Sample Working Group Charter............................21 81 1. Introuction 82 The Internet, a loosely-organized international collaboration of 83 autonomous, interconnected networks, supports host-to-host 84 communication through voluntary adherence to open protocols and 85 procedures defined by Internet Standards. There are also many 86 isolated interconnected networks, which are not connected to the 87 global Internet but use the Internet Standards. Internet Standards 88 are developed in the Internet Engineering Task Force (IETF). This 89 document defines guidelines and procedures for IETF working groups. 90 The Internet Standards Process of the IETF is defined in [1]. The 91 organizations involved in the IETF Standards Process are described in 92 [2] as are the roles of specific individuals. 94 The IETF is a large, open community of network designers, operators, 95 vendors, users, and researchers concerned with the Internet and the 96 technology used on it. The primary activities of the IETF are 97 performed by committees known as working groups. There are currently 98 more than 100 working groups. ( See the IETF web page for a up-to- 99 date list of IETF Working Groups - http://www.ietf.org.) Working 100 groups tend to have a narrow focus and a lifetime bounded by the 101 completion of a specific set of tasks, although there are exceptions. 103 For management purposes, the IETF working groups are collected 104 together into areas, with each area having a separate focus. For 105 example, the security area deals with the development of security- 106 related technology. Each IETF area is managed by one or two Area 107 Directors. There are currently 8 areas in the IETF but the number 108 changes from time to time. (See the IETF web page for a list of the 109 current areas, the Area Directors for each area, and a list of which 110 working groups are assigned to each area.) 112 In many areas the Area Directors have formed an advisory group or 113 directorate. These comprise experienced members of the IETF and the 114 technical community represented by the area The specific name and 115 the details of the role for each group differs from area to area, but 116 the primary intent is that these groups assist the Area Director(s), 117 e.g., with the review of specifications produced in the area. 119 The IETF area directors are selected by a nominating committee, which 120 also selects an overall chair for the IETF. The nominations process 121 is described in [3]. 123 The area directors sitting as a body, along with the IETF Chair 124 comprise the Internet Engineering Steering Group (IESG). The IETF 125 Executive Director is an ex-officio participant of the IESG, as are 126 the IAB Chair and a designated Internet Architecture Board (IAB) 127 liaison. The IESG approves IETF Standards and approves the 128 publication of other IETF documents. (See [1].) 130 A small IETF Secretariat provides staff and administrative support 131 for the operation of the IETF. 133 There is no formal membership in the IETF. Participation is open to 134 all. This participation may be by on-line contribution, attendance 135 at face-to-face sessions, or both. Anyone from the Internet 136 community who has the time and interest is urged to participate in 137 IETF meetings and any of its on-line working group discussions. 138 Participation is by individual technical contributors, rather than by 139 formal representatives of organizations. 141 This document defines procedures and guidelines for formation and 142 operation of working groups in the IETF. It defines the relations of 143 working groups to other bodies within the IETF. The duties of working 144 group Chairs and Area Directors with respect to the operation of the 145 working group are also defined. When used in this document the key 146 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 147 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 148 interpreted as described in RFC 2119 [6]. RFC 2119 defines the use 149 of these key words to help make the intent of standards track 150 documents as clear as possible. The same key words are used in this 151 document to help smooth WG operation and reduce the chance for 152 confusion about the processes. 154 1.1. IETF approach to standardization 155 Familiarity with The Internet Standards Process [1] is essential for 156 a complete understanding of the philosophy, procedures and guidelines 157 described in this document. 159 1.2. Roles within a Working Group 160 The document "Organizations Involved in the IETF Standards Process" 161 [2] describes the roles of a number of individuals within a working 162 group, including the working group chair and the document editor. 163 These descriptions are expanded later in this document. 165 2. Working group formation 166 IETF working groups (WGs) are the primary mechanism for development 167 of IETF specifications and guidelines, many of which are intended to 168 be standards or recommendations. A working group may be established 169 at the initiative of an Area Director or it may be initiated by an 170 individual or group of individuals. Anyone interested in creating an 171 IETF working group MUST obtain the advice and consent of the IETF 172 Area Director(s) in whose area the working group would fall and MUST 173 proceed through the formal steps detailed in this section. 175 Working groups are typically created to address a specific problem or 176 to produce one or more specific deliverables (a guideline, standards 177 specification, etc.). Working groups are generally expected to be 178 short-lived in nature. Upon completion of its goals and achievement 179 of its objectives, the working group is terminated. A working group 180 may also be terminated for other reasons. (see section 4) 181 Alternatively with the concurrence of the IESG, Area Director, the WG 182 Chair, and the WG participants, the objectives or assignment of the 183 working group may be extended by modifying the working group's 184 charter through a rechartering process (see section 5). 186 2.1. Criteria for formation 187 When determining whether it is appropriate to create a working group, 188 the Area Director(s) and the IESG will consider several issues: 189 - Are the issues that the working group plans to address clear and 190 relevant to the Internet community? 191 - Are the goals specific and reasonably achievable, and achievable 192 within a reasonable time frame? 193 - What are the risks and urgency of the work, to determine the level 194 of effort required? 195 - Do the working group's activities overlap with those of another 196 working group? If so, it may still be appropriate to create the 197 working group, but this question must be considered carefully by 198 the Area Directors as subdividing efforts often dilutes the 199 available technical expertise. 200 - Is there sufficient interest within the IETF in the working group's 201 topic with enough people willing to expend the effort to produce 202 the desired result (e.g., a protocol specification)? Working 203 groups require considerable effort, including management of the 204 working group process, editing of working group documents, and 205 contributing to the document text. IETF experience suggests that 206 these roles typically cannot all be handled by one person; a 207 minimum of four or five active participants in the management 208 positions are typically required in addition to a minimum of one 209 or two dozen people that will attend the working group meetings 210 and contribute on the mailing list. NOTE: The interest must be 211 broad enough that a working group would not be seen as merely the 212 activity of a single vendor. 213 - Is there enough expertise within the IETF in the working group's 214 topic, and are those people interested in contributing in the 215 working group? - Does a base of interested consumers (end users) 216 appear to exist for the planned work? Consumer interest can be 217 measured by participation of end-users within the IETF process, as 218 well as by less direct means. 219 - Does the IETF have a reasonable role to play in the determination 220 of the technology? There are many Internet-related technologies 221 that may be interesting to IETF members but in some cases the IETF 222 may not be in a position to effect the course of the technology in 223 the "real world". For example, if the technology is being 224 developed by another standards body or an industry consortium. 225 - Are all known intellectual property rights relevant to the proposed 226 working group's efforts issues understood? 227 - Is the proposed work plan an open IETF effort or is it an attempt 228 to "bless" non-IETF technology where the effect of input from IETF 229 participants may be limited. 230 - Is there a good understanding of any existing work that is relevant 231 to the topics that the proposed working group is to pursue? This 232 includes work within the IETF and elsewhere. 233 - Do the working group's goals overlap with known work in another 234 standards body, and if so is adequate liaison in place? 236 Considering the above criteria, the Area Director(s), using his or 237 her best judgement, will decide whether to pursue the formation of 238 the group through the chartering process. 240 2.2. Charter 241 The formation of a working group requires a charter which is 242 primarily negotiated between a prospective working group Chair and 243 the relevant Area Director(s), although final approval is made by the 244 IESG with advice from the Internet Architecture Board (IAB). A 245 charter is a contract between a working group and the IETF to perform 246 a set of tasks. A charter: 247 1. Lists relevant administrative information for the working group; 248 2. Specifies the direction or objectives of the working group and 249 describes the approach that will be taken to achieve the goals; 250 and 251 3. Enumerates a set of milestones together with time frames for their 252 completion. 254 When the prospective Chair(s), the Area Director and the IETF 255 Secretariat are satisfied with the charter form and content, it 256 becomes the basis for forming a working group. Note that an Area 257 Director MAY require the holding an exploratory Birds of a Feather 258 (BOF) meeting, as described below, to gage the level of support for a 259 working group before submitting the charter to the IESG and IAB for 260 approval. 262 Charters may be renegotiated periodically to reflect the current 263 status, organization or goals of the working group. (see section 5) 264 Hence, a charter is a contract between the IETF and the working group 265 which is committing to meet explicit milestones and delivering 266 specific "products". 268 Specifically, each charter consists of the following sections: 269 Working group name 270 A working group name should be reasonably descriptive or 271 identifiable. Additionally, the group shall define an acronym 272 (maximum 8 printable ASCII characters) to reference the group in 273 the IETF directories, mailing lists, and general documents. 274 Chair(s) 275 The working group may have one or more Chairs to perform the 276 administrative functions of the group. The email address(es) of 277 the Chair(s) shall be included. Generally a working group is 278 limited to two chairs. 279 Area and Area Director(s) 280 The name of the IETF area with which the working group is 281 affiliated and the name and electronic mail address of the 282 associated Area Director(s). 283 Area Advisor 284 If the area has two Area Directors one of them MUST be listed as 285 the primary contact for the working group. 286 Mailing list 287 An IETF working group MUST have a general Internet mailing list. 288 Most of the work of an IETF working group will be conducted on the 289 mailing list. The working group charter MUST include: 291 1. The address to which a participant sends a subscription request 292 and the procedures to follow when subscribing, 293 2. The address to which a participant sends submissions and 294 special procedures, if any, and 295 3. The location of the mailing list archive. A message archive 296 MUST be maintained in a public place which can be accessed via 297 FTP or via the web. The address "ietf-archive@ietf.org" MUST be 298 included in the mailing list in order that a copy of all 299 mailing list messages is sent to an archive at the IETF 300 Secretariat. There is an archive of a number of working group 301 mailing lists at ftp.ietf.org/ietf-mail-archives. This is a 302 service offered by the IETF Secretariat but it does not 303 eliminate the need for each WG to maintain their own set of 304 archives. 306 Description of working group 307 The focus and intent of the group shall be set forth briefly. By 308 reading this section alone, an individual should be able to decide 309 whether this group is relevant to their own work. The first 310 paragraph must give a brief summary of the problem area, basis, 311 goal(s) and approach(es) planned for the working group. This 312 paragraph can be used as an overview of the working group's 313 effort. 315 To facilitate evaluation of the intended work and to provide on- 316 going guidance to the working group, the charter must describe the 317 problem being solved and must discuss objectives and expected 318 impact with respect to: 319 - Architecture 320 - Operations 321 - Security 322 - Network management 323 - Scaling 324 - Transition (where applicable) 326 Goals and milestones 327 The working group charter MUST establish a timetable for specific 328 work items. While this may be re-negotiated over time, the list of 329 milestones and dates facilitates the Area Director's tracking of 330 working group progress and status, and it is indispensable to 331 potential participants identifying the critical moments for input. 332 Milestones shall consist of deliverables that can be qualified as 333 showing specific achievement; e.g., "Internet-Draft finished" is 334 fine, but "discuss via email" is not. It is helpful to specify 335 milestones for every 3-6 months, so that progress can be gauged 336 easily. This milestone list is expected to be updated 337 periodically. (see section 5) 338 An example of a WG charter is included as Appendix A. 340 2.3. Charter review & approval 341 Proposed working groups often comprise technically competent 342 participants who are not familiar with the history of Internet 343 architecture or IETF processes. This can, unfortunately, lead to 344 good working group consensus about a bad design. To facilitate 345 working group efforts, an Area Director may assign a Consultant from 346 among the ranks of senior IETF participants. (Consultants are 347 described in section 6.) At the discretion of the Area Director, 348 approval of a new WG may be withheld in the absence of sufficient 349 consultant resources. 351 Once the Area Director (and the Area Directorate, as the Area 352 Director deems appropriate) has approved the working group charter, 353 the charter is submitted for review by the IAB and approval by the 354 IESG. After a review period of at least a week the proposed charter 355 is posted to the IETF-announce mailing list as a public notice that 356 the formation of the working group is being considered. At the same 357 time the proposed charter is also posted to the "new-work" mailing 358 list. This mailing list has been created to let qualified 359 representatives from other standards organizations know about pending 360 IETF working groups. After another review period lasting at least a 361 week the IESG MAY approve the charter as-is, it MAY request that 362 changes be made in the charter, or MAY decline to approve chartering 363 of the working group 365 If the IESG approves the formation of the working group it remands 366 the approved charter to the IETF Secretariat who records and enters 367 the information into the IETF tracking database. The working group 368 is announced to the IETF-announce a by the IETF Secretariat. 370 2.4. Birds of a feather (BOF) 371 Often it is not clear whether an issue merits the formation of a 372 working group. To facilitate exploration of the issues the IETF 373 offers the possibility of a Birds of a Feather (BOF) session, as well 374 as the early formation of an email list for preliminary discussion. 375 In addition, a BOF may serve as a forum for a single presentation or 376 discussion, without any intent to form a working group. 378 A BOF is a session at an IETF meeting which permits "market research" 379 and technical "brainstorming". Any individual may request permission 380 to hold a BOF on a subject. The request MUST be filed with a relevant 381 Area Director who must approve a BOF before it can be scheduled. The 382 person who requests the BOF is usually appointed as Chair of the BOF. 383 The Chair of the BOF is also responsible for providing a report on 384 the outcome of the BOF. If the Area Director approves the BOF is 385 then scheduled by submitting a request to agenda@ietf.org with copies 386 to the area Area Director(s). A BOF description and agenda are 387 required before a BOF can be scheduled. 389 The Area Director MAY require the establishment of an open email list 390 prior to authorizing a BOF. This permits initial exchanges and 391 sharing of framework, vocabulary and approaches, in order to make the 392 time spent in the BOF more productive. The Area Director MAY require 393 that a BOF be held, prior to establishing a working group (see 394 section 2.2). The Area Director MAY require that there be a draft of 395 the WG charter prior to holding a BOF. The Area Director MAY require 396 that a BOF not be held until an Internet-Draft describing the 397 proposed technology has been published so it can be used as a basis 398 for discussion in the BOF. 400 In general BOF on a particular topic is held only once (ONE slot at 401 one IETF Plenary meeting). Under unusual circumstances Area Directors 402 may, at their discretion, allow a BOF to meet for a second time. BOFs 403 are not permitted to meet three times. Note that all other things 404 being equal, WGs will be given priority for meeting space over BOFs. 406 Usually the outcome of a BOF will be one of the following: 407 - There was enough interest and focus in the subject to warrant the 408 formation of a WG; 409 - While there was a reasonable level of interest expressed in the BOF 410 some other criteria for working group formation was not met. (see 411 section 2.1) 412 - The discussion came to a fruitful conclusion, with results to be 413 written down and published, however there is no need to establish 414 a WG; or 415 - There was not enough interest in the subject to warrant the 416 formation of a WG. 418 3. Working Group Operation 419 The IETF has basic requirements for open and fair participation and 420 for thorough consideration of technical alternatives. Within those 421 constraints, working groups are autonomous and each determines most 422 of the details of its own operation with respect to session 423 participation, reaching closure, etc. The core rule for operation is 424 that acceptance or agreement is achieved via working group "rough 425 consensus". WG participants should specifically note the 426 requirements for disclosure of conflicts of interest in [2]. 428 A number of procedural questions and issues will arise over time, and 429 it is the function of the Working Group Chair(s) to manage the group 430 process, keeping in mind that the overall purpose of the group is to 431 make progress towards reaching rough consensus in realizing the 432 working group's goals and objectives. 434 There are few hard and fast rules on organizing or conducting working 435 group activities, but a set of guidelines and practices have evolved 436 over time that have proven successful. These are listed here, with 437 actual choices typically determined by the working group participants 438 and the Chair(s). 440 3.1. Session planning 441 For coordinated, structured WG interactions, the Chair(s) MUST 442 publish a draft agenda well in advance of the actual session. The 443 agenda should contain at least: 444 - The items for discussion; 445 - The estimated time necessary per item; and 446 - A clear indication of what documents the participants will need to 447 read before the session in order to be well prepared. 449 Publication of the working group agenda shall include sending a copy 450 of the agenda to the working group mailing list and to 451 agenda@ietf.org. 453 All working group actions shall be taken in a public forum, and wide 454 participation is encouraged. A working group will conduct much of its 455 business via electronic mail distribution lists but may meet 456 periodically to discuss and review task status and progress, to 457 resolve specific issues and to direct future activities. It is 458 common, but not required, that a working group will meet at the IETF 459 Plenary meetings. Additionally, interim sessions may be scheduled for 460 telephone conference, video teleconference, or for face-to-face 461 (physical) sessions. 463 All working group sessions (including those held outside of the IETF 464 meetings) shall be reported by making minutes available. These 465 minutes should include the agenda for the session, an account of the 466 discussion including any decisions made, and a list of attendees. The 467 Working Group Chair is responsible for insuring that session minutes 468 are written and distributed, though the actual task may be performed 469 by someone designated by the Working Group Chair. The minutes shall 470 be submitted in printable ASCII text for publication in the IETF 471 Proceedings, and for posting in the IETF Directories and are to be 472 sent to: minutes@ietf.org 474 3.2. Session venue 475 Each working group will determine the balance of email and face-to- 476 face sessions that is appropriate for achieving its milestones. 477 Electronic mail permits the widest participation; face-to-face 478 meetings often permit better focus and therefore can be more 479 efficient for reaching a consensus among a core of the working group 480 participants. In determining the balance, the WG must ensure that 481 its process does not serve to exclude contribution by email-only 482 participants. Also note that decisions reached during IETF meetings 483 are NOT final, but MUST be conveyed to the mailing list to verify WG 484 consensus. 486 IETF Meetings 487 If a WG needs a session at an IETF meeting, the Chair must apply for 488 time-slots as soon as the first announcement of that IETF meeting is 489 made by the IETF Secretariat to the WG-chairs list. Session time is 490 a scarce resource at IETF meetings, so placing requests early will 491 facilitate schedule coordination for WGs requiring the same set of 492 experts. 494 The application for a WG session at an IETF meeting MUST be made to 495 the IETF Secretariat at the address agenda@ietf.org. Some Area 496 Directors may want to coordinate WG sessions in their area and 497 request that time slots be coordinated through them. If this is the 498 case it will be noted in the IETF meeting announcement. A WG 499 scheduling request MUST contain: 500 - The working group name and full title; 501 - The amount of time requested; 502 - The rough outline of the WG agenda that is expected to be covered; 503 - The estimated number of people that will attend the WG session; 504 - Related WGs that should not be scheduled for the same time 505 slot(s); and 506 - Optionally a request can be added for the WG session to be 507 transmitted over the Internet in audio and video.. 509 NOTE: While open discussion and contribution is essential to working 510 group success, the Chair is responsible for ensuring forward 511 progress. When acceptable to the WG, the Chair may call for 512 restricted participation (but not restricted attendance!) at IETF 513 working group sessions for the purpose of achieving progress. The 514 Working Group Chair then has the authority to refuse to grant the 515 floor to any individual who is unprepared or otherwise covering 516 inappropriate material, or who, in the opinion of the Chair is 517 disrupting the WG process. The Chair should consult with the Area 518 Director(s) if the individual persists in disruptive behavior. 520 On-line 521 It can be quite useful to conduct email exchanges in the same manner 522 as a face-to-face session, with published schedule and agenda, as 523 well as on-going summarization and consensus polling. 525 Many working group participants hold that mailing list discussion is 526 the best place to consider and resolve issues and make decisions. 527 Choice of operational style is made by the working group itself. It 528 is important to note, however, that Internet email discussion is 529 possible for a much wider base of interested persons than is 530 attendance at IETF meetings, due to the time and expense required to 531 attend. 533 As with face-to-face sessions occasionally one or more individuals 534 may engage in behavior on a mailing list which disrupts the WG's 535 progress. In these cases the Chair should attempt to discourage the 536 behavior by communication directly with the offending individual 537 rather than on the open mailing list. If the behavior persists then 538 the Chair must involve the Area Director in the issue. As a last 539 resort and after explicit warnings, the Area Director, with the 540 approval of the IESG, may request that the mailing list maintainer 541 block the ability of the offending individual to post to the mailing 542 list. (If the mailing list software permits this type of operation.) 543 Even if this is done, the individual must not be prevented from 544 receiving messages posted to the list. 546 3.3. Session management 547 Working groups make decisions through a "rough consensus" process. 548 IETF consensus does not require that all participants agree although 549 this is, of course, preferred. In general the dominant view of the 550 working group shall prevail. (However, it must be noted that 551 "dominance" is not to be determined on the basis of volume or 552 persistence, but rather a more general sense of agreement.) Consensus 553 can be determined by a show of hands, humming, or any other means on 554 which the WG agrees (by rough consensus, of course). Note that 51% 555 of the working group does not qualify as "rough consensus" and 99% is 556 better than rough. It is up to the Chair to determine that rough 557 consensus has been reached. 559 The challenge to managing working group sessions is to balance the 560 need for open and fair consideration of the issues against the need 561 to make forward progress. The working group, as a whole, has the 562 final responsibility for striking this balance. The Chair has the 563 responsibility for overseeing the process but may delegate direct 564 process management to a formally-designated Facilitator. 566 It is occasionally appropriate to revisit a topic, to re-evaluate 567 alternatives or to improve the group's understanding of a relevant 568 decision. However, unnecessary repeated discussions on issues can be 569 avoided if the Chair makes sure that the main arguments in the 570 discussion (and the outcome) are summarized and archived after a 571 discussion has come to conclusion. It is also good practice to note 572 important decisions/consensus reached by email in the minutes of the 573 next 'live' session, and to summarize briefly the decision-making 574 history in the final documents the WG produces. 576 To facilitate making forward progress, a Working Group Chair may wish 577 to decide to reject or defer the input from a member, based upon the 578 following criteria: 580 Old 581 The input pertains to a topic that already has been resolved and is 582 redundant with information previously available; 584 Minor 585 The input is new and pertains to a topic that has already been 586 resolved, but it is felt to be of minor import to the existing 587 decision; 589 Timing 590 The input pertains to a topic that the working group has not yet 591 opened for discussion; or 593 Scope 594 The input is outside of the scope of the working group charter. 596 3.4. Contention and appeals 597 Disputes are possible at various stages during the IETF process. As 598 much as possible the process is designed so that compromises can be 599 made, and genuine consensus achieved, however there are times when 600 even the most reasonable and knowledgeable people are unable to 601 agree. To achieve the goals of openness and fairness, such conflicts 602 must be resolved by a process of open review and discussion. 604 Formal procedures for requesting a review of WG, Chair, Area Director 605 or IESG actions and conducting appeals are documented in The Internet 606 Standards Process [1]. 608 4. Working Group Termination 609 Working groups are typically chartered to accomplish a specific task 610 or tasks. After the tasks are complete, the group will be disbanded. 611 However if a WG produces a Proposed or Draft Standard, the WG will 612 become dormant rather than disband (i.e., the WG will no longer 613 conduct formal activities, but the mailing list will remain available 614 to review the work as it moves to Draft Standard and Standard 615 status.) 617 If, at some point, it becomes evident that a working group is unable 618 to complete the work outlined in the charter, or if the assumptions 619 which that work was based have been modified in discussion or by 620 experience, the Area Director, in consultation with the working group 621 can either: 623 1. Recharter to refocus its tasks, 624 2. Choose new Chair(s), or 625 3. Disband. 627 If the working group disagrees with the Area Director's choice, it 628 may appeal to the IESG. (see section 3.4) 630 5. Rechartering a Working Group 631 Updated milestones are re-negotiated with the Area Director and the 632 IESG, as needed, and then are submitted to the IESG Secretariat: 633 iesg-secretary@ietf.org 635 Rechartering (other than revising milestones) a working group follows 636 the same procedures that the initial chartering does. (see section 2) 637 The revised charter must be submitted to the IESG and IAB for 638 approval. As with the initial chartering, the IESG may approve new 639 charter as-is, it may request that changes be made in the new charter 640 (including having the Working Group continue to use the old charter), 641 or it may decline to approve the rechartered working group. In the 642 latter case the working group is disbanded. 644 6. Staff Roles 645 Working groups require considerable care and feeding. In addition to 646 general participation, successful working groups benefit from the 647 efforts of participants filling specific functional roles. The Area 648 Director must agree to the specific people performing the WG Chair, 649 and Working Group Consultant roles, and they serve at the discretion 650 of the Area Director. 652 6.1. WG Chair 653 The Working Group Chair is concerned with making forward progress 654 through a fair and open process, and has wide discretion in the 655 conduct of WG business. The Chair must ensure that a number of tasks 656 are performed, either directly or by others assigned to the tasks. 658 The Chair has the responsibility and the authority to make decisions, 659 on behalf of the working group, regarding all matters of working 660 group process and staffing, in conformance with the rules of the 661 IETF. The AD has the authority and the responsibility to assist in 662 making those decisions at the request of the Chair or when 663 circumstances warrant such an intervention. 665 The Chair's responsibility encompasses at least the following: 667 Ensure WG process and content management 668 The Chair has ultimate responsibility for ensuring that a working 669 group achieves forward progress and meets its milestones. The Chair 670 is also responsible to ensure that the working group operates in an 671 open and fair manner. For some working groups, this can be 672 accomplished by having the Chair perform all management-related 673 activities. In other working groups -- particularly those with large 674 or divisive participation -- it is helpful to allocate process and/or 675 secretarial functions to other participants. Process management 676 pertains strictly to the style of working group interaction and not 677 to its content. It ensures fairness and detects redundancy. The 678 secretarial function encompasses document editing. It is quite 679 common for a working group to assign the task of specification Editor 680 to one or two participants. Sometimes, they also are part of the 681 design team, described below. 683 Moderate the WG email list 684 The Chair should attempt to ensure that the discussions on this list 685 are relevant and that they converge to consensus agreements. The 686 Chair should make sure that discussions on the list are summarized 687 and that the outcome is well documented (to avoid repetition). The 688 Chair also may choose to schedule organized on-line "sessions" with 689 agenda and deliverables. These can be structured as true meetings, 690 conducted over the course of several days (to allow participation 691 across the Internet.) Organize, prepare and chair face-to-face & on- 692 line formal sessions 694 Plan WG Sessions 695 The Chair must plan and announce all WG sessions well in advance. 696 (See section 3.1) 698 Communicate results of sessions 699 The Chair and/or Secretary must ensure that minutes of a session are 700 taken and that an attendance list is circulated. (See section 3.1) 702 Immediately after a session, the WG Chair MUST provide the Area 703 Director with a very short report (approximately one paragraph, via 704 email) on the session. 706 Distribute the workload 707 Of course each WG will have participants who may not be able (or 708 want) to do any work at all. Most of the time the bulk of the work is 709 done by a few dedicated participants. It is the task of the Chair to 710 motivate enough experts to allow for a fair distribution of the 711 workload. 713 Document development 714 Working groups produce documents and documents need authors. The 715 Chair must make sure that authors of WG documents incorporate changes 716 as agreed to by the WG. (See section 6.3) 718 Document publication 719 The Chair and/or Document Editor will work with the RFC Editor to 720 ensure document conformance with RFC publication requirements and to 721 coordinate any editorial changes suggested by the RFC Editor. A 722 particular concern is that all participants are working from the same 723 version of a document at the same time. 725 Document implementations 726 Under the procedures described in [1] the Chair is responsible for 727 documenting the specific implementations which qualify the 728 specification for Draft or Internet Standard status along with 729 documentation about testing of the interoperation of these 730 implementations. 732 6.2. WG Secretary 733 Taking minutes and editing working group documents often is performed 734 by a specifically-designated participant or set of participants. In 735 this role, the Secretary's job is to record WG decisions, rather than 736 to perform basic specification. 738 6.3. Document Editor 739 Most IETF working groups focus their efforts on a document, or set of 740 documents, that capture the results of the group's work. A working 741 group generally designates a person or persons to serve as the Editor 742 for a particular document. The Document Editor is responsible for 743 ensuring that the contents of the document accurately reflect the 744 decisions that have been made by the working group. 746 As a general practice, the Working Group Chair and Document Editor 747 positions are filled by different individuals to help ensure that the 748 resulting documents accurately reflect the consensus of the working 749 group and that all processes are followed. 751 6.4. WG Facilitator 752 When meetings tend to become distracted or divisive, it often is 753 helpful to assign the task of "process management" to one 754 participant. Their job is to oversee the nature, rather than the 755 content, of participant interactions. That is, they attend to the 756 style of the discussion and to the schedule of the agenda, rather 757 than making direct technical contributions themselves. 759 6.5. Design teams 760 It is often useful, and perhaps inevitable, for a sub-group of a 761 working group to develop a proposal to solve a particular problem. 762 Such a sub-group is called a design team. In order for a design team 763 to remain small and agile, it is acceptable to have closed membership 764 and private meetings. Design teams may range from an informal chat 765 between people in a hallway to a formal set of expert volunteers that 766 the WG chair or AD appoints to attack a controversial problem. The 767 output of a design team is always subject to approval, rejection or 768 modification by the WG as a whole. 770 6.6. Working Group Consultant 771 At the discretion of the Area Director, a Consultant may be assigned 772 to a working group. Consultants have specific technical background 773 appropriate to the WG and experience in Internet architecture and 774 IETF process. 776 6.7. Area Director 777 Area Directors are responsible for ensuring that working groups in 778 their area produce coherent, coordinated, architecturally consistent 779 and timely output as a contribution to the overall results of the 780 IETF. 782 7. Working Group Documents 784 7.1. Session documents 785 All relevant documents for a session should be published and 786 available as Internet-Drafts at least two weeks before a session 787 starts. Any document which does not meet this publication deadline 788 can only be discussed in a working group session with the specific 789 approval of the working group chair(s). The final session agenda 790 should be posted to the working group mailing list at two weeks 791 before the session. 793 7.2. IETF meeting documents 794 In preparing for an IETF meeting it is helpful to have ready access 795 to all documents that are being reviewed. Thus all documents which 796 will be under discussion in a working group session must be published 797 as Internet-Drafts before the session. 799 7.3. Internet-Drafts (I-D) 800 The Internet-Drafts directory is provided to working groups as a 801 resource for posting and disseminating in-process copies of working 802 group documents. This repository is replicated at various locations 803 around the Internet. It is encouraged that draft documents be posted 804 as soon as they become reasonably stable. 806 It is stressed here that Internet-Drafts are working documents and 807 have no official standards status whatsoever. They may, eventually, 808 turn into a standards-track document or they may sink from sight. 809 Internet-Drafts are submitted to: internet-drafts@ietf.org 811 The format of an Internet-Draft must be the same as for an RFC [2]. 812 Further, an I-D must contain: 814 - Beginning, standard, boilerplate text which is provided by the 815 Secretariat on their web site and in the ftp directory; 816 - The I-D filename; and 817 - The expiration date for the I-D. 819 Complete specification of requirements for an Internet-Draft are 820 found in the file "1id-guidelines.txt" in the Internet-Drafts 821 directory at an Internet Repository site. The organization of the 822 Internet-Drafts directory is found in the file "1id-organization" in 823 the Internet-Drafts directory at an Internet Repository site. This 824 file also contains the rules for naming Internet-Drafts (See [1] for 825 more information about Internet-Drafts.) 827 7.4. Request For Comments (RFC) 828 The work of an IETF working group often results in publication of one 829 or more documents, as part of the Request For Comments (RFCs) [1] 830 series. This series is the archival publication record for the 831 Internet community. A document can be written by an individual in a 832 working group, by a group as a whole with a designated Editor, or by 833 others not involved with the IETF. 835 NOTE: The RFC series is a publication mechanism only and publication 836 does not determine the IETF status of a document. Status is 837 determined through separate, explicit status labels assigned by the 838 IESG on behalf of the IETF. In other words, the reader is reminded 839 that all Internet Standards are published as RFCs, but NOT all RFCs 840 specify standards. [4] 842 7.5. Working Group Last-Call 843 When a WG decides that a document is ready for publication it may be 844 submitted to the IESG for consideration. In most cases the 845 determination that a WG feels that a document is ready for 846 publication is done by the WG Chair issuing a working group Last- 847 Call. The decision to issue a working group Last-Call is at the 848 discretion of the WG Chair working with the Area Director. A working 849 group Last-Call serves the same purpose within a working group that 850 an IESG Last-Call does in the broader IETF community. (See [1].) 852 7.6 Submission of documents 853 Once that a WG has determined that at least rough consensus exists 854 within the WG for the advancement of a document the following must be 855 done: 856 - The version of the relevant document exactly as agreed to by the 857 WG MUST be in the Internet-Drafts directory; 858 - The relevant document MUST be formatted according to RFC rules 859 [5]. 860 - The WG Chair MUST send email to the relevant Area Director. A 861 copy of the request MUST be also sent to the IESG Secretariat. 862 The mail MUST contain the reference to the document's ID filename, 863 and the action requested. 865 Unless returned to the WG for further development, progressing of the 866 document is then the responsibility of the IESG. After IESG 867 approval, responsibility for final disposition is the joint 868 responsibility of the RFC Editor, the WG Chair and the Document 869 Editor. 871 8. Review of documents 872 The IESG reviews all documents submitted for publication as RFCs. 873 Usually minimal IESG review is necessary in the case of a submission 874 from a WG intended as an Informational or Experimental RFC. More 875 extensive review is undertaken in the case of standards-track 876 documents. 878 Prior to the IESG beginning their deliberations on standards-track 879 documents, IETF Secretariat will issue a "Last-Call" to the IETF 880 mailing list. (See [1]) This Last Call will announce the intention 881 of the IESG to consider the document, and it will solicit final 882 comments from the IETF within a period of two weeks. It is important 883 to note that a Last-Call is intended as a brief, final check with the 884 Internet community, to make sure that no important concerns have been 885 missed or misunderstood. The Last-Call should not serve as a more 886 general, in-depth review. 888 The IESG review takes into account responses to the Last-Call and 889 will lead to one of these possible conclusions: 890 1. The document is accepted as is for the status requested. 891 This fact will be announced by the IETF Secretariat to the IETF 892 mailing list and to the RFC Editor. 894 2. The document is accepted as-is but not for the status requested. 895 This fact will be announced by the IETF Secretariat to the IETF 896 mailing list and to the RFC Editor. (see [1] for more details) 898 3. Changes regarding content are suggested to the author(s)/WG. 899 Suggestions from the IESG must be clear and direct, so as to 900 facilitate working group and author correction of the 901 specification. If the author(s)/WG can explain to the 902 satisfaction of the IESG why the changes are not necessary, the 903 document will be accepted for publication as under point 1, above. 904 If the changes are made the revised document may be resubmitted 905 for IESG review. 907 4. Changes are suggested by the IESG and a change in status is 908 recommended. 909 The process described above for 3 and 2 are followed in that 910 order. 912 5. The document is rejected. 913 Any document rejection will be accompanied by specific and 914 thorough arguments from the IESG. Although the IETF and working 915 group process is structured such that this alternative is not 916 likely to arise for documents coming from a working group the IESG 917 has the right and responsibility to reject documents that the IESG 918 feels are fatally flawed in some way. 920 If any individual or group of individuals feels that the review 921 treatment has been unfair, there is the opportunity to make a 922 procedural complaint. The mechanism for this type of complaints is 923 described in [1]. 925 9. Security Considerations 926 Documents describing IETF processes, such as this one, do not have an 927 impact on the security of the network infrastructure or of Internet 928 applications. 930 It should be noted that all IETF working groups are required to 931 examine and understand the security implications of any technology 932 they develop. This analysis must be included in any resulting RFCs 933 in a Security Considerations section. Note that merely noting a 934 significant security hole is no longer sufficient. IETF developed 935 technologies should not add insecurity to the environment in which 936 they are run. 938 10. Acknowledgments 939 This revision of this document relies heavily on the previous version 940 (RFC 1603) which was edited by Erik Huizer and Dave Crocker. It has 941 been reviewed by the poisson working group. 943 11. References 944 [1] Bradner, S. Ed., "The Internet Standards Process -- Revision 3", 945 RFC 2026, Harvard University, October 1996. 946 [2] Hovey, R., S. Bradner, "The Organizations involved in the IETF 947 Standards Process", RFC 2028, Digital Equipment Corp., Harvard 948 University, October 1996 949 [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall 950 Process: Operation of the Nominating and Recall Committees", RFC 951 2027, CommerceNet, October 1996 952 [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards", 953 RFC 1796, INRIA, ISI, CyberCash, April 1995 954 [5] Postel, J., "Instructions to RFC Authors", RFC 1543, 955 USC/Information Sciences Institute, October 1993. 956 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 957 Level", RFC 2119, March 1997 959 12. Authors' Address 960 Scott Bradner 961 Harvard University 962 1350 Mass Ave. 963 Cambridge MA 964 02138 965 USA 967 phone +1 617 495 3864 969 Appendix: Sample Working Group Charter 971 Working Group Name: 972 IP Telephony (iptel) 974 IETF Area: 975 Transport Area 977 Chair(s): 978 Jonathan Rosenberg 980 Transport Area Director(s): 981 Scott Bradner 982 Allyn Romanow 984 Transport Area Advisor: 985 Allyn Romanow 987 Mailing Lists: 988 General Discussion:iptel@lists.research.bell-labs.com 989 To Subscribe: iptel-request@lists.research.bell-labs.com 990 Archive: http://www.bell-labs.com/mailing-lists/siptel 992 Description of Working Group: 994 Before Internet telephony can become a widely deployed service, a 995 number of protocols must be deployed. These include signaling and 996 capabilities exchange, but also include a number of "peripheral" 997 protocols for providing related services. 999 The primary purpose of this working group is to develop two such 1000 supportive protocols and a frameword document. They are: 1002 1. Call Processing Syntax. When a call is setup between two 1003 endpoints, the signaling will generally pass through several servers 1004 (such as an H.323 gatekeeper) which are responsible for forwarding, 1005 redirecting, or proxying the signaling messages. For example, a user 1006 may make a call to j.doe@bigcompany.com. The signaling message to 1007 initiate the call will arrive at some server at bigcompany. This 1008 server can inform the caller that the callee is busy, forward the 1009 call initiation request to another server closer to the user, or drop 1010 the call completely (among other possibilities). It is very desirable 1011 to allow the callee to provide input to this process, guiding the 1012 server in its decision on how to act. This can enable a wide variety 1013 of advanced personal mobility and call agent services. 1015 Such preferences can be expressed in a call processing syntax, which 1016 can be authored by the user (or generated automatically by some 1017 tool), and then uploaded to the server. The group will develop this 1018 syntax, and specify means of securely transporting and extending it. 1019 The result will be a single standards track RFC. 1021 2. In addition, the group will write a service model document, which 1022 describes the services that are enabled by the call processing 1023 syntax, and discusses how the syntax can be used. This document will 1024 result in a single RFC. 1026 3. Gateway Attribute Distribution Protocol. When making a call 1027 between an IP host and a PSTN user, a telephony gateway must be used. 1028 The selection of such gateways can be based on many criteria, 1029 including client expressed preferences, service provider preferences, 1030 and availability of gateways, in addition to destination telephone 1031 number. Since gateways outside of the hosts' administrative domain 1032 might be used, a protocol is required to allow gateways in remote 1033 domains to distribute their attributes (such as PSTN connectivity, 1034 supported codecs, etc.) to entities in other domains which must make 1035 a selection of a gateway. The protocol must allow for scalable, 1036 bandwidth efficient, and very secure transmission of these 1037 attributes. The group will investigate and design a protocol for this 1038 purpose, generate an Internet Draft, and advance it to RFC as 1039 appropriate. 1041 Goals and Milestones: 1043 May 98 Issue first Internet-Draft on service framework 1044 Jul 98 Submit framework ID to IESG for publication as an RFC. 1045 Aug 98 Issue first Internet-Draft on Call Processing Syntax 1046 Oct 98 Submit Call processing syntax to IESG for consideration 1047 as a Proposed Standard. 1048 Dec 98 Achieve consensus on basics of gateway attribute 1049 distribution protocol 1050 Jan 99 Submit Gateway Attribute Distribution protocol to IESG 1051 for consideration as a RFC (info, exp, stds track TB