idnits 2.17.1 draft-ietf-iasa2-rfc2418bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 192: '...TF working group MUST obtain the advic...' RFC 2119 keyword, line 193: '... the working group would fall and MUST...' RFC 2119 keyword, line 296: '... Director MAY require holding an exp...' RFC 2119 keyword, line 331: '...TF working group MUST have a general I...' RFC 2119 keyword, line 333: '...he working group charter MUST include:...' (21 more instances...) -- The draft header indicates that this document obsoletes RFC2418, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 1097 looks like a reference -- Missing reference section? 'RFC2028' on line 1101 looks like a reference -- Missing reference section? 'RFC2282' on line 1115 looks like a reference -- Missing reference section? 'RFC2119' on line 1106 looks like a reference -- Missing reference section? '1' on line 1122 looks like a reference -- Missing reference section? '2' on line 1124 looks like a reference -- Missing reference section? '3' on line 1126 looks like a reference -- Missing reference section? '4' on line 1128 looks like a reference -- Missing reference section? '5' on line 1130 looks like a reference -- Missing reference section? '6' on line 1132 looks like a reference -- Missing reference section? 'RFC2223' on line 1111 looks like a reference -- Missing reference section? '7' on line 1134 looks like a reference -- Missing reference section? '8' on line 1136 looks like a reference -- Missing reference section? 'RFC1796' on line 1093 looks like a reference -- Missing reference section? 'RFC1603' on line 1089 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bradner, Ed. 3 Internet-Draft 4 Obsoletes: 2418 (if approved) R. Salz, Ed. 5 Intended status: Best Current Practice Akamai Technologies, Inc. 6 Expires: April 23, 2019 October 20, 2018 8 IETF Working Group Guidelines and Procedures 9 draft-ietf-iasa2-rfc2418bis-01 11 Abstract 13 The Internet Engineering Task Force (IETF) has responsibility for 14 developing and reviewing specifications intended as Internet 15 Standards. IETF activities are organized into working groups (WGs). 16 This document describes the guidelines and procedures for formation 17 and operation of IETF working groups. It also describes the formal 18 relationship between IETF participants WG and the Internet 19 Engineering Steering Group (IESG) and the basic duties of IETF 20 participants, including WG Chairs, WG participants, and IETF Area 21 Directors. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 23, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. IETF approach to standardization . . . . . . . . . . . . 4 59 1.2. Roles within a Working Group . . . . . . . . . . . . . . 4 60 2. Working group formation . . . . . . . . . . . . . . . . . . . 4 61 2.1. Criteria for formation . . . . . . . . . . . . . . . . . 5 62 2.2. Charter . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3. Charter review and approval . . . . . . . . . . . . . . . 9 64 2.4. Birds of a feather (BOF) . . . . . . . . . . . . . . . . 10 65 3. Working Group Operation . . . . . . . . . . . . . . . . . . . 11 66 3.1. Session planning . . . . . . . . . . . . . . . . . . . . 11 67 3.2. Session venue . . . . . . . . . . . . . . . . . . . . . . 12 68 3.2.1. IETF Meetings . . . . . . . . . . . . . . . . . . . . 13 69 3.2.2. On-line . . . . . . . . . . . . . . . . . . . . . . . 13 70 3.3. Session management . . . . . . . . . . . . . . . . . . . 14 71 3.4. Contention and appeals . . . . . . . . . . . . . . . . . 16 72 4. Working Group Termination . . . . . . . . . . . . . . . . . . 16 73 5. Rechartering a Working Group . . . . . . . . . . . . . . . . 16 74 6. Staff Roles . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 6.1. WG Chair . . . . . . . . . . . . . . . . . . . . . . . . 17 76 6.2. WG Secretary . . . . . . . . . . . . . . . . . . . . . . 19 77 6.3. Document Editor . . . . . . . . . . . . . . . . . . . . . 19 78 6.4. WG Facilitator . . . . . . . . . . . . . . . . . . . . . 19 79 6.5. Design teams . . . . . . . . . . . . . . . . . . . . . . 19 80 6.6. Working Group Consultant . . . . . . . . . . . . . . . . 20 81 6.7. Area Director . . . . . . . . . . . . . . . . . . . . . . 20 82 7. Working Group Documents . . . . . . . . . . . . . . . . . . . 20 83 7.1. Session documents . . . . . . . . . . . . . . . . . . . . 20 84 7.2. Internet-Drafts (I-D) . . . . . . . . . . . . . . . . . . 20 85 7.3. Request For Comments (RFC) . . . . . . . . . . . . . . . 21 86 7.4. Working Group Last-Call . . . . . . . . . . . . . . . . . 21 87 7.5. Submission of documents . . . . . . . . . . . . . . . . . 21 88 8. Review of documents . . . . . . . . . . . . . . . . . . . . . 22 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 10.1. References . . . . . . . . . . . . . . . . . . . . . . . 23 92 10.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 Appendix A. Sample Working Group Charter . . . . . . . . . . . . 24 94 Appendix B. Changes from RFC 2418 . . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Introduction 99 The Internet, a loosely-organized international collaboration of 100 autonomous, interconnected networks, supports host-to-host 101 communication through voluntary adherence to open protocols and 102 procedures defined by Internet Standards. There are also many 103 isolated interconnected networks, which are not connected to the 104 global Internet but use the Internet Standards. Internet Standards 105 are developed in the Internet Engineering Task Force (IETF). This 106 document defines guidelines and procedures for IETF working groups. 107 The Internet Standards Process of the IETF is defined in [RFC2026]. 108 The organizations involved in the IETF Standards Process are 109 described in [RFC2028] as are the roles of specific individuals. 111 The IETF is a large, open community of network designers, operators, 112 vendors, users, and researchers concerned with the Internet and the 113 technology used on it. The primary activities of the IETF are 114 performed by committees known as working groups. There are currently 115 more than 100 working groups. (See the IETF web page for an up-to- 116 date list of IETF Working Groups - http://www.ietf.org.) Working 117 groups tend to have a narrow focus and a lifetime bounded by the 118 completion of a specific set of tasks, although there are exceptions. 120 For management purposes, the IETF working groups are collected 121 together into areas, with each area having a separate focus. For 122 example, the security area deals with the development of security- 123 related technology. Each IETF area is managed by one or two Area 124 Directors (ADs). There are currently eight areas in the IETF but the 125 number changes from time to time. (See the IETF website for a list 126 of the current areas, the Area Directors for each area, and a list of 127 which working groups are assigned to each area.) 129 In many areas, the Area Directors have formed an advisory group or 130 directorate. These comprise experienced members of the IETF and the 131 technical community represented by the area. The specific name and 132 the details of the role for each group differ from area to area, but 133 the primary intent is that these groups assist the Area Director(s), 134 e.g., with the review of specifications produced in the area. 136 The IETF area directors are selected by a nominating committee, which 137 also selects an overall chair for the IETF. The nominations process 138 is described in [RFC2282]. 140 The area directors sitting as a body, along with the IETF Chair, 141 comprise the Internet Engineering Steering Group (IESG). The 142 Managing Director of the IETF Secretariat is an ex-officio 143 participant of the IESG, as are the IAB Chair and a designated 144 Internet Architecture Board (IAB) liaison. The IESG approves IETF 145 Standards and approves the publication of other IETF documents. (See 146 [RFC2026].) 148 A small IETF Secretariat provides staff and administrative support 149 for the operation of the IETF. 151 There is no formal membership in the IETF. Participation is open to 152 all. This participation may be by on-line contribution, attendance 153 at face-to-face sessions, or both. Anyone from the Internet 154 community who has the time and interest is urged to participate in 155 IETF meetings and any of its on-line working group discussions. 156 Participation is by individual technical contributors, rather than by 157 formal representatives of organizations. 159 This document defines procedures and guidelines for the formation and 160 operation of working groups in the IETF. It defines the relations of 161 working groups to other bodies within the IETF. The duties of 162 working group Chairs and Area Directors with respect to the operation 163 of the working group are also defined. When used in this document 164 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 166 be interpreted as described [RFC2119]. RFC 2119 defines the use of 167 these key words to help make the intent of standards track documents 168 as clear as possible. The same key words are used in this document 169 to help smooth WG operation and reduce the chance for confusion about 170 the processes. 172 1.1. IETF approach to standardization 174 Familiarity with The Internet Standards Process [RFC2026] is 175 essential for a complete understanding of the philosophy, procedures 176 and guidelines described in this document. 178 1.2. Roles within a Working Group 180 The document, "Organizations Involved in the IETF Standards Process" 181 [RFC2028] describes the roles of a number of individuals within a 182 working group, including the working group chair and the document 183 editor. These descriptions are expanded later in this document. 185 2. Working group formation 187 IETF working groups (WGs) are the primary mechanism for development 188 of IETF specifications and guidelines, many of which are intended to 189 be standards or recommendations. A working group may be established 190 at the initiative of an Area Director or it may be initiated by an 191 individual or group of individuals. Anyone interested in creating an 192 IETF working group MUST obtain the advice and consent of the IETF 193 Area Director(s) in whose area the working group would fall and MUST 194 proceed through the formal steps detailed in this section. 196 Working groups are typically created to address a specific problem or 197 to produce one or more specific deliverables (a guideline, standards 198 specification, etc.). Working groups are generally expected to be 199 short-lived in nature. Upon completion of its goals and achievement 200 of its objectives, the working group is terminated. A working group 201 may also be terminated for other reasons (see Section 4). 202 Alternatively, with the concurrence of the IESG, Area Director, the 203 WG Chair, and the WG participants, the objectives or assignment of 204 the working group may be extended by modifying the working group's 205 charter through a rechartering process (see Section 5). 207 2.1. Criteria for formation 209 When determining whether it is appropriate to create a working group, 210 the Area Director(s) and the IESG will consider several issues: 212 o Are the issues that the working group plans to address clear and 213 relevant to the Internet community? 215 o Are the goals specific and reasonably achievable, and achievable 216 within a reasonable time frame? 218 o What are the risks and urgency of the work, to determine the level 219 of effort required? 221 o Do the working group's activities overlap with those of another 222 working group? If so, it may still be appropriate to create the 223 working group, but this question must be considered carefully by 224 the Area Directors as subdividing efforts often dilutes the 225 available technical expertise. 227 o Is there sufficient interest within the IETF in the working 228 group's topic with enough people willing to expend the effort to 229 produce the desired result (e.g., a protocol specification)? 230 Working groups require considerable effort, including management 231 of the working group process, editing of working group documents, 232 and contributing to the document text. IETF experience suggests 233 that these roles typically cannot all be handled by one person; a 234 minimum of four or five active participants in the management 235 positions are typically required in addition to a minimum of one 236 or two dozen people that will attend the working group meetings 237 and contribute on the mailing list. NOTE: The interest must be 238 broad enough that a working group would not be seen as merely the 239 activity of a single vendor. 241 o Is there enough expertise within the IETF in the working group's 242 topic, and are those people interested in contributing in the 243 working group? 245 o Does a base of interested consumers (end-users) appear to exist 246 for the planned work? Consumer interest can be measured by 247 participation of end-users within the IETF process, as well as by 248 less direct means. 250 o Does the IETF have a reasonable role to play in the determination 251 of the technology? There are many Internet-related technologies 252 that may be interesting to IETF members but in some cases the IETF 253 may not be in a position to effect the course of the technology in 254 the "real world". This can happen, for example, if the technology 255 is being developed by another standards body or an industry 256 consortium. 258 o Are all known intellectual property rights relevant to the 259 proposed working group's efforts issues understood? 261 o Is the proposed work plan an open IETF effort or is it an attempt 262 to "bless" non-IETF technology where the effect of input from IETF 263 participants may be limited? 265 o Is there a good understanding of any existing work that is 266 relevant to the topics that the proposed working group is to 267 pursue? This includes work within the IETF and elsewhere. 269 o Do the working group's goals overlap with known work in another 270 standards body, and if so is adequate liaison in place? 272 Considering the above criteria, the Area Director(s), using his or 273 her best judgement, will decide whether to pursue the formation of 274 the group through the chartering process. 276 2.2. Charter 278 The formation of a working group requires a charter which is 279 primarily negotiated between a prospective working group Chair and 280 the relevant Area Director(s), although final approval is made by the 281 IESG with advice from the Internet Architecture Board (IAB). A 282 charter is a contract between a working group and the IETF to perform 283 a set of tasks. A charter: 285 1. Lists relevant administrative information for the working group; 286 2. Specifies the direction or objectives of the working group and 287 describes the approach that will be taken to achieve the goals; 288 and 290 3. Enumerates a set of milestones together with time frames for 291 their completion. 293 When the prospective Chair(s), the Area Director and the IETF 294 Secretariat are satisfied with the charter form and content, it 295 becomes the basis for forming a working group. Note that an Area 296 Director MAY require holding an exploratory Birds of a Feather (BOF) 297 meeting, as described below, to gage the level of support for a 298 working group before submitting the charter to the IESG and IAB for 299 approval. 301 Charters may be renegotiated periodically to reflect the current 302 status, organization or goals of the working group (see Section 5). 303 Hence, a charter is a contract between the IETF and the working group 304 which is committing to meet explicit milestones and delivering 305 specific "products." 307 Specifically, each charter consists of the following sections: 309 Working group name 310 A working group name should be reasonably descriptive or 311 identifiable. Additionally, the group shall define an acronym 312 (maximum eight printable ASCII characters) to reference the group 313 in the IETF directories, mailing lists, and general documents. 315 Chair(s) 316 The working group may have one or more Chairs to perform the 317 administrative functions of the group. The email address(es) of 318 the Chair(s) shall be included. Generally, a working group is 319 limited to two chairs. 321 Area and Area Director(s) 322 The name of the IETF area with which the working group is 323 affiliated and the name and electronic mail address of the 324 associated Area Director(s). 326 Responsible Area Director 327 The Area Director who acts as the primary IESG contact for the 328 working group. 330 Mailing list 331 An IETF working group MUST have a general Internet mailing list. 332 Most of the work of an IETF working group will be conducted on the 333 mailing list. The working group charter MUST include: 335 1. The address to which a participant sends a subscription 336 request and the procedures to follow when subscribing, 338 2. The address to which a participant sends submissions and 339 special procedures, if any, and 341 3. The location of the mailing list archive. A message archive 342 MUST be maintained in a public place which can be accessed via 343 FTP or via the web. 345 As a service to the community, the IETF Secretariat operates a 346 mailing list archive for working group mailing lists. In order to 347 take advantage of this service, working group mailing lists MUST 348 include the address "wg_acronym-archive@ietf.org" (where 349 "wg_acronym" is the working group acronym) in the mailing list in 350 order that a copy of all mailing list messages be recorded in the 351 Secretariat's archive. Those archives are located at 352 ftp://ftp.ietf.org/ietf-mail-archive. For robustness, WGs SHOULD 353 maintain an additional archive separate from that maintained by 354 the Secretariat. 356 Description of working group 357 The focus and intent of the group shall be set forth briefly. By 358 reading this section alone, an individual should be able to decide 359 whether this group is relevant to their own work. The first 360 paragraph must give a brief summary of the problem area, basis, 361 goal(s) and approach(es) planned for the working group. This 362 paragraph can be used as an overview of the working group's 363 effort. 364 To facilitate evaluation of the intended work and to provide on- 365 going guidance to the working group, the charter must describe the 366 problem being solved and should discuss objectives and expected 367 impact with respect to: 369 * Architecture 371 * Operations 373 * Security 375 * Network management 377 * Scaling 379 * Transition (where applicable) 381 Goals and milestones 382 The working group charter MUST establish a timetable for specific 383 work items. While this may be renegotiated over time, the list of 384 milestones and dates facilitates the Area Director's tracking of 385 working group progress and status, and it is indispensable to 386 potential participants identifying the critical moments for input. 387 Milestones shall consist of deliverables that can be qualified as 388 showing specific achievement; e.g., "Internet-Draft finished" is 389 fine, but "discuss via email" is not. It is helpful to specify 390 milestones for every three to six months, so that progress can be 391 gauged easily. This milestone list is expected to be updated 392 periodically (see Section 5). 394 An example of a WG charter is included as Appendix A. 396 2.3. Charter review and approval 398 Proposed working groups often comprise technically competent 399 participants who are not familiar with the history of Internet 400 architecture or IETF processes. This can, unfortunately, lead to 401 good working group consensus about a bad design. To facilitate 402 working group efforts, an Area Director may assign a Consultant from 403 among the ranks of senior IETF participants. (Consultants are 404 described in Section 6.) At the discretion of the Area Director, 405 approval of a new WG may be withheld in the absence of sufficient 406 consultant resources. 408 Once the Area Director (and the Area Directorate, as the Area 409 Director deems appropriate) has approved the working group charter, 410 the charter is submitted for review by the IAB and approval by the 411 IESG. After a review period of at least a week the proposed charter 412 is posted to the IETF-announce mailing list as a public notice that 413 the formation of the working group is being considered. At the same 414 time the proposed charter is also posted to the "new-work" mailing 415 list. This mailing list has been created to let qualified 416 representatives from other standards organizations know about pending 417 IETF working groups. After another review period lasting at least a 418 week the IESG MAY approve the charter as-is, it MAY request that 419 changes be made in the charter, or MAY decline to approve chartering 420 of the working group 422 If the IESG approves the formation of the working group it remands 423 the approved charter to the IETF Secretariat who records and enters 424 the information into the IETF tracking database. The working group 425 is announced to the IETF-announce a by the IETF Secretariat. 427 2.4. Birds of a feather (BOF) 429 Often it is not clear whether an issue merits the formation of a 430 working group. To facilitate exploration of the issues the IETF 431 offers the possibility of a Birds of a Feather (BOF) session, as well 432 as the early formation of an email list for preliminary discussion. 433 In addition, a BOF may serve as a forum for a single presentation or 434 discussion, without any intent to form a working group. 436 A BOF is a session at an IETF meeting which permits "market research" 437 and technical "brainstorming". Any individual may request permission 438 to hold a BOF on a subject. The request MUST be filed with a 439 relevant Area Director who must approve a BOF before it can be 440 scheduled. The person who requests the BOF may be asked to serve as 441 Chair of the BOF. 443 The Chair of the BOF is also responsible for providing a report on 444 the outcome of the BOF. If the Area Director approves, the BOF is 445 then scheduled by submitting a request to agenda@ietf.org [1] with 446 copies to the Area Director(s). A BOF description and agenda are 447 required before a BOF can be scheduled. 449 Available time for BOFs is limited, and BOFs are held at the 450 discretion of the ADs for an area. The AD(s) may require additional 451 assurances before authorizing a BOF. For example, 453 o The Area Director MAY require the establishment of an open email 454 list prior to authorizing a BOF. This permits initial exchanges 455 and sharing of framework, vocabulary and approaches, in order to 456 make the time spent in the BOF more productive. 458 o The Area Director MAY require that a BOF be held, prior to 459 establishing a working group (see Section 2.2). 461 o The Area Director MAY require that there be a draft of the WG 462 charter prior to holding a BOF. 464 o The Area Director MAY require that a BOF not be held until an 465 Internet-Draft describing the proposed technology has been 466 published so it can be used as a basis for discussion in the BOF. 468 In general, a BOF on a particular topic is held only once (ONE slot 469 at one IETF Plenary meeting). Under unusual circumstances Area 470 Directors may, at their discretion, allow a BOF to meet for a second 471 time. BOFs are not permitted to meet three times. Note that all 472 other things being equal, WGs will be given priority for meeting 473 space over BOFs. Also, occasionally BOFs may be held for other 474 purposes than to discuss formation of a working group. 476 Usually the outcome of a BOF will be one of the following: 478 o There was enough interest and focus in the subject to warrant the 479 formation of a WG; 481 o While there was a reasonable level of interest expressed in the 482 BOF some other criteria for working group formation was not met 483 (see Section 2.1). 485 o The discussion came to a fruitful conclusion, with results to be 486 written down and published, however there is no need to establish 487 a WG; or 489 o There was not enough interest in the subject to warrant the 490 formation of a WG. 492 3. Working Group Operation 494 The IETF has basic requirements for open and fair participation and 495 for thorough consideration of technical alternatives. Within those 496 constraints, working groups are autonomous and each determines most 497 of the details of its own operation with respect to session 498 participation, reaching closure, etc. The core rule for operation is 499 that acceptance or agreement is achieved via working group "rough 500 consensus". WG participants should specifically note the 501 requirements for disclosure of conflicts of interest in [RFC2028]. 503 A number of procedural questions and issues will arise over time, and 504 it is the function of the Working Group Chair(s) to manage the group 505 process, keeping in mind that the overall purpose of the group is to 506 make progress towards reaching rough consensus in realizing the 507 working group's goals and objectives. 509 There are few hard and fast rules on organizing or conducting working 510 group activities, but a set of guidelines and practices has evolved 511 over time that have proven successful. These are listed here, with 512 actual choices typically determined by the working group participants 513 and the Chair(s). 515 3.1. Session planning 517 For coordinated, structured WG interactions, the Chair(s) MUST 518 publish a draft agenda well in advance of the actual session. The 519 agenda should contain at least: 521 o The items for discussion; 523 o The estimated time necessary per item; and 524 o A clear indication of what documents the participants will need to 525 read before the session in order to be well prepared. 527 Publication of the working group agenda shall include sending a copy 528 of the agenda to the working group mailing list and to 529 agenda@ietf.org [2] 531 All working group actions shall be taken in a public forum, and wide 532 participation is encouraged. A working group will conduct much of 533 its business via electronic mail distribution lists but may meet 534 periodically to discuss and review task status and progress, to 535 resolve specific issues and to direct future activities. IETF 536 Plenary meetings are the primary venue for these face-to-face working 537 group sessions, and it is common (though not required) that active 538 "interim" face-to-face meetings, telephone conferences, or video 539 conferences may also be held. Interim meetings are subject to the 540 same rules for advance notification, reporting, open participation, 541 and process, which apply to other working group meetings. 543 All working group sessions (including those held outside of the IETF 544 meetings) shall be reported by making minutes available. These 545 minutes should include the agenda for the session, an account of the 546 discussion including any decisions made, and a list of attendees. 547 The Working Group Chair is responsible for insuring that session 548 minutes are written and distributed, though the actual task may be 549 performed by someone designated by the Working Group Chair. The 550 minutes shall be submitted in printable ASCII text for publication in 551 the IETF Proceedings, and for posting in the IETF Directories and are 552 to be sent to: minutes@ietf.org [3] 554 3.2. Session venue 556 Each working group will determine the balance of email and face-to- 557 face sessions that is appropriate for achieving its milestones. 558 Electronic mail permits the widest participation; face-to-face 559 meetings often permit better focus and therefore can be more 560 efficient for reaching a consensus among a core of the working group 561 participants. In determining the balance, the WG must ensure that 562 its process does not serve to exclude contribution by email-only 563 participants. Decisions reached during a face-to-face meeting about 564 topics or issues which have not been discussed on the mailing list, 565 or are significantly different from previously arrived mailing list 566 consensus MUST be reviewed on the mailing list. 568 3.2.1. IETF Meetings 570 If a WG needs a session at an IETF meeting, the Chair must apply for 571 time-slots as soon as the first announcement of that IETF meeting is 572 made by the IETF Secretariat to the wg-chairs@ietf.org [4] list. 573 Session time is a scarce resource at IETF meetings, so placing 574 requests early will facilitate schedule coordination for WGs 575 requiring the same set of experts. 577 The application for a WG session at an IETF meeting MUST be made to 578 the IETF Secretariat at the address agenda@ietf.org [5]. Some Area 579 Directors may want to coordinate WG sessions in their area and 580 request that time slots be coordinated through them. If this is the 581 case it will be noted in the IETF meeting announcement. A WG 582 scheduling request MUST contain: 584 o The working group name and full title; 586 o The amount of time requested; 588 o The rough outline of the WG agenda that is expected to be covered; 590 o The estimated number of people that will attend the WG session; 592 o Related WGs that should not be scheduled for the same time 593 slot(s); and 595 o Optionally a request can be added for the WG session to be 596 transmitted over the Internet in audio and video. 598 NOTE: While open discussion and contribution is essential to working 599 group success, the Chair is responsible for ensuring forward 600 progress. When acceptable to the WG, the Chair may call for 601 restricted participation (but not restricted attendance!) at IETF 602 working group sessions for the purpose of achieving progress. The 603 Working Group Chair then has the authority to refuse to grant the 604 floor to any individual who is unprepared or otherwise covering 605 inappropriate material, or who, in the opinion of the Chair is 606 disrupting the WG process. The Chair should consult with the Area 607 Director(s) if the individual persists in disruptive behavior. 609 3.2.2. On-line 611 It can be quite useful to conduct email exchanges in the same manner 612 as a face-to-face session, with published schedule and agenda, as 613 well as on-going summarization and consensus polling. Many working 614 group participants hold that mailing list discussion is the best 615 place to consider and resolve issues and make decisions. The choice 616 of operational style is made by the working group itself. It is 617 important to note, however, that Internet email discussion is 618 possible for a much wider base of interested persons than is 619 attendance at IETF meetings, due to the time and expense required to 620 attend. 622 As with face-to-face sessions occasionally one or more individuals 623 may engage in behavior on a mailing list which disrupts the WG's 624 progress. In these cases the Chair should attempt to discourage the 625 behavior by communication directly with the offending individual 626 rather than on the open mailing list. If the behavior persists then 627 the Chair must involve the Area Director in the issue. As a last 628 resort and after explicit warnings, the Area Director, with the 629 approval of the IESG, may request that the mailing list maintainer 630 block the ability of the offending individual to post to the mailing 631 list. (If the mailing list software permits this type of operation.) 632 Even if this is done, the individual must not be prevented from 633 receiving messages posted to the list. Other methods of mailing list 634 control may be considered but must be approved by the AD(s) and the 635 IESG. 637 3.3. Session management 639 Working groups make decisions through a "rough consensus" process. 640 IETF consensus does not require that all participants agree although 641 this is, of course, preferred. In general, the dominant view of the 642 working group shall prevail. (However, it must be noted that 643 "dominance" is not to be determined on the basis of volume or 644 persistence, but rather a more general sense of agreement.) 645 Consensus can be determined by a show of hands, humming, or any other 646 means on which the WG agrees (by rough consensus, of course). Note 647 that 51% of the working group does not qualify as "rough consensus" 648 and 99% is better than rough. It is up to the Chair to determine if 649 rough consensus has been reached. 651 It can be particularly challenging to gauge the level of consensus on 652 a mailing list. There are two different cases where a working group 653 may be trying to understand the level of consensus via a mailing list 654 discussion. But in both cases the volume of messages on a topic is 655 not, by itself, a good indicator of consensus since one or two 656 individuals may be generating much of the traffic. 658 In the case where a consensus which has been reached during a face- 659 to-face meeting is being verified on a mailing list the people who 660 were in the meeting and expressed agreement must be taken into 661 account. If there were 100 people in a meeting and only a few people 662 on the mailing list disagree with the consensus of the meeting then 663 the consensus should be seen as being verified. Note that enough 664 time should be given to the verification process for the mailing list 665 readers to understand and consider any objections that may be raised 666 on the list. The normal two week last-call period should be 667 sufficient for this. 669 The other case is where the discussion has been held entirely over 670 the mailing list. The determination of the level of consensus may be 671 harder to do in this case since most people subscribed to mailing 672 lists do not actively participate in discussions on the list. It is 673 left to the discretion of the working group chair how to evaluate the 674 level of consensus. The most common method used is for the working 675 group chair to state what he or she believes to be the consensus view 676 and. at the same time, requests comments from the list about the 677 stated conclusion. 679 The challenge to managing working group sessions is to balance the 680 need for open and fair consideration of the issues against the need 681 to make forward progress. The working group, as a whole, has the 682 final responsibility for striking this balance. The Chair has the 683 responsibility for overseeing the process but may delegate direct 684 process management to a formally-designated Facilitator. 686 It is occasionally appropriate to revisit a topic, to re-evaluate 687 alternatives or to improve the group's understanding of a relevant 688 decision. However, unnecessary repeated discussions on issues can be 689 avoided if the Chair makes sure that the main arguments in the 690 discussion (and the outcome) are summarized and archived after a 691 discussion has come to conclusion. It is also good practice to note 692 important decisions/consensus reached by email in the minutes of the 693 next 'live' session, and to summarize briefly the decision-making 694 history in the final documents the WG produces. 696 To facilitate making forward progress, a Working Group Chair may wish 697 to decide to reject or defer the input from a member, based upon the 698 following criteria: 700 Old 701 The input pertains to a topic that already has been resolved and 702 is redundant with information previously available; 704 Minor 705 The input is new and pertains to a topic that has already been 706 resolved, but it is felt to be of minor import to the existing 707 decision; 709 Timing 710 The input pertains to a topic that the working group has not yet 711 opened for discussion; or 713 Scope 714 The input is outside of the scope of the working group charter. 716 3.4. Contention and appeals 718 Disputes are possible at various stages during the IETF process. As 719 much as possible the process is designed so that compromises can be 720 made, and genuine consensus achieved; however, there are times when 721 even the most reasonable and knowledgeable people are unable to 722 agree. To achieve the goals of openness and fairness, such conflicts 723 must be resolved by a process of open review and discussion. 725 Formal procedures for requesting a review of WG, Chair, Area Director 726 or IESG actions and conducting appeals are documented in The Internet 727 Standards Process [RFC2026]. 729 4. Working Group Termination 731 Working groups are typically chartered to accomplish a specific task 732 or tasks. After the tasks are complete, the group will be disbanded. 733 However, if a WG produces a Proposed or Draft Standard, the WG will 734 frequently become dormant rather than disband (i.e., the WG will no 735 longer conduct formal activities, but the mailing list will remain 736 available to review the work as it moves to Draft Standard and 737 Standard status.) 739 If, at some point, it becomes evident that a working group is unable 740 to complete the work outlined in the charter, or if the assumptions 741 which that work was based have been modified in discussion or by 742 experience, the Area Director, in consultation with the working group 743 can either: 745 1. Recharter to refocus its tasks, 747 2. Choose new Chair(s), or 749 3. Disband. 751 If the working group disagrees with the Area Director's choice, it 752 may appeal to the IESG (see Section 3.4). 754 5. Rechartering a Working Group 756 Updated milestones are renegotiated with the Area Director and the 757 IESG, as needed, and then are submitted to the IESG Secretariat: 758 iesg-secretary@ietf.org [6]. 760 Rechartering (other than revising milestones) a working group follows 761 the same procedures that the initial chartering does (see Section 2). 762 The revised charter must be submitted to the IESG and IAB for 763 approval. As with the initial chartering, the IESG may approve new 764 charter as-is, it may request that changes be made in the new charter 765 (including having the Working Group continue to use the old charter), 766 or it may decline to approve the rechartered working group. In the 767 latter case, the working group is disbanded. 769 6. Staff Roles 771 Working groups require considerable care and feeding. In addition to 772 general participation, successful working groups benefit from the 773 efforts of participants filling specific functional roles. The Area 774 Director must agree to the specific people performing the WG Chair, 775 and Working Group Consultant roles, and they serve at the discretion 776 of the Area Director. 778 6.1. WG Chair 780 The Working Group Chair is concerned with making forward progress 781 through a fair and open process, and has wide discretion in the 782 conduct of WG business. The Chair must ensure that a number of tasks 783 are performed, either directly or by others assigned to the tasks. 785 The Chair has the responsibility and the authority to make decisions, 786 on behalf of the working group, regarding all matters of working 787 group process and staffing, in conformance with the rules of the 788 IETF. The AD has the authority and the responsibility to assist in 789 making those decisions at the request of the Chair or when 790 circumstances warrant such an intervention. 792 The Chair's responsibility encompasses at least the following: 794 Ensure WG process and content management 795 The Chair has ultimate responsibility for ensuring that a working 796 group achieves forward progress and meets its milestones. The 797 Chair is also responsible to ensure that the working group 798 operates in an open and fair manner. For some working groups, 799 this can be accomplished by having the Chair perform all 800 management-related activities. In other working groups -- 801 particularly those with large or divisive participation -- it is 802 helpful to allocate process and/or secretarial functions to other 803 participants. Process management pertains strictly to the style 804 of working group interaction and not to its content. It ensures 805 fairness and detects redundancy. The secretarial function 806 encompasses document editing. It is quite common for a working 807 group to assign the task of specification Editor to one or two 808 participants. Sometimes, they also are part of the design team, 809 described below. 811 Moderate the WG email list 812 The Chair should attempt to ensure that the discussions on this 813 list are relevant and that they converge to consensus agreements. 814 The Chair should make sure that discussions on the list are 815 summarized and that the outcome is well documented (to avoid 816 repetition). The Chair also may choose to schedule organized on- 817 line "sessions" with agenda and deliverables. These can be 818 structured as true meetings, conducted over the course of several 819 days (to allow participation across the Internet). 820 Organize, prepare and chair face-to-face and on-line formal 821 sessions. 823 Plan WG Sessions 824 The Chair must plan and announce all WG sessions well in advance 825 (see Section 3.1). 827 Communicate results of sessions 828 The Chair and/or Secretary must ensure that minutes of a session 829 are taken and that an attendance list is circulated (see 830 Section 3.1). 831 Immediately after a session, the WG Chair MUST provide the Area 832 Director with a very short report (approximately one paragraph, 833 via email) on the session. 835 Distribute the workload 836 Of course, each WG will have participants who may not be able (or 837 want) to do any work at all. Most of the time the bulk of the 838 work is done by a few dedicated participants. It is the task of 839 the Chair to motivate enough experts to allow for a fair 840 distribution of the workload. 842 Document development 843 Working groups produce documents and documents need authors. The 844 Chair must make sure that authors of WG documents incorporate 845 changes as agreed to by the WG (see Section 6.3). 847 Document publication 848 The Chair and/or Document Editor will work with the RFC Editor to 849 ensure document conformance with RFC publication requirements 850 [RFC2223] and to coordinate any editorial changes suggested by the 851 RFC Editor. A particular concern is that all participants are 852 working from the same version of a document at the same time. 854 Document implementations 855 Under the procedures described in [RFC2026], the Chair is 856 responsible for documenting the specific implementations which 857 qualify the specification for Draft or Internet Standard status 858 along with documentation about testing of the interoperation of 859 these implementations. 861 6.2. WG Secretary 863 Taking minutes and editing working group documents often is performed 864 by a specifically-designated participant or set of participants. In 865 this role, the Secretary's job is to record WG decisions, rather than 866 to perform basic specification. 868 6.3. Document Editor 870 Most IETF working groups focus their efforts on a document, or set of 871 documents, that capture the results of the group's work. A working 872 group generally designates a person or persons to serve as the Editor 873 for a particular document. The Document Editor is responsible for 874 ensuring that the contents of the document accurately reflect the 875 decisions that have been made by the working group. 877 As a general practice, the Working Group Chair and Document Editor 878 positions are filled by different individuals to help ensure that the 879 resulting documents accurately reflect the consensus of the working 880 group and that all processes are followed. 882 6.4. WG Facilitator 884 When meetings tend to become distracted or divisive, it often is 885 helpful to assign the task of "process management" to one 886 participant. Their job is to oversee the nature, rather than the 887 content, of participant interactions. That is, they attend to the 888 style of the discussion and to the schedule of the agenda, rather 889 than making direct technical contributions themselves. 891 6.5. Design teams 893 It is often useful, and perhaps inevitable, for a sub-group of a 894 working group to develop a proposal to solve a particular problem. 895 Such a sub-group is called a design team. In order for a design team 896 to remain small and agile, it is acceptable to have closed membership 897 and private meetings. Design teams may range from an informal chat 898 between people in a hallway to a formal set of expert volunteers that 899 the WG chair or AD appoints to attack a controversial problem. The 900 output of a design team is always subject to approval, rejection or 901 modification by the WG as a whole. 903 6.6. Working Group Consultant 905 At the discretion of the Area Director, a Consultant may be assigned 906 to a working group. Consultants have specific technical background 907 appropriate to the WG and experience in Internet architecture and 908 IETF process. 910 6.7. Area Director 912 Area Directors are responsible for ensuring that working groups in 913 their area produce coherent, coordinated, architecturally consistent 914 and timely output as a contribution to the overall results of the 915 IETF. 917 7. Working Group Documents 919 7.1. Session documents 921 All relevant documents to be discussed at a session should be 922 published and available as Internet-Drafts at least two weeks before 923 a session starts. Any document which does not meet this publication 924 deadline can only be discussed in a working group session with the 925 specific approval of the working group chair(s). Since it is 926 important that working group members have adequate time to review all 927 documents, granting such an exception should only be done under 928 unusual conditions. The final session agenda should be posted to the 929 working group mailing list at least two weeks before the session and 930 sent at that time to agenda@ietf.org [7] for publication on the IETF 931 web site. 933 7.2. Internet-Drafts (I-D) 935 The Internet-Drafts directory is provided to working groups as a 936 resource for posting and disseminating in-process copies of working 937 group documents. This repository is replicated at various locations 938 around the Internet. It is encouraged that draft documents be posted 939 as soon as they become reasonably stable. 941 It is stressed here that Internet-Drafts are working documents and 942 have no official standards status whatsoever. They may, eventually, 943 turn into a standards-track document or they may sink from sight. 944 Internet-Drafts are submitted to: internet-drafts@ietf.org [8]. 946 The format of an Internet-Draft must be the same as for an RFC 947 [RFC2028]. Further, an I-D must contain: 949 o Beginning, standard, boilerplate text which is provided by the 950 Secretariat on their web site and in the ftp directory; 952 o The I-D filename; and 954 o The expiration date for the I-D. 956 Complete specification of requirements for an Internet-Draft are 957 found in the file "1id-guidelines.txt" in the Internet-Drafts 958 directory at an Internet Repository site. The organization of the 959 Internet-Drafts directory is found in the file "1id-organization" in 960 the Internet-Drafts directory at an Internet Repository site. This 961 file also contains the rules for naming Internet-Drafts. (See 962 [RFC2026] for more information about Internet-Drafts.) 964 7.3. Request For Comments (RFC) 966 The work of an IETF working group often results in publication of one 967 or more documents, as part of the Request For Comments (RFCs) 968 [RFC2026] series. This series is the archival publication record for 969 the Internet community. A document can be written by an individual 970 in a working group, by a group as a whole with a designated Editor, 971 or by others not involved with the IETF. 973 NOTE: The RFC series is a publication mechanism only and publication 974 does not determine the IETF status of a document. Status is 975 determined through separate, explicit status labels assigned by the 976 IESG on behalf of the IETF. In other words, the reader is reminded 977 that all Internet Standards are published as RFCs, but NOT all RFCs 978 specify standards [RFC1796]. 980 7.4. Working Group Last-Call 982 When a WG decides that a document is ready for publication it may be 983 submitted to the IESG for consideration. In most cases the 984 determination that a WG feels that a document is ready for 985 publication is done by the WG Chair issuing a working group Last- 986 Call. The decision to issue a working group Last-Call is at the 987 discretion of the WG Chair working with the Area Director. A working 988 group Last-Call serves the same purpose within a working group that 989 an IESG Last-Call does in the broader IETF community (see [RFC2026]). 991 7.5. Submission of documents 993 Once that a WG has determined at least rough consensus exists within 994 the WG for the advancement of a document the following must be done: 996 o The version of the relevant document exactly as agreed to by the 997 WG MUST be in the Internet-Drafts directory. 999 o The relevant document MUST be formatted according to Section 7.3. 1001 o The WG Chair MUST send email to the relevant Area Director. A 1002 copy of the request MUST be also sent to the IESG Secretariat. 1003 The mail MUST contain the reference to the document's ID filename, 1004 and the action requested. The copy of the message to the IESG 1005 Secretariat is to ensure that the request gets recorded by the 1006 Secretariat so that they can monitor the progress of the document 1007 through the process. 1009 Unless returned by the IESG to the WG for further development, 1010 progressing of the document is then the responsibility of the IESG. 1011 After IESG approval, responsibility for final disposition is the 1012 joint responsibility of the RFC Editor, the WG Chair and the Document 1013 Editor. 1015 8. Review of documents 1017 The IESG reviews all documents submitted for publication as RFCs. 1018 Usually minimal IESG review is necessary in the case of a submission 1019 from a WG intended as an Informational or Experimental RFC. More 1020 extensive review is undertaken in the case of standards-track 1021 documents. 1023 Prior to the IESG beginning their deliberations on standards-track 1024 documents, IETF Secretariat will issue a "Last-Call" to the IETF 1025 mailing list (see [RFC2026]). This Last Call will announce the 1026 intention of the IESG to consider the document, and it will solicit 1027 final comments from the IETF within a period of two weeks. It is 1028 important to note that a Last-Call is intended as a brief, final 1029 check with the Internet community, to make sure that no important 1030 concerns have been missed or misunderstood. The Last-Call should not 1031 serve as a more general, in-depth review. 1033 The IESG review takes into account responses to the Last-Call and 1034 will lead to one of these possible conclusions: 1036 1. The document is accepted as is for the status requested. This 1037 fact will be announced by the IETF Secretariat to the IETF 1038 mailing list and to the RFC Editor. 1040 2. The document is accepted as-is but not for the status requested. 1041 This fact will be announced by the IETF Secretariat to the IETF 1042 mailing list and to the RFC Editor (see [RFC2026] for more 1043 details). 1045 3. Changes regarding content are suggested to the author(s)/WG. 1046 Suggestions from the IESG must be clear and direct, so as to 1047 facilitate working group and author correction of the 1048 specification. If the author(s)/WG can explain to the 1049 satisfaction of the IESG why the changes are not necessary, the 1050 document will be accepted for publication as under Paragraph 1, 1051 above. If the changes are made the revised document may be 1052 resubmitted for IESG review. 1054 4. Changes are suggested by the IESG and a change in status is 1055 recommended. The process described above for Paragraph 3 and 1056 Paragraph 2 are followed in that order. 1058 5. The document is rejected. Any document rejection will be 1059 accompanied by specific and thorough arguments from the IESG. 1060 Although the IETF and working group process is structured such 1061 that this alternative is not likely to arise for documents coming 1062 from a working group, the IESG has the right and responsibility 1063 to reject documents that the IESG feels are fatally flawed in 1064 some way. 1066 If any individual or group of individuals feels that the review 1067 treatment has been unfair, there is the opportunity to make a 1068 procedural complaint. The mechanism for this type of complaints is 1069 described in [RFC2026]. 1071 9. Security Considerations 1073 Documents describing IETF processes, such as this one, do not have an 1074 impact on the security of the network infrastructure or of Internet 1075 applications. 1077 It should be noted that all IETF working groups are required to 1078 examine and understand the security implications of any technology 1079 they develop. This analysis must be included in any resulting RFCs 1080 in a Security Considerations section. Note that merely noting a 1081 significant security hole is no longer sufficient. IETF developed 1082 technologies should not add insecurity to the environment in which 1083 they are run. 1085 10. References 1087 10.1. References 1089 [RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines 1090 and Procedures", RFC 1603, DOI 10.17487/RFC1603, March 1091 1994, . 1093 [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are 1094 Standards", RFC 1796, DOI 10.17487/RFC1796, April 1995, 1095 . 1097 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1098 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1099 . 1101 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 1102 the IETF Standards Process", BCP 11, RFC 2028, 1103 DOI 10.17487/RFC2028, October 1996, 1104 . 1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1107 Requirement Levels", BCP 14, RFC 2119, 1108 DOI 10.17487/RFC2119, March 1997, 1109 . 1111 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 1112 RFC 2223, DOI 10.17487/RFC2223, October 1997, 1113 . 1115 [RFC2282] Galvin, J., "IAB and IESG Selection, Confirmation, and 1116 Recall Process: Operation of the Nominating and Recall 1117 Committees", RFC 2282, DOI 10.17487/RFC2282, February 1118 1998, . 1120 10.2. URIs 1122 [1] mailto:agenda@ietf.org 1124 [2] mailto:agenda@ietf.org 1126 [3] mailto:minutes@ietf.org 1128 [4] mailto:wg-chairs@ietf.org 1130 [5] mailto:agenda@ietf.org 1132 [6] mailto:iesg-secretary@ietf.org 1134 [7] mailto:agenda@ietf.org 1136 [8] mailto:internet-drafts@ietf.org 1138 Appendix A. Sample Working Group Charter 1140 Working Group Name: 1141 IP Telephony (iptel) 1143 IETF Area: 1144 Transport Area 1146 Chair(s): 1147 Jonathan Rosenberg 1149 Transport Area Director(s): 1150 Scott Bradner Allyn Romanow 1152 Responsible Area Director: 1153 Allyn Romanow 1155 Mailing Lists: 1156 General Discussion:iptel@lists.research.bell-labs.com 1157 To Subscribe: iptel-request@lists.research.bell-labs.com 1158 Archive: http://www.bell-labs.com/mailing-lists/siptel 1160 Description of Working Group: 1161 Before Internet telephony can become a widely deployed service, a 1162 number of protocols must be deployed. These include signaling and 1163 capabilities exchange, but also include a number of "peripheral" 1164 protocols for providing related services. 1165 The primary purpose of this working group is to develop two such 1166 supportive protocols and a frameword document. They are: 1168 1. Call Processing Syntax. When a call is setup between two 1169 endpoints, the signaling will generally pass through several 1170 servers (such as an H.323 gatekeeper) which are responsible 1171 for forwarding, redirecting, or proxying the signaling 1172 messages. For example, a user may make a call to 1173 j.doe@bigcompany.com. The signaling message to initiate the 1174 call will arrive at some server at bigcompany. This server 1175 can inform the caller that the callee is busy, forward the 1176 call initiation request to another server closer to the user, 1177 or drop the call completely (among other possibilities). It 1178 is very desirable to allow the callee to provide input to this 1179 process, guiding the server in its decision on how to act. 1180 This can enable a wide variety of advanced personal mobility 1181 and call agent services. 1182 Such preferences can be expressed in a call processing syntax, 1183 which can be authored by the user (or generated automatically 1184 by some tool), and then uploaded to the server. The group 1185 will develop this syntax, and specify means of securely 1186 transporting and extending it. The result will be a single 1187 standards track RFC. 1189 2. In addition, the group will write a service model document, 1190 which describes the services that are enabled by the call 1191 processing syntax, and discusses how the syntax can be used. 1192 This document will result in a single RFC. 1194 3. Gateway Attribute Distribution Protocol. When making a call 1195 between an IP host and a PSTN user, a telephony gateway must 1196 be used. The selection of such gateways can be based on many 1197 criteria, including client expressed preferences, service 1198 provider preferences, and availability of gateways, in 1199 addition to destination telephone number. Since gateways 1200 outside of the hosts' administrative domain might be used, a 1201 protocol is required to allow gateways in remote domains to 1202 distribute their attributes (such as PSTN connectivity, 1203 supported codecs, etc.) to entities in other domains which 1204 must make a selection of a gateway. The protocol must allow 1205 for scalable, bandwidth efficient, and very secure 1206 transmission of these attributes. The group will investigate 1207 and design a protocol for this purpose, generate an Internet 1208 Draft, and advance it to RFC as appropriate. 1210 Goals and Milestones: 1212 Date Milestone 1213 May 98 Issue first Internet-Draft on service framework 1214 Jul 98 Submit framework ID to IESG for publication as an RFC. 1215 Aug 98 Issue first Internet-Draft on Call Processing Syntax 1216 Oct 98 Submit Call processing syntax to IESG for consideration 1217 as a Proposed Standard 1218 Dec 98 Achieve consensus on basics of gateway attribute 1219 distribution protocol 1220 Jan 99 Submit Gateway Attribute Distribution protocol to IESG 1221 for consideration as a RFC (info, exp, stds track TB 1223 Appendix B. Changes from RFC 2418 1225 Changed IETF Executive Director title to Managing Director of the 1226 Secretariat. 1228 Converted to XML input format, and made relevant insignificant 1229 Editorial changes. 1231 Authors' Addresses 1233 Scott Bradner (editor) 1235 Email: sob@sobco.com 1236 Rich Salz (editor) 1237 Akamai Technologies, Inc. 1238 150 Broadway 1239 Cambridge, MA 02142 1240 USA 1242 Email: rsalz@akamai.com