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