idnits 2.17.1 draft-crocker-rfc2418bis-wgguidelines-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.) ** There are 15 instances of too long lines in the document, the longest one being 63 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC7221, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2418, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2026, 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1, 2015) is 3157 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: 'AD' is mentioned on line 348, but not defined == Missing Reference: 'RFC 2026' is mentioned on line 1020, but not defined == Missing Reference: 'RFC7258' is mentioned on line 1802, but not defined == Missing Reference: 'PROTO-WIKI' is mentioned on line 2090, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AgendaNotes' -- Possible downref: Non-RFC (?) normative reference: ref. 'IETF-Meetings' -- Possible downref: Non-RFC (?) normative reference: ref. 'Interim' -- Possible downref: Non-RFC (?) normative reference: ref. 'MeetMaterials' -- Possible downref: Non-RFC (?) normative reference: ref. 'MeetMaterialTool' -- Possible downref: Non-RFC (?) normative reference: ref. 'MeetRequest' -- Obsolete informational reference (is this intentional?): RFC 1603 (Obsoleted by RFC 2418) -- Obsolete informational reference (is this intentional?): RFC 2028 (Obsoleted by RFC 9281) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker, Ed. 3 Internet-Draft Brandenburg InternetWorking 4 Obsoletes: 2418, 7221 (if approved) R. Droms, Ed. 5 Updates: 2026 (if approved) Cisco Systems 6 Intended status: Best Current Practice September 1, 2015 7 Expires: March 4, 2016 9 IETF Working Group Guidelines and Procedures 10 draft-crocker-rfc2418bis-wgguidelines-01 12 Abstract 14 IETF activities are primarily organized into open-participation 15 working groups (WGs). This document describes the formation, 16 requirements, structure, and operation of IETF working groups. This 17 includes the formal relationships and duties of participants. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 4, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Terminology and References . . . . . . . . . . . . . . . 4 56 1.3. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Basic Structure and Requirements . . . . . . . . . . . . . . 6 58 2.1. Working Group Charter . . . . . . . . . . . . . . . . . . 6 59 2.2. Deliverables . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3. Mailing List . . . . . . . . . . . . . . . . . . . . . . 7 61 2.4. Area Directors . . . . . . . . . . . . . . . . . . . . . 8 62 2.5. Chair(s) . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.6. Document Writer . . . . . . . . . . . . . . . . . . . . . 9 64 2.7. Participants . . . . . . . . . . . . . . . . . . . . . . 9 65 2.8. Rough Consensus Decision Making . . . . . . . . . . . . . 9 66 3. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.1. Home Page . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.2. Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 3.3. Issue-tracking Tickets . . . . . . . . . . . . . . . . . 11 70 3.4. Meeting Materials . . . . . . . . . . . . . . . . . . . . 11 71 3.5. Internet-Drafts (I-D) . . . . . . . . . . . . . . . . . . 12 72 3.6. Request For Comments (RFC) . . . . . . . . . . . . . . . 12 73 4. Working Group Internal Operation . . . . . . . . . . . . . . 12 74 4.1. Prime Directives . . . . . . . . . . . . . . . . . . . . 12 75 4.2. General Organizing . . . . . . . . . . . . . . . . . . . 13 76 4.3. Discussion and Progress . . . . . . . . . . . . . . . . . 15 77 4.4. IETF Open Decision-Making . . . . . . . . . . . . . . . . 16 78 4.5. Mailing List Primacy . . . . . . . . . . . . . . . . . . 16 79 4.6. Discussion Venues . . . . . . . . . . . . . . . . . . . . 17 80 4.7. Session Planning . . . . . . . . . . . . . . . . . . . . 20 81 4.8. Meeting Drafts and Documents . . . . . . . . . . . . . . 21 82 4.9. Meeting Record Keeping . . . . . . . . . . . . . . . . . 21 83 5. Document Development & Lifecycle . . . . . . . . . . . . . . 21 84 5.1. Basic Sequence . . . . . . . . . . . . . . . . . . . . . 22 85 5.2. Early Document Review . . . . . . . . . . . . . . . . . . 23 86 5.3. Document Coordination Between Working Groups . . . . . . 23 87 5.4. Working Group Last-Call . . . . . . . . . . . . . . . . . 24 88 5.5. Final External Review of Documents . . . . . . . . . . . 24 89 6. Staff Roles . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 6.1. Development . . . . . . . . . . . . . . . . . . . . . . . 26 91 6.2. Advice . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 7. WG External Administration . . . . . . . . . . . . . . . . . 27 94 7.1. Working group Formation . . . . . . . . . . . . . . . . . 27 95 7.2. Charter Content . . . . . . . . . . . . . . . . . . . . . 32 96 7.3. Submission & Publication of Documents . . . . . . . . . . 33 97 7.4. Working Group Termination . . . . . . . . . . . . . . . . 34 98 7.5. Contention and appeals . . . . . . . . . . . . . . . . . 35 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 101 9.1. References - Normative . . . . . . . . . . . . . . . . . 35 102 9.2. References - Informative . . . . . . . . . . . . . . . . 36 103 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 104 Appendix B. Sample Working Group Charters . . . . . . . . . . . 38 105 B.1. DPRIVE . . . . . . . . . . . . . . . . . . . . . . . . . 38 106 B.2. iptel . . . . . . . . . . . . . . . . . . . . . . . . . . 40 107 B.3. rtg . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 108 B.4. another one . . . . . . . . . . . . . . . . . . . . . . . 45 109 Appendix C. [PROTO-WIKI] Working Group Advice . . . . . . . . . 45 110 C.1. If you have a formal WG role... . . . . . . . . . . . . . 45 111 C.2. Advice for Chairs . . . . . . . . . . . . . . . . . . . . 45 112 C.3. Meetings . . . . . . . . . . . . . . . . . . . . . . . . 46 113 C.4. Ongoing WG operation . . . . . . . . . . . . . . . . . . 47 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 116 1. Introduction 118 The IETF ([RFC3995],[About]) is an open community of network 119 designers, operators, vendors, users, and researchers concerned with 120 the development and operation of Internet technical specifications. 121 Activities of the IETF are primarily performed by committees known as 122 Working Groups [WG]. For administrative purposes, they are organized 123 into topical [Areas]. Working groups are formally chartered, 124 typically with a narrow focus and lifetime bounded by the completion 125 of a specific set of tasks. 127 This document describes the formation, requirements, structure, and 128 operation of IETF working groups. This includes the formal 129 relationships and duties of participants. 131 At base, working groups are driven by: 133 o Goals 135 o Rules 137 o Tasks 139 o Participants 141 That is, a collection of participants, who fill various roles, work 142 toward some common goal(s), according to IETF requirements. This 143 document is principally organized according to these distinctions. 145 1.1. Background 147 This version is organized as an aid to (new) working group 148 participants both as an introduction and as a later reference. 150 o It describes existing IETF rules and practices and does not 151 describe or suggest any changes. 153 Specifically this version of the document: 155 o Replaces general IETF tutorial material that it had with pointers 156 to independent versions 158 o Incorporates work from a number of targeted efforts over the years 160 o Reorganizes content to aid direct use by working group 161 participants 163 o Distinguishes between formal IETF requirements and processes, 164 versus common practices chosen by working groups, where the latter 165 are primarily discussed in a non-normative external IETF Wiki 166 (Appendix C) that can be continually revised by the community. 168 A useful introduction to the IETF is The Tao of IETF: A Novice's 169 Guide to the Internet Engineering Task Force [Tao]. Familiarity with 170 The Internet Standards Process [RFC2026] is essential for a complete 171 understanding of the philosophy, procedures and guidelines described 172 in this document. 174 1.2. Terminology and References 176 When used in this document the key words "MUST", "MUST NOT", 177 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 178 "RECOMMENDED", "MAY", and "OPTIONAL" are normative and are to be 179 interpreted as described in [RFC2119]. 181 NOTE: Summary text about other documents is solely advisory. 182 Unless explicitly stated otherwise, it MUST NOT be taken as pre- 183 empting the content of those documents. 185 Throughout the document, there are portions prefaced with a (Task) 186 label. These call out specific actions that are required, suggested, 187 or permitted. Besides being meant to draw the eye to action items 188 that are distinct from surrounding discussion text, these provide an 189 approximate list of tasks that might be assigned to various roles in 190 the working group, as discussed in Section 6. 192 1.3. OPEN ISSUES 194 NOTE TO RFC EDITOR: Remove this section before publication. 196 This list is an invitation for information, pointers, corrections, 197 and additional/different text. In some cases, resolution will 198 require discussion and some version of IETF consensus. 200 Roles/Titles: What are the formal WG roles/titles that are a) 201 documented, b) can be written into a charter, and c) can be 202 assigned via the Datatracker? E.g., Consultant vs. Tech Adviser. 203 What are the formal permissions for "Delegated authority"? What 204 are options and what are choices within options? 206 Doc Publication: In terms of process, what is formally required 207 vs. typical vs. wg choice. Eg, a) required - wg last call? -- 208 maybe not required, but advisable to avoid an appeal; b) Formal: 209 publication as wg item, when pushing doc out of wg to iesg/rfc 210 editor. 212 WG Ops vs. Tasks: Macro vs micro -- Overall wg management, eg, 213 meetings and task sequencing; vs. managing a task, eg, doc 214 revisions, issue tracking, writer/wg relationship. 216 Familiarity: Besides RFC 2026, what other IETF docs are "required" 217 for the reader to have familiarity with? 219 Charter negotiation: WHO NEGOTIATES A CHARTER??? Distinguish 220 required vs. flexible. Emphasize open and accountable. 222 Citations: What other RFCs, IESG Statements, etc. need to be 223 cited? 225 Mailing List Hosting: (Secretariat queried) Are IETF working group 226 mailing lists now required to be hosted at the IETF? 228 Milestones: make sure example charter in Appendix A includes 229 milestones 231 Suspension: Email -- " the Area Director, with the approval of the 232 IESG, MAY request that the mailing list maintainer block the 233 ability of the offending individual to post to the mailing list." 234 Is it the AD that does this? Who really does? 236 Docs on Agenda: "Any document which does not meet this publication 237 deadline can only be discussed in a working group session with the 238 specific approval of the working group chair(s)." Current 239 operation is that /all/ items on an agenda are explicitly approved 240 by the chair/wg??? -- distinguish "IETF" deadline from "WG- 241 specific" requirement(s)." 243 Wiki? What should be moved to the Wiki or added to it? 245 Normative? Review references for normative/non-normative placement 246 listing in doc. 248 Reporting? Resolve various IETF website pages concerning 249 submission and archive of notes, etc? 251 Milestone Revision: Revised milestones MUST be approved by the 252 cognizant Area Director. Is any other review or approval needed, 253 such as from the IESG? 255 2. Basic Structure and Requirements 257 The IETF permits wide variation in the conduct of working group 258 affairs. Still, there is a core of required organization and 259 required operation. This section describes that core. 261 2.1. Working Group Charter 263 A working group is based on a formal a charter, which is a contract 264 between a working group and the IETF to perform a set of tasks. A 265 charter: 267 o Lists relevant administrative information for the working group 269 o Specifies the direction or objectives of the working group and 270 describes the approach that will be taken to achieve the goals 272 o Enumerates a set of milestones together with time frames for their 273 completion 275 Details concerning charters are provided in Section 7.2. 277 2.2. Deliverables 279 A working group's charter specifies deliverables to be achieved. 280 (Section 7.2) These are usually documents to be published in the 281 Request for Comments series [RFC-Editor]. The means of achieving 282 those deliverables is only lightly constrained: whatever permits a 283 working group to conduct a fair, open and accountable process, while 284 achieving working group rough consensus, is permitted. The challenge 285 with this flexibility is formulating the details of internal working 286 group structure and process in a manner that ensures timely 287 achievement. 289 In other words, the group needs to efficiently balance fair and open 290 discussion, proper attention to legitimate concerns, and making 291 forward progress. 293 2.3. Mailing List 295 A process that is truly open and inclusive makes participation as 296 easy as possible, for the widest range of participants as possible. 297 For the IETF, that means that the primary venue for working group 298 activities MUST be the mailing list associated with the group. 299 (Section 7.2) Further, the mailing list MUST be the only venue for 300 formally assessing working group rough consensus. 302 "Decisions" made at venues other than the working group mailing 303 list MUST be treated as preliminary, and MUST be explicitly 304 documented and confirmed through the mailing list. 306 (Task) It is important to ensure that the discussions on this list 307 are relevant and that they converge to consensus agreements. 309 (Task) It can help to summarize a discussion periodically. 311 (Task) It also can help later review to ensure that outcomes are 312 well and explicitly documented (to avoid repetition). 314 The Chair also MAY choose to schedule organized on-line "sessions" 315 with agenda and deliverables. These can be structured as true 316 meetings, conducted over the course of several days (to allow 317 participation across the Internet). 319 Mailing lists related to IETF activities are usually hosted at the 320 IETF, but generally MAY be hosted elsewhere. 322 (Task) A message archive MUST be maintained in a public place 323 which can be accessed via FTP or via the web. 325 As a service to the community, the IETF Secretariat operates a 326 mailing list archive for working group mailing lists. In order to 327 take advantage of this service, working group mailing lists MUST 328 include the address: 330 {ACRONYM}-archive@ietf.org 332 (where {ACRONYM} is the abbreviated name for the working group) in 333 the mailing list, so that a copy of all mailing list messages is 334 recorded in the Secretariat's archive for the list. 336 Multiple versions of list archives are available, as indicated in the 337 "Archives" section of [MailList]. One form is located at: 339 http://www.ietf.org/mail-archive/web/{ACRONYM}/current/maillist.html 341 where {ACRONYM} is the abbreviated name for the working group. For 342 robustness, WGs SHOULD maintain an additional archive separate from 343 that maintained by the Secretariat. 345 2.4. Area Directors 347 IETF Working Groups are administratively aggregated into "areas". 348 Each working group has a designated ("cognizant") Area Director [AD] 349 ([AD-Desc],[Areas]), to formally select chairs for the working group 350 and to provide oversight. 352 2.5. Chair(s) 354 Working Group Chairs are formally responsible for ensuring that the 355 working group makes forward progress through a fair and open process. 356 They have wide discretion in the conduct of WG business. However 357 within the bounds of IETF formal requirement, Chairs are always 358 accountable to the rough consensus (Section 2.8) of the working group 359 participants, as well as to the Area Director who appointed them. 360 Chairs ensure that a number of procedural, administrative and project 361 management tasks are performed, either directly or by others assigned 362 to the tasks. 364 Chairs have the authority and the responsibility to make decisions, 365 on behalf of the working group, regarding all matters of internal 366 working group process and staffing, in conformance with the rules of 367 the IETF. The AD has the authority and the responsibility to assist 368 in making those decisions at the request of the Chair or when 369 circumstances warrant such an intervention. 371 The choices for assignment of tasks are highly dependent upon the 372 nature of the working group topic, the nature of the work to be done, 373 and the nature of working group participation. When a topic is well- 374 understood, the deliverables straightforward and the participants 375 generally knowledgeable and compatible, a very streamlined working 376 group organization can be quite reasonable. As topic and/or 377 participation get more challenging, working group operation typically 378 needs to be more actively and formally managed, typically requiring 379 administrative tasks to be spread among other participants and 380 processes for discussion and decision-making more structured. 382 2.6. Document Writer 384 Most IETF working groups focus their efforts on a document, or set of 385 documents, that capture the results of the group's work. A working 386 group designates one or more people to serve as the Writer for a 387 particular document. The Document Writer is responsible for ensuring 388 that the contents of the document accurately reflect the decisions 389 that have been made by the working group. 391 As a general practice, the Working Group Chair and Document Writer 392 positions are filled by different individuals to help ensure a clear 393 distinction between process management and content generation. This 394 helps the resulting documents to accurately reflect the consensus of 395 the working group. However this separation is not a firm 396 requirement. Especially in a small, narrow, simple effort among a 397 cohesive group, it might be convenient and efficient for the Chair 398 and Writer roles to be combined. 400 The Document Writer is variously called an "author" or an "editor". 401 The IETF does not have consistent rules for distinguishing use of 402 these terms. However, see Section 3 of [RFC7221] for a suggested 403 distinction between primary responsibility for creating concepts and 404 content, versus responsibility for recording content developed by the 405 working group itself. 407 2.7. Participants 409 The foundation of a working group is its participants. Within the 410 scope of the charter, working group participants represent the entire 411 Internet, indicating what output is needed from the working group 412 effort -- including who will use it and why -- and providing 413 guidance, ideas, text, discussion, and assessment. For all 414 substantive choices, the 'rough consensus' of the participants 415 determines the real work of the group. 417 NOTE: WG participants MUST conform to the requirements for 418 disclosure of conflicts of interest in [RFC2028]. 420 2.8. Rough Consensus Decision Making 422 The IETF does not have "members" and it's open processes can not make 423 decisions by "voting". Rather, a community sense of strongly- 424 dominant agreement, in the absence of compelling objections, is used 425 to make decisions. This is called Rough Consensus [RFC7282]. Within 426 working group processes, this is the required means for making 427 working group decisions, but more importantly it is a model for 428 considering issues. 430 Expediency: In the abstract, nearly all working group activities 431 and decisions are subject to Rough Consensus. In practice, 432 working group chairs often make decisions based on the assumption 433 of working group support. This practice is essential for working 434 group efficiency, but its risk is that the chair's choices will 435 not actually be in sync with the working group's desires. 436 Consequently, all participants carry the responsibility of voicing 437 concerns they consider significant, even when no other participant 438 has spoken up. 440 Substantiveness: A major challenge in considering Rough Consensus 441 appears to be distinguishing between active and passive support. 442 Active support is indicated by participants that are actively 443 engaged in discussing the topic, whereas passive has, at most, pro 444 forma expressions of support, without any obvious indication that 445 the topic is both understand and important to the participant. 446 The dangers of passive support are that it could mean the topic is 447 not adequately understood and/or that the topic will not obtain 448 community followup, such as deployment and use. 450 Minorities: The other major challenge, as discussed in [RFC7282], 451 is that "minority" concerns are not adequately addressed. In 452 particular in the interest of moving the working group effort 453 along, it is easy to marginalize such concerns because they are 454 expressed by few participants. What this risks is failure to 455 attend to problems that are serious and will affect utility of the 456 work later. There is, of course, a competing pressure that 457 'minority' voices could stall the working group. So the core 458 working group challenge with a minority concern is to adequately 459 consider its nature and adequately consider its effect, while 460 still making forward progress. 462 3. Documents 464 3.1. Home Page 466 Each working group has an associated web page, listing working group 467 documents and pointing to a variety of related other pages. The 468 working group home page is located at: 470 http://datatracker.ietf.org/wg/{ACRONYM}/documents/ 472 where {ACRONYM} is the abbreviated name for the working group. 474 3.2. Wiki 476 Working groups can have access to an editable wiki, if requested by a 477 Chair, for use as the working group sees fit. It is located at: 479 http://trac.tools.ietf.org/wg/{ACRONYM}/trac/wiki 481 where {ACRONYM} is the abbreviated name for the working group. 483 3.3. Issue-tracking Tickets 485 (Task) As topics, issues and suggestions increase for a working 486 group, it can be helpful to document them in an issue tracking 487 system. 489 One can be provided through the working group wiki, if requested by a 490 Chair, at the tab for "View Tickets": 492 http://trac.tools.ietf.org/wg/{ACRONYM}/trac/report 494 where {ACRONYM} is the abbreviated name for the working group. 496 3.4. Meeting Materials 498 Any organized working group session (meeting) will have planning and 499 reporting material, including: 501 o Agenda 503 o Presentations 505 o Notes 507 o Transcripts (e.g., jabber logs) 509 (Task) The planning and presentation material needs to be made 510 available in advance of the session. 512 (Task) They and the reporting materials also need to be preserved 513 for later reference. 515 Details about IETF Meeting Materials are provided in [MeetMaterials], 516 [MeetMaterialTool]. 518 NOTE: The IETF web site has related information that appears to be 519 out of date, such as [AgendaNotes]. 521 3.5. Internet-Drafts (I-D) 523 Working group efforts are typically driven by specific documents. 524 Some are used to fuel working group discussion while others are the 525 deliverable product under development. Documents are processed as 526 Internet Drafts [I-D], which are strictly working documents and have 527 no official standards status whatsoever. They might, eventually, 528 turn into a standards-track document or they might sink from sight. 530 Formal adoption of Internet Drafts in a working group is discussed in 531 [RFC7221]. Also, there are naming conventions, to identify Internet 532 Drafts that have been adopted by a working group, as described in 533 Section 7 of [I-D-Guidelines]. 535 3.6. Request For Comments (RFC) 537 The work of an IETF working group typically targets publication of 538 one or more documents, as part of the Request For Comments (RFC) 539 series. ([RFC-IETF], [RFC-Editor], [RFC2026]) This series is the 540 archival publication record for the Internet community. There are 541 multiple, independent streams that produce documents published as 542 RFCs; the IETF stream is one of these. A document can be written by 543 an individual in a working group, by a group as a whole with a 544 designated Writer, or by others not involved with the IETF. The RFC 545 Editor provides guidance for writing an RFC. [RFC7322] 547 NOTE: The RFC series is a publication mechanism only and publication 548 does not determine the IETF status of a document. RFCs are processed 549 through a number of independent 'streams', of which those produced 550 with IETF approval represent one. The IETF status is determined 551 through separate, explicit status labels assigned by the IESG on 552 behalf of the IETF. In other words, the reader is reminded that all 553 Internet Standards are published as RFCs, but NOT all RFCs specify 554 standards. [RFC1796] 556 4. Working Group Internal Operation 558 4.1. Prime Directives 560 The IETF has basic requirements for open and fair participation and 561 for thorough consideration of technical alternatives. Within those 562 constraints, working groups are nearly autonomous and each determines 563 most of the details of its own operation with respect to 564 organization, planning, session participation, discussion style, 565 means of reaching closure, etc. 567 o The core rule for operation is that acceptance or agreement is 568 achieved via working group "rough consensus". (Section 2.8) 570 A number of procedural questions and issues will arise over time. 571 The Working Group Chair(s) have ultimate responsibility for 572 management of the group process, keeping in mind that the overall 573 purpose of the group is to make progress towards reaching rough 574 consensus in realizing the working group's goals and objectives. 576 There are few hard and fast rules on organizing or conducting working 577 group activities, but a set of guidelines and practices has evolved 578 over time that have proven successful. Some basic choices are listed 579 in (Section 6). These are discussed at length in the associated 580 wiki. (Appendix C) 582 (Task) Actual choices for the details of working group operation 583 are determined by the working group participants and the Chair(s). 585 For some working groups, this can be accomplished by having the Chair 586 perform all management-related activities. In other working groups 587 -- particularly those with large or divisive participation -- it is 588 helpful to allocate process and/or secretarial functions to other 589 participants. Process management pertains strictly to the style of 590 working group interaction and not to its content. It ensures 591 fairness and detects redundancy. The secretarial function 592 encompasses document editing. It is quite common for a working group 593 to assign the task of specification Writer to one or two 594 participants. Sometimes, they also are part of the design team, 595 described below. (Section 6) 597 Of course, each WG will have participants who might not be able (or 598 want) to do any work at all. Most of the time the bulk of the work 599 is done by a few dedicated participants. It is the task of the Chair 600 to motivate enough experts to allow for a fair distribution of the 601 workload and the necessary representation of Internet community 602 requirements. 604 4.2. General Organizing 606 Working groups sometimes develop and operate organically, needing 607 very little assertive management by the Chairs. Such groups are 608 nearly self-regulating and that is entirely acceptable, but it also 609 is rare. When a working group has to do simple tasks, and the 610 working group is cohesive and knowledgeable, there is little need for 611 much formality in working group management. Most working groups are 612 not so fortunate. For them, active management might be required, to 613 determine such things as the sequence of work, the design teams for 614 doing core work, issue-tracking, the approach for resolving issues, 615 and even discussion facilitation. 617 4.2.1. Characterizing the Effort 619 (Task) It can help to evaluate the work to be done and the 620 participation in the working group that will do it: 622 * Consider the community knowledge of the problem space 624 * Consider the plausible solution space, in terms of complexity 625 and clarity 627 * Consider the composition of the working group, in terms of 628 size, shared knowledge, interaction style, and focus on 629 achieving productive results 631 4.2.2. Plan of Work 633 Working groups typically produce more than one document. While there 634 might appear to be a natural sequence for developing them, consider 635 that some foundational documents that logically need to be done first 636 might also need to be revised later, as the working group gains more 637 experience with its topic(s). 639 (Task) Given a sequence of documents, what are the subordinate 640 steps that will achieve necessary milestones? It can help to 641 chart this explicitly in the working group Wiki. (Section 3.2) 643 4.2.3. Tasks vs. Roles 645 A working group requires significant administrative and management 646 work. What is flexible is who performs the work. The choices for 647 assigning one or more tasks to a participant filling a particular 648 role will depend upon the assessment of the Chair(s). For example, 649 as the scale or complexity or contentiousness of a working group 650 increases, so does its risk of failure and its attendant need for 651 more active and more formal management. 653 This typically means stricter adherence to formal rules of working 654 group process and assignment of various tasks to a wider set of 655 participants in specific roles, so that each task receiver proper 656 focus. Roles that are required or, at least, useful are discussed 657 later, in (Section 6). 659 4.2.4. Venues 661 Although the working group mailing list is intended to be the primary 662 venue for discussion and MUST be the ultimate venue for assessing 663 working group rough consensus, scheduled meetings can also be 664 important. (Some successful efforts have taken place only on mailing 665 lists, with no interactive meetings, but these are rare.) 667 Meetings can be face-to-face, such as during the thrice-annual IETF 668 Plenary Meeting, or "virtual" via teleconference or chat session. 669 Face-to-face meetings can (and often do) include provisions for 670 virtual participation to accommodate participants who cannot attend 671 in person. See: Section 4.6, Section 4.7, Section 4.6.4. 673 4.3. Discussion and Progress 675 The challenge to managing working group discussion is to balance the 676 need for open and fair consideration of the issues against the need 677 to make forward progress. The working group, as a whole, has the 678 final responsibility for striking this balance. 680 (Task) The Chair has the responsibility for overseeing the process 681 but MAY delegate direct process management to a formally- 682 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: 689 (Task) Main arguments in the discussion (and the outcome) are 690 summarized and archived after a discussion has come to conclusion. 692 It is also good practice to: 694 (Task) Note important decisions/consensus reached by email in the 695 notes of the next 'live' session, and to summarize briefly the 696 decision-making history in the final documents the WG produces. 698 (Task) To facilitate making forward progress, a working group MAY 699 decide to reject or defer the input from a participant, based upon 700 the following criteria: 702 Old: The input pertains to a topic that already has been 703 resolved and is redundant with information previously 704 available; 706 Minor: The input is new and pertains to a topic that has 707 already been resolved, but it is felt to be of minor import 708 to the existing decision; 710 Timing: The input pertains to a topic that the working group 711 has not yet opened for discussion; or Scope The input is 712 outside of the scope of the working group charter. 714 4.4. IETF Open Decision-Making 716 The IETF values and demands open, inclusive decision-making by 717 working groups. A process that is truly open and inclusive makes 718 participation as easy as possible, for the widest range of 719 participants as possible. 721 For the IETF, that means that the official venue for working group 722 formal decision-making MUST be the mailing list associated with 723 the group AND NOWHERE ELSE. 725 Working groups make decisions through a "rough consensus" process 726 (Section 2.8), which entails considerably more than merely 727 determining that a majority are for or against a particular choice. 728 IETF rough consensus does not require that all participants agree 729 although this is, of course, preferred. In general, the dominant 730 view of the working group needs to prevail, absent compelling 731 arguments against. In particular note the role of "minority" views, 732 as discussed in [RFC7282]. 734 It can be especially challenging to gauge the level of consensus on a 735 mailing list. There are two different cases where a working group 736 might be trying to understand the level of consensus via a mailing 737 list discussion. But in both cases the volume of messages on a topic 738 is not, by itself, a good indicator of consensus since one or two 739 individuals might be generating much of the traffic. 741 (Task) Enough time MUST be given to the verification process for 742 the mailing list readers to understand and consider any objections 743 that might be raised on the list. The normal two week last-call 744 period SHOULD be sufficient for this. 746 4.5. Mailing List Primacy 748 Discussions relating to working group topics MAY happen anywhere, 749 amongst any group of people, on a spontaneous or continuing basis and 750 as a closed or open set. Closed groups that persist with a 751 continuing role in providing substantive input to the working group's 752 content are called 'design teams'. They can be self-forming or 753 created by the Chair(s). 755 The working group, itself, can provide a variety of open discussion 756 venues, over the life of the working group, as discussed below. 757 However discussions are conducted, "decisions" made at venues other 758 than the working group mailing list MUST be treated as preliminary, 759 and MUST be explicitly documented and confirmed through the mailing 760 list. 762 An example method is to post a note summarizing: 764 o the discussion 766 o the proposed resolution 768 o the rationale for proposing its adoption 770 This provides working group participants with enough foundational 771 material to understand the proposal and comment on it or even support 772 it. It also creates a record on the official email archive. 774 If discussion is held entirely over the mailing list, determination 775 of the level of consensus might be harder to do, since most people 776 subscribed to mailing lists do not actively participate in 777 discussions. It is left to the discretion of the working group chair 778 how to evaluate the level of consensus. The most common method used 779 is for the working group chair to state what they believe to be the 780 consensus view and at the same time, request comments from the list 781 about the stated conclusion. 783 4.6. Discussion Venues 785 Each working group will determine the balance of email versus 786 interactive (face-to-face, online, ...) sessions that is appropriate 787 for achieving its milestones. Electronic mail permits the widest 788 participation; interactive, real-time meetings often permit better 789 focus and therefore can be more efficient for reaching a consensus 790 among a core of the working group participants. In determining the 791 balance, the WG MUST ensure that its process does not serve to 792 exclude contribution by email-only participants. 794 (Task) Remember that consensus reached during an interactive MUST 795 be reviewed on the mailing list. 797 4.6.1. Tradeoffs 799 Each working group will determine the balance of email versus 800 interactive (face-to-face, online, ...) sessions that is appropriate 801 for achieving its milestones. The choices are affected by various 802 factors, including the working group's milestone schedule -- that is, 803 degree of urgency -- complexity of the work, number of active 804 discussants, and the schedule and support of those discussants. 806 However there tends to be a significant tradeoff between doing work 807 at interactive sessions, versus working group inclusiveness. 809 Interactive sessions demand that a participant's schedule permit 810 availability during the sessions. Even when held online, this can be 811 a significant burden for some participants. Even if their formal 812 schedule is sufficiently flexible, the fact of different participant 813 timezones tends to work to the disadvantage of some participants. 815 If the meetings are face-to-face, the schedule and monetary demands 816 are dramatically higher and, obviously, further restrict 817 participation. 819 A mailing list venue permits the widest and most-convenient 820 participation, by allowing for time-shifted debate among participants 821 in multiple time zones. Its asynchrony also permits the most 822 thoughtful presentation of views and the most thoughtful 823 consideration of them. 825 Interactive, real-time meetings often provide richer and higher speed 826 communication with lower latency and therefore permit better focus. 827 They therefore can be more efficient for reaching a consensus among a 828 core of the working group participants, especially for narrow and 829 contested choices. 831 Any tools that permit real-time, or time-shifted, interaction and 832 information exchange could be used, without affecting the basic 833 principle that decisions are exposed and confirmed on the mailing 834 list -- Facebook, Twitter, github, issue tracker, etc. Note that 835 these do not provide a formal, IETF archive of the activity, although 836 their record can be useful to cite. 838 The mode of interaction can (and probably ought) be different in 839 different situations. Regardless, the choice of operational style 840 MUST be made through rough consensus of all working group mailing 841 list participants. In determining the balance, the working group 842 MUST ensure that its process does not serve to exclude substantive 843 contribution by email-only participants. 845 A basic principle is that although face-to-face discussion, either 846 during a plenary week or at an interim meeting, might sometimes be 847 considered essential to make rapid progress or to resolve tricky 848 issues, this MUST NOT be discriminatory against those unable to 849 attend. As far as technically and financially possible, facilities 850 for passive and active remote participation SHOULD be provided. 852 Similarly, "virtual" interim meetings in which all participants are 853 remote MUST NOT be discriminatory against those unable to attend. 855 The choice of operational style MUST be made by the working group 856 itself. 858 Again: consensus reached during an interactive session is purely 859 preliminary. The proposed decision and its basis MUST be reviewed 860 on the mailing list, and rough consensus developed and documented 861 there. 863 4.6.2. Mailing List Discussion Management 865 It can be quite useful to conduct email exchanges in the same manner 866 as an interactive session, with published schedule and agenda, as 867 well as on-going summarization and consensus polling, even though 868 message-posting and responding continues to be asynchronous amongst 869 participants. 871 WG chairs should guide WG email debate when necessary, for example by 872 encouraging participants to stay on topic, remain polite, avoid 873 repetition, etc. It is helpful to encourage distinct threads with 874 meaningful subject headers for distinct topics. 876 As with face-to-face sessions occasionally a participant might engage 877 in behavior on a mailing list which disrupts the WG's progress. 879 (Task) In these cases the Chair SHOULD attempt to discourage the 880 behavior by communication directly with the offending individual 881 rather than on the open mailing list. If the behavior persists 882 then the Chair MUST involve the Area Director in the issue. 884 (Task) As a last resort and after explicit warnings, the Area 885 Director, with the approval of the IESG, MAY request that the 886 mailing list maintainer block the ability of the offending 887 individual to post to the mailing list. (If the mailing list 888 software permits this type of operation.) Even if this is done, 889 the individual MUST NOT be prevented from receiving messages 890 posted to the list. 892 Other methods of mailing list control MAY be considered but MUST be 893 approved by the AD(s) and the IESG. 895 4.6.3. IETF Plenary Meetings 897 If a WG needs a session at an IETF meeting, the Chair MUST apply for 898 time-slots as soon as the first announcement of that IETF meeting is 899 made by the IETF Secretariat to the WG-chairs list. Session time is 900 a scarce resource at IETF meetings, so placing requests early will 901 facilitate schedule coordination for WGs requiring the same set of 902 experts. 904 (Task) Some Area Directors MAY want to coordinate WG sessions in 905 their area and request that time slots be coordinated through 906 them. If this is the case it will be noted in the IETF meeting 907 announcement. 909 (Task) Requirements and procedures for obtaining a session slot 910 at an IETF Meeting are specified in [MeetRequest]. 912 NOTE: While open discussion and contribution is essential to working 913 group success, the Chair is responsible for ensuring forward 914 progress. When acceptable to the WG, the Chair MAY call for 915 restricted participation (but not restricted attendance!) at IETF 916 working group sessions for the purpose of achieving progress. 918 (Task) The Working Group Chair has the authority to refuse to 919 grant the floor to any individual who is unprepared, is covering 920 inappropriate material, or who in the opinion of the Chair is 921 disrupting the WG process. 923 The Chair SHOULD consult with the Area Director(s) if the individual 924 persists in disruptive behavior. 926 4.6.4. Interim Meetings 928 In addition to mailing list discussion and meeting at the thrice- 929 yearly IETF Meetings, a working group might decide that it should 930 hold an additional, real-time "interim" meeting. This might be 931 through a real-time chat session, group telephone call, online 932 teleconference, or physical, face-to-face meeting. 934 Guidance for the conduct of such sessions is provided by [Interim], 935 with useful tutorial material at [Interim-Train]. Also see: 936 Section 4.7. 938 4.7. Session Planning 940 Administrative and process details for the conduct of structured 941 meetings are referenced at [IETF-Meetings] and in [Interim] 943 (Task) Sessions MUST be planned, organized and announced well in 944 advance. 946 (Task) For coordinated, structured WG interactions, a draft agenda 947 SHOULD be published well in advance of the actual session. 949 Details about Meeting Materials are provided in [MeetMaterials], 950 [MeetMaterialTool]. 952 4.8. Meeting Drafts and Documents 954 NOTE: The requirements here apply to all IETF working group 955 meetings, independent of venue or mode. That is, all official 956 sessions during an IETF Week and all interims. 958 (Task) All relevant documents to be discussed at a session SHOULD 959 be published and available as Internet-Drafts at least two weeks 960 before a session starts, so that working group participants have 961 adequate time to review all documents. 963 4.9. Meeting Record Keeping 965 NOTE: The requirements here apply to all IETF working group 966 meetings, independent of venue or mode. That is, all official 967 sessions during an IETF Week and all interims. 969 The task(s) of creating records about meeting activity are discussed 970 in [AgendaNotes], above. 972 (Task) An attendance list MUST be circulated 974 (Task) Notes of a session MUST be taken; they SHOULD include the 975 agenda for the session, an account of the discussion including any 976 decisions made, and a list of attendees 978 (Task) Immediately after a session, the WG Chair SHOULD provide 979 the Area Director with a very short report (approximately one 980 paragraph, via email) on the session. 982 5. Document Development & Lifecycle 984 Working groups produce documents and documents need Writers. 986 (Task) The Chair MUST make sure that Document Writers incorporate 987 changes as agreed to by the WG. 989 It is quite easy for active and productive writers to move into a 990 dominant position, either making changes faster than the working 991 group can absorb, or becoming adversarial with working group 992 preferences. An especially conducive environment for this problem 993 combines original (pre-working group) authors with a more passive 994 working group. However a working group that does not fully and 995 actively support a specification, the greater the risk that it will 996 not achieve deployment and use. 998 5.1. Basic Sequence 1000 Working group development of a document proceeds through these steps: 1002 1. An individual or a group has something for the WG to discuss and 1003 publishes a document on the topic as an individual I-D 1005 2. WG adopts the document as a WG work item, per section 2 of 1006 [RFC7221] 1008 3. WG develops the document, per [RFC7221] 1010 4. When the WG is done with development, the chairs organize a WG 1011 last call to determine consensus for sending the I-D to the IESG 1012 for review and publication 1014 5. Chairs assign a document shepherd who prepares the cover sheet 1015 and assumes responsibility for managing the review and 1016 publication process 1018 6. The Working Group, through the chairs or the shepherd, make a 1019 recommendation to the to the Area Director that a standards 1020 action be approved regarding the document [RFC 2026] 1022 7. Area Director reviews the document to determine if the standards 1023 action should proceed; this review may include an external 1024 review, per [RFC2026] 1026 8. Area Director formally requests an IETF Last Call to determine 1027 IETF consensus about whether the I-D is ready for publication, 1028 per [RFC2026] 1030 9. Once the IETF Last Call is complete, the AD, the document 1031 shepherd, the editors and the WG agree on any changes to the I-D 1032 based on the Last Call comments 1034 10. The AD schedules the I-D for discussion during an IESG telechat 1036 11. Prior to the telechat, IESG members post a ballot position on 1037 the I-D 1039 12. After the telechat, the I-D may require additional revision; the 1040 IESG, the document shepherd, the editors and the WG agree on any 1041 changes to the I-D based on the IESG ballot positions and 1042 telechat discussion 1044 13. Once the I-D meets the IESG ballot requirements for publication, 1045 the IETF is notified of any associated standards action and the 1046 document is forwarded to the RFC Editor 1048 5.2. Early Document Review 1050 It is easier to make substantial changes to a specification during 1051 its early stages than it is later on. Periodically, the IETF's 1052 various late-stage reviews uncover basic concerns with assumptions or 1053 approaches in a design. When a working group is pursuing a solution 1054 that has unusual design choices or unusual operational 1055 characteristics, or has any other feature that might impede its 1056 success, or when the working group participants have less experience 1057 in producing specifications for Internet-scale use, it is advisable 1058 to recruit review and advice from a broad base of experts. 1060 5.3. Document Coordination Between Working Groups 1062 A document is adopted by one working group as a deliverable; they are 1063 therefore responsible for its development, review and publication. 1064 (Section 3.5) When initiated outside a working group environment, the 1065 writer(s) usually have a specific -- possibly new -- working group in 1066 mind as the development home. However some documents address 1067 problems or contain technologies that span multiple Areas or working 1068 groups. In such cases, the document is assigned to one of these, 1069 with other interested groups participating in the development 1070 process. This joint participation can take many forms. One example 1071 is a joint Working Group Last Call conducted by the host group but 1072 announced on the mailing lists for the other interested groups. 1074 As an example, documents that extend DHCP to carry configuration 1075 information for other protocols often span multiple working groups. 1076 Some of these documents define a simple DHCP option that follows one 1077 of the option formats in section 5 of [RFC7227]. Such options can be 1078 developed in the working group responsible for the protocol that will 1079 use the option, without significant participation of the dhc working 1080 group. A joint last call between the two groups might be all that is 1081 required. However some documents will define options that have a 1082 significantly new option format, or define a new DHCP message or 1083 otherwise make a fundamental change to the semantics of DHCP message 1084 exchanges. These options or new messages will be developed in the 1085 dhc working group, with input from other interested groups, to ensure 1086 that there are no conflicts or other issues with the documents that 1087 would cause problems with the DHCP standards. 1089 5.4. Working Group Last-Call 1091 When a WG decides that a document is ready for publication it is 1092 submitted to the IESG for consideration. In most cases the 1093 determination that a WG feels that a document is ready for 1094 publication is done by the WG Chair issuing a working group Last- 1095 Call. The decision to issue a working group Last-Call is at the 1096 discretion of the WG Chair working with the Area Director. A working 1097 group Last-Call serves the same purpose within a working group that 1098 an IESG Last-Call does in the broader IETF community. ([RFC2026]) 1100 5.5. Final External Review of Documents 1102 The IESG reviews all documents submitted for publication as RFCs. 1103 Usually minimal IESG review is necessary in the case of a submission 1104 from a WG intended as an Informational or Experimental RFC. More 1105 extensive review is undertaken in the case of standards-track 1106 documents. 1108 Prior to the IESG beginning their deliberations on standards-track 1109 documents, IETF Secretariat will issue a "Last-Call" to the IETF 1110 mailing list. ([RFC2026]) This Last Call will announce the intention 1111 of the IESG to consider the document, and it will solicit final 1112 comments from the IETF within a period of two weeks. It is important 1113 to note that a Last-Call is intended as a brief, final check with the 1114 Internet community, to make sure that no important concerns have been 1115 missed or misunderstood. The Last-Call should not serve as a more 1116 general, in-depth review. 1118 The IESG review takes into account responses to the Last-Call and 1119 will lead to one of these possible conclusions: 1121 1. The document is accepted as is for the status requested. This 1122 fact will be announced by the IETF Secretariat to the IETF 1123 mailing list and to the RFC Editor. 1125 2. The document is accepted as-is but not for the status requested. 1126 This fact will be announced by the IETF Secretariat to the IETF 1127 mailing list and to the RFC Editor. (See [RFC2026] for more 1128 details.) 1130 3. Changes regarding content are suggested to the Writer(s)/WG. 1131 Suggestions from the IESG need to be clear and direct, so as to 1132 facilitate working group and Writer correction of the 1133 specification. If the Writer(s)/WG can explain to the 1134 satisfaction of the IESG why the changes are not necessary, the 1135 document will be accepted for publication as under point 1, 1136 above. If the changes are made the revised document MAY be 1137 resubmitted for IESG review. 1139 4. Changes are suggested by the IESG and a change in status is 1140 recommended. The process described above for 3 and 2 are 1141 followed in that order. 1143 5. The document is rejected. Any document rejection will be 1144 accompanied by specific and thorough arguments from the IESG. 1145 Although the IETF and working group process is structured such 1146 that this alternative is not likely to arise for documents coming 1147 from a working group, the IESG has the right and responsibility 1148 to reject documents that the IESG feels are fatally flawed in 1149 some way. 1151 If any individual or group of individuals feels that the review 1152 treatment has been unfair, there is the opportunity to make a 1153 procedural complaint. The mechanism for this type of complaints is 1154 described in [RFC2026]. 1156 6. Staff Roles 1158 From initial chartering, through document development and 1159 publication, ending with working group termination, there are tasks 1160 that are formally required to be done, while others are merely -- 1161 though often very -- helpful to do. This document discusses the 1162 formal tasks and many of the other, useful tasks. 1164 Working groups require considerable care and feeding. In addition to 1165 general participation, successful working groups benefit from the 1166 efforts of participants filling specific functional roles. 1168 Beyond a limited set of formal tasks, there are no rules about who 1169 MAY be assigned tasks internal to the working group. This section 1170 discusses possible mappings between working group tasks and working 1171 group participants who might be assigned roles for performing those 1172 tasks. However it is important to remember that such mappings are 1173 strictly at the discretion of the chairs, assuming working group 1174 agreement. 1176 [RFC2028] describes the roles of a number of individuals related to 1177 external aspects of working groups, as well including the working 1178 group chair and the document Writer. These descriptions are expanded 1179 later in this section. 1181 6.1. Development 1183 Document Writer: This role is discussed in Section 2.6. 1185 Design Team: It is often useful, and perhaps inevitable, for a 1186 sub-group of a working group to develop a proposal to solve a 1187 particular problem. Such a sub-group is called a design team. In 1188 order for a design team to remain small and agile, it is 1189 acceptable to have closed membership and private meetings. 1190 Operationally, a design team typically is advisory to the Document 1191 Writer(s), specifically, or the working group discussion, 1192 generally. Design teams can range from an informal chat between 1193 people in a hallway to a formal set of expert volunteers that the 1194 WG chair appoints to attack a controversial problem. The output 1195 of a design team always MUST be subject to approval, rejection or 1196 modification by the WG as a whole. 1198 Participant: Discuss issues. Suggest ideas and text. Review 1199 documents. Actively pursue resolution of topics. 1201 6.2. Advice 1203 Adviser (WG Consultant): At the discretion of the Area Director or 1204 Chair, an Adviser MAY be assigned to a working group. Consultants 1205 have specific technical background appropriate to the WG and 1206 experience in Internet architecture and IETF process. An 1207 adviser's role is strictly advisory rather than authoritative. 1208 However of course their concerns are likely to gain the attention 1209 of reviewers, the Area Director and the IESG. 1211 6.3. Process 1213 Area Director: This role is discussed in Section 2.4. 1215 Working Group Chair: This role is discussed in Section 2.5. 1217 WG Facilitator: When meetings tend to become distracted or 1218 divisive, it often is helpful to assign the task of "process 1219 management" to one participant. [Facilitate] Their job is to 1220 oversee the nature, rather than the content, of participant 1221 interactions. That is, they attend to the style of the discussion 1222 and to the schedule of the agenda, rather than making direct 1223 technical contributions themselves. 1225 WG Secretary: Taking notes, producing discussion summaries, and 1226 maintaining a list of working group action items are tasks often 1227 is performed by one or more designated participants. 1229 Scribe: A Scribe is tasked with note-taking during a meeting. 1230 This might be for real-time use during the session, such as 1231 providing quick summaries of on-going discussion via an instant- 1232 messaging channel, to assist remote participants. Or it might be 1233 basic meeting notes; these are typically summarizations of 1234 discussions, rather than detailed 'minutes'. [I-D-Jscribe] 1236 7. WG External Administration 1238 7.1. Working group Formation 1240 IETF working groups (WGs) are the primary means of developing IETF 1241 specifications and guidelines, many of which are intended to be 1242 standards or recommendations. Working groups are typically created 1243 to address a specific problem or to produce one or more specific 1244 deliverables (a guideline, standards specification, etc.). Working 1245 groups are generally expected to be short-lived in nature. 1247 A working group is typically created by a community initiative, but 1248 can also be established at the initiative of an Area Director. 1249 Anyone interested in creating an IETF working group MUST obtain the 1250 advice and consent of IETF Area Director(s) and MUST proceed through 1251 the formal steps detailed in this section. 1253 7.1.1. Criteria for formation 1255 When determining whether it is appropriate to create a working group, 1256 the Area Director(s) and the IESG will consider several issues: 1258 Issues: Are the issues that the working group plans to address 1259 clear and relevant to the Internet community? 1261 Goals: Are the goals specific and reasonably achievable, and 1262 achievable within a reasonable time frame? 1264 Risks/Urgency: What are the risks and urgency of the work, to 1265 determine the level of effort required? 1267 WG Overlap: Do the working group's activities overlap with those 1268 of another working group? If so, it can still be appropriate to 1269 create the working group, but this question needs to be considered 1270 carefully by the Area Directors as subdividing efforts often 1271 dilutes the available technical expertise. 1273 Interest: Is there sufficient interest within the IETF in the 1274 working group's topic with enough people willing to expend the 1275 effort to produce the desired result (e.g., a protocol 1276 specification)? Working groups require considerable effort, 1277 including management of the working group process, editing of 1278 working group documents, and contributing to the document text. 1279 IETF experience suggests that these roles typically cannot all be 1280 handled by one person; a minimum of four or five active 1281 participants in the management positions are typically required in 1282 addition to a minimum of one or two dozen people that will attend 1283 the working group meetings and contribute on the mailing list. 1284 NOTE: The interest needs to be broad enough that a working group 1285 would not be seen as merely the activity of a single vendor. 1287 Expertise: Is there enough expertise within the IETF in the 1288 working group's topic, and are those people interested in 1289 contributing in the working group? 1291 Market: Does a base of interested consumers (end-users) appear to 1292 exist for the planned work? Consumer interest can be measured by 1293 participation of end-users within the IETF process, as well as by 1294 less direct means. 1296 IETF Relevance: Does the IETF have a reasonable role to play in 1297 the determination of the technology? There are many Internet- 1298 related technologies that might be interesting to IETF 1299 participants but in some cases the IETF might not be in a position 1300 to effect the course of the technology in the "real world". This 1301 can happen, for example, if the technology is being developed by 1302 another standards body or an industry consortium. 1304 IPR: Are all known intellectual property rights relevant to the 1305 proposed working group's efforts issues understood? 1307 Real IETF Work: Is the proposed work plan an open IETF effort or 1308 is it an attempt to "bless" non-IETF technology where the effect 1309 of input from IETF participants might be limited? 1311 Existing Work: Is there a good understanding of any existing work 1312 that is relevant to the topics that the proposed working group is 1313 to pursue? This includes work within the IETF and elsewhere. 1315 SDO Overlap: Do the working group's goals overlap with known work 1316 in another standards body, and if so is adequate liaison in place? 1318 Considering the above criteria, the Area Director(s) will use their 1319 best judgment to decide whether to pursue formation of the group 1320 through the chartering process. 1322 7.1.2. Birds of a Feather (BOF) 1324 Often it is not clear whether an issue merits the formation of a 1325 working group. To facilitate exploration of the issues the IETF 1326 offers the possibility of a Birds of a Feather (BOF) session 1327 ([RFC5434]) as well as the early formation of an email list for 1328 preliminary discussion. In addition, a BOF can serve as a forum for 1329 a single presentation or discussion, without any intent to form a 1330 working group. 1332 A BOF is a session at an IETF meeting which permits "market research" 1333 and technical "brainstorming". Any individual MAY request permission 1334 to hold a BOF on a subject. The request MUST be filed with a 1335 relevant Area Director, and their approval MUST be obtained before a 1336 BOF can be scheduled. The person who requests the BOF MAY be asked 1337 to serve as Chair of the BOF. 1339 The Chair of the BOF is also responsible for providing a report on 1340 the outcome of the BOF. If the Area Director approves, the BOF is 1341 then scheduled by submitting a request to agenda@ietf.org with copies 1342 to the Area Director(s). A BOF description and agenda are required 1343 before a BOF can be scheduled. 1345 Available time for BOFs is limited, and BOFs are held at the 1346 discretion of the ADs for an area. The AD(s) MAY require additional 1347 assurances before authorizing a BOF. For example, 1349 o The Area Director MAY require the establishment of an open email 1350 list prior to authorizing a BOF. This permits initial exchanges 1351 and sharing of framework, vocabulary and approaches, in order to 1352 make the time spent in the BOF more productive. 1354 o The Area Director MAY require that there be a draft of the WG 1355 charter prior to holding a BOF. 1357 o The Area Director MAY require that a BOF not be held until an 1358 Internet-Draft describing the proposed technology has been issued 1359 so it can be used as a basis for discussion in the BOF. 1361 In general, a BOF on a particular topic is held only once -- ONE slot 1362 at one IETF Plenary meeting. Under unusual circumstances Area 1363 Directors MAY, at their discretion, allow a BOF to meet for a second 1364 time. BOFs are limited to a maximum of two meetings. Note that all 1365 other things being equal, WGs will be given priority for meeting 1366 space over BOFs. Also, occasionally BOFs might be held for other 1367 purposes than to discuss formation of a working group. 1369 Usually the outcome of a BOF will be one of the following: 1371 o There was enough interest and focus in the subject to warrant the 1372 formation of a WG 1374 o While there was a reasonable level of interest expressed in the 1375 BOF some other criteria for working group formation was not met, 1376 per Section 7.1.1 1378 o The discussion came to a fruitful conclusion, with results to be 1379 written down and published, however there is no need to establish 1380 a WG 1382 o There was not enough interest in the subject to warrant the 1383 formation of a WG 1385 7.1.3. Charter Development 1387 The formation of a working group requires a charter. Development of 1388 a charter results from the efforts of interested parties and an Area 1389 Director. The substance of IETF working group charters is specified 1390 in Section 7.2. The development of the proposed charter is overseen 1391 by a shepherding Area Director and can be pursued in a number of 1392 ways. 1394 The method of developing a charter can vary greatly. In many 1395 instances, the development of the charter is carried out on an open 1396 mailing list, allowing all interested IETF participants to contribute 1397 to the effort. Among other possibilities, charter development might 1398 driven by a small group of active proponents. All charter 1399 development models allow for interested participants to take 1400 ownership in the purpose and outcome of the working group. 1402 It is common, but not required, to hold an exploratory Birds of a 1403 Feather (BOF) meeting to gauge the level of support for a working 1404 group.([RFC5434],Section 7.1.2) Such a BOF can focus on formulating 1405 the problem to be solved, considering the key items in a proposed 1406 charter, discussing proposed solutions, or some combination of these 1407 items. 1409 When the prospective Chair(s), the Area Director and the IETF 1410 Secretariat are satisfied with the charter form and content, it 1411 becomes the foundation of the working group approval process and for 1412 the substantive conduct of the working group. 1414 7.1.4. Charter review & approval 1416 Proposed working groups often include technically competent 1417 participants who are not familiar with the history of Internet 1418 architecture or IETF processes. This can, unfortunately, lead to 1419 good working group consensus about a bad design. 1421 (Task) To facilitate working group efforts, an Area Director MAY 1422 assign a Adviser from among the ranks of IETF participants. 1423 (Section 6) 1425 At the discretion of the Area Director, approval of a new WG MAY be 1426 withheld in the absence of sufficient Adviser resources. 1428 For review of a draft charter, the sponsoring Area Director might 1429 consult with their Area Directorate, or others, as deemed 1430 appropriate. Once an Area Director supports a version of the working 1431 group charter, the approval sequence then is: 1433 1. In parallel: 1435 * The charter is submitted for review by the IAB 1437 * It is also submitted for approval by the IESG. 1439 2. After a review period of at least a week, in parallel: 1441 * the proposed charter is posted to the IETF-announce mailing 1442 list as a public notice that the formation of the working 1443 group is being considered. 1445 * the proposed charter is also posted to the "new-work" mailing 1446 list. This mailing list has been created to let qualified 1447 representatives from other standards organizations know about 1448 pending IETF working groups. 1450 3. After another review period lasting at least a week the IESG MAY 1451 approve the charter as-is, or it MAY request that changes be made 1452 in the charter, or MAY decline to approve chartering of the 1453 working group 1455 If the IESG approves the formation of the working group it remands 1456 the approved charter to the IETF Secretariat who records and enters 1457 the information into the IETF tracking database. The working group 1458 is announced to the IETF-announce a by the IETF Secretariat. 1460 7.1.5. Milestones Revision 1462 The milestone list is expected to be updated periodically. Updated 1463 milestones are (re-)negotiated with the Area Director, as needed, and 1464 then are submitted to the IESG Secretariat: 1466 iesg-secretary@ietf.org 1468 7.1.6. Rechartering a Working Group 1470 Charters MAY be renegotiated periodically to reflect the current 1471 status, organization or goals of the working group. 1473 Rechartering a working group follows the same procedures that the 1474 initial chartering does Section 7.1. 1476 7.2. Charter Content 1478 Charter development and approval, rechartering, and milestone 1479 revision are discussed in Section 7.1. 1481 Examples working group charters are shown in Appendix B 1483 A charter consists of the following sections: 1485 Working group name: A working group name ought to be reasonably 1486 descriptive or identifiable. Additionally, the group needs to 1487 define an acronym (maximum 8 printable ASCII characters) to 1488 reference the group in the IETF directories, mailing lists, and 1489 general documents. 1491 Chair(s): The working group can have one or more Chairs to perform 1492 the administrative functions of the group. The email address(es) 1493 of the Chair(s) are included. Generally, a working group is 1494 limited to two chairs. 1496 (Optional) Other Staff: Optional positions, such as secretary and 1497 technical adviser. 1499 Area Director(s): The name of the IETF area with which the working 1500 group is affiliated and the name and electronic mail address of 1501 the associated Area Director(s). 1503 Responsible Area: Director The Area Director who acts as the 1504 primary IESG contact for the working group. 1506 Mailing list: An IETF working group MUST have a general Internet 1507 mailing list. The working group charter MUST include: 1509 * The address to which a participant sends a subscription request 1510 and the procedures to follow when subscribing, 1512 * The address to which a participant sends submissions and 1513 special procedures, if any, and 1515 * The location of the mailing list archive. 1517 For basic IETF requirements concerning mailing list configuration 1518 and use. (Section 2.3) 1520 Description of working group: The focus and intent of the group is 1521 set forth briefly. By reading this section alone, an individual 1522 should be able to decide whether this group is relevant to their 1523 own work. 1525 To facilitate evaluation of the intended work and to provide on- 1526 going guidance to the working group, the charter MUST describe the 1527 problem being solved and SHOULD discuss objectives and expected 1528 impact with respect to: 1530 * Architecture 1532 * Operations 1534 * Security 1536 * Network management 1538 * Scaling 1540 * Transition (where applicable) 1542 Goals and milestones: The working group charter MUST establish a 1543 timetable for specific work items. While this MAY be renegotiated 1544 over time, the list of milestones and dates facilitates the Area 1545 Director's tracking of working group progress and status, and it 1546 is indispensable to potential participants identifying the 1547 critical moments for input. 1549 Milestones MUST consist of deliverables that can be qualified as 1550 showing specific achievement; e.g., "Internet-Draft finished" is 1551 fine, but "discuss via email" is not. 1553 It is helpful to specify milestones for every 3-6 months, so that 1554 progress can be gauged easily. 1556 7.3. Submission & Publication of Documents 1558 Once a WG has determined that rough consensus exists within the WG 1559 for the advancement of a document, the following MUST be done: 1561 (Task) The version of the relevant document exactly as agreed to 1562 by the WG MUST be in the Internet-Drafts directory, formatted 1563 according to Section 3.6 1565 (Task) The WG Chair MUST initiate a publication request through 1566 the Datatracker entry for the document 1568 The copy of the message to the IESG Secretariat is to ensure that the 1569 request gets recorded by the Secretariat so that they can monitor the 1570 progress of the document through the process. 1572 Unless returned by the IESG to the WG for further development, 1573 progressing of the document is then the responsibility of the IESG. 1575 After IESG approval, responsibility for final disposition is the 1576 joint responsibility of the RFC Editor, the WG Chair and the Document 1577 Writer. 1579 The Chair and/or Document Editor will work with the RFC Editor to 1580 ensure document conformance with RFC publication requirements 1581 [RFC2223] and to coordinate any editorial changes suggested by the 1582 RFC Editor. A particular concern is that all participants are 1583 working from the same version of a document at the same time. 1585 7.4. Working Group Termination 1587 Working groups are typically chartered to accomplish a specific task 1588 or tasks. Upon completion of its goals and achievement of its 1589 objectives, the working group is usually terminated. (A working 1590 group MAY also be terminated for other reasons, as discussed in 1591 Section 7.4.> 1593 If there is sufficient community interest the working group will 1594 formally become dormant rather than be disbanded -- the WG will no 1595 longer conduct formal activities -- so that the mailing list will 1596 remain available to review activities related to the working group's 1597 topic, including use and issues with documents it has produced. 1599 If, at some point, it becomes evident that a working group is unable 1600 to complete the work outlined in the charter, or if the assumptions 1601 which that work was based have been modified in discussion or by 1602 experience, the Area Director, in consultation with the working group 1603 can either: 1605 o Recharter to refocus its tasks (See Section 7.1.6) 1607 o Choose new Chair(s) 1608 o Disband 1610 If the working group disagrees with the Area Director's choice, it 1611 MAY appeal to the IESG. Section 7.5 1613 7.5. Contention and appeals 1615 Disputes are possible at various stages during the IETF process. As 1616 much as possible the process is designed so that compromises can be 1617 made, and genuine consensus achieved; however, there are times when 1618 even the most reasonable and knowledgeable people are unable to 1619 agree. To achieve the goals of openness and fairness, resolution of 1620 such conflicts MUST be pursued through a process of open review and 1621 discussion. 1623 Formal procedures for requesting a review of WG, Chair, Area Director 1624 or IESG actions and conducting appeals are documented in The Internet 1625 Standards Process [RFC2026]. 1627 8. Security Considerations 1629 9. References 1631 9.1. References - Normative 1633 [AgendaNotes] 1634 "Formatting and Content of IETF Working Group Agendas and 1635 Minutes", 1636 . 1638 [IETF-Meetings] 1639 "IETF Meetings", . 1641 [Interim] "Interim Meetings", 1642 . 1644 [MeetMaterials] 1645 "Meeting Materials", 1646 . 1648 [MeetMaterialTool] 1649 "The IETF Meeting Materials Management Tool", 1650 . 1653 [MeetRequest] 1654 "Requesting Meeting Sessions at IETF Meetings", 1655 . 1658 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1659 3", BCP 9, RFC 2026, October 1996. 1661 [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol 1662 (IPP): Event Notifications and Subscriptions", RFC 3995, 1663 March 2005. 1665 9.2. References - Informative 1667 [About] "About the IETF", . 1669 [AD-Desc] "Area Director Qualifications", 1670 . 1673 [Areas] "Areas", . 1675 [ChairGuide] 1676 "WG Chairs' Guide, 1677 http://wiki.tools.ietf.org/group/wgchairs/", 1678 . 1680 [Facilitate] 1681 "Facilitation", . 1684 [I-D] "Internet-Drafts (I-Ds)", . 1686 [I-D-Guidelines] 1687 Russ, R., "Guidelines to Authors of Internet-Drafts", 1688 December 2010, . 1691 [I-D-Jscribe] 1692 "The Jabber Scribe Role at IETF Meetings", I-D draft- 1693 saintandre-jabber-scribe. 1695 [Interim-Train] 1696 Atlas, A., Schliesser, B., and S. Turner, "Routing Area 1697 Chair Training: Interim Meetings", January 2015, 1698 . 1701 [MailList] 1702 "Email Lists", . 1704 [RFC-Editor] 1705 "RFC Editor", . 1707 [RFC-IETF] 1708 "Request for Comments (RFC)", 1709 . 1711 [RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines 1712 and Procedures", RFC 1603, March 1994. 1714 [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are 1715 Standards", RFC 1796, April 1995. 1717 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 1718 the IETF Standards Process", BCP 11, RFC 2028, October 1719 1996. 1721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1722 Requirement Levels", BCP 14, RFC 2119, March 1997. 1724 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 1725 RFC 2223, October 1997. 1727 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 1728 Procedures", BCP 25, RFC 2418, September 1998. 1730 [RFC5434] Narten, T., "Considerations for Having a Successful Birds- 1731 of-a-Feather (BOF) Session", RFC 5434, February 2009. 1733 [RFC7221] Farrel, A. and D. Crocker, "Handling of Internet-Drafts by 1734 IETF Working Groups", RFC 7221, April 2014. 1736 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1737 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1738 BCP 187, RFC 7227, May 2014. 1740 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", 1741 RFC 7282, June 2014. 1743 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 1744 September 2014. 1746 [Secretaries] 1747 Vigoureux, M. and D. King, "IETF Working Groups' 1748 Secretaries", I-D draft-secretaries-good-practices, 1749 November 2014. 1751 [Tao] "The Tao of IETF: A Novice's Guide to the Internet 1752 Engineering Task Force", . 1754 [WG] "Working Groups", . 1756 Appendix A. Acknowledgements 1758 The original version of this document was developed by Erik Huizer 1759 and Dave Crocker. ([RFC1603]) A revised version was edited by Scott 1760 Bradner and reviewed by the Poisson Working Group. ([RFC2418]) The 1761 current version was prompted by [Secretaries] and the vigorous IETF 1762 discussion that ensued. In their typical fashion, the IETF 1763 Secretariat staff were extremely helpful in clarifying current IETF 1764 administrative practices and rules. 1766 Development of the initial version of this document's revision 1767 benefited greatly from thoughtful and diligent comments by: Fred 1768 Baker, Brian Carpenter, Brian Haberman, Melinda Shore. 1770 Appendix B. Sample Working Group Charters 1772 NOTE: Can we get a better example? This example does not 1773 completely conform to wg charter requirements, especially for the 1774 first paragraph of the description. /d 1776 B.1. DPRIVE 1778 DNS PRIVate Exchange (dprive) 1780 Group Name: DNS PRIVate Exchange 1781 Acronym: dprive 1782 Area: Internet Area (int) 1783 Charter: charter-ietf-dprive-01 (Approved) 1784 Personnel 1785 Chairs: Tim Wicinski 1786 Warren Kumari 1787 Area Director: Brian Haberman 1788 Mailing List Address: dns-privacy@ietf.org 1789 To Subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy 1790 Archive: http://www.ietf.org/mail-archive/web/dns-privacy/ 1791 Jabber Chat Room Address: xmpp:dprive@jabber.ietf.org 1792 Logs: http://jabber.ietf.org/logs/dprive/ 1793 Charter for Working Group 1795 The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to 1796 provide confidentiality to DNS transactions, to address concerns 1797 surrounding pervasive monitoring (RFC 7258). 1799 The set of DNS requests that an individual makes can provide an 1800 attacker with a large amount of information about that individual. 1801 DPRIVE aims to deprive the attacker of this information. (The IETF 1802 defines pervasive monitoring as an attack [RFC7258]) 1804 The primary focus of this Working Group is to develop mechanisms that 1805 provide confidentiality between DNS Clients and Iterative Resolvers, 1806 but it may also later consider mechanisms that provide confidentiality 1807 between Iterative Resolvers and Authoritative Servers, or provide 1808 end-to-end confidentiality of DNS transactions. Some of the results of 1809 this working group may be experimental. The Working Group will also 1810 develop an evaluation document to provide methods for measuring the 1811 performance against pervasive monitoring; and how well the goal is met. 1812 The Working Group will also develop a document providing example 1813 assessments for common use cases. 1815 DPRIVE is chartered to work on mechanisms that add confidentiality to 1816 the DNS. While it may be tempting to solve other DNS issues while 1817 adding confidentiality, DPRIVE is not the working group to do this. 1818 DPRIVE will not work on any integrity-only mechanisms. 1820 Examples of the sorts of risks that DPRIVE will address can be found 1821 in [draft-bortzmeyer-dnsop-dns-privacy], and include both passive 1822 wiretapping and more active attacks, such as MITM attacks. DPRIVE will 1823 address risks to end-users' privacy (for example, which websites an 1824 end user is accessing). 1826 Some of the main design goals (in no particular order) are: 1828 - Provide confidentiality to DNS transactions (for the querier). 1830 - Maintain backwards compatibility with legacy DNS implementations. 1832 - Require minimal application-level changes. 1834 - Require minimal additional configuration or effort from applications or users 1836 Milestones 1837 Dec 2014 1838 WG LC on an problem statement document 1839 draft-bortzmeyer-dnsop-dns-privacy 1840 Mar 2015 1841 WG selects one or more primary protocol directions 1842 Jul 2015 1843 WG LC on primary protocol directions 1845 B.2. iptel 1847 Working Group Name: 1848 IP Telephony (iptel) 1850 IETF Area: 1851 Transport Area 1853 Chair(s): 1854 Jonathan Rosenberg 1856 Transport Area Director(s): 1857 Scott Bradner 1858 Allyn Romanow 1860 Responsible Area Director: 1861 Allyn Romanow 1863 Mailing Lists: 1864 General Discussion:iptel@lists.research.bell-labs.com 1865 To Subscribe: iptel-request@lists.research.bell-labs.com 1866 Archive: http://www.bell-labs.com/mailing-lists/siptel 1868 Description of Working Group: 1870 Before Internet telephony can become a widely deployed service, a 1871 number of protocols must be deployed. These include signaling and 1872 capabilities exchange, but also include a number of "peripheral" 1873 protocols for providing related services. 1875 The primary purpose of this working group is to develop two such 1876 supportive protocols and a frameword document. They are: 1878 1. Call Processing Syntax. When a call is setup between two 1879 endpoints, the signaling will generally pass through several servers 1880 (such as an H.323 gatekeeper) which are responsible for forwarding, 1881 redirecting, or proxying the signaling messages. For example, a user 1882 may make a call to j.doe@bigcompany.com. The signaling message to 1883 initiate the call will arrive at some server at bigcompany. This 1884 server can inform the caller that the callee is busy, forward the 1885 call initiation request to another server closer to the user, or drop 1886 the call completely (among other possibilities). It is very desirable 1887 to allow the callee to provide input to this process, guiding the 1888 server in its decision on how to act. This can enable a wide variety 1889 of advanced personal mobility and call agent services. 1890 Such preferences can be expressed in a call processing syntax, which 1891 can be authored by the user (or generated automatically by some 1892 tool), and then uploaded to the server. The group will develop this 1893 syntax, and specify means of securely transporting and extending it. 1894 The result will be a single standards track RFC. 1896 2. In addition, the group will write a service model document, which 1897 describes the services that are enabled by the call processing 1898 syntax, and discusses how the syntax can be used. This document will 1899 result in a single RFC. 1901 3. Gateway Attribute Distribution Protocol. When making a call 1902 between an IP host and a PSTN user, a telephony gateway must be used. 1903 The selection of such gateways can be based on many criteria, 1904 including client expressed preferences, service provider preferences, 1905 and availability of gateways, in addition to destination telephone 1906 number. Since gateways outside of the hosts' administrative domain 1907 might be used, a protocol is required to allow gateways in remote 1908 domains to distribute their attributes (such as PSTN connectivity, 1909 supported codecs, etc.) to entities in other domains which must make 1910 a selection of a gateway. The protocol must allow for scalable, 1911 bandwidth efficient, and very secure transmission of these 1912 attributes. The group will investigate and design a protocol for this 1913 purpose, generate an Internet Draft, and advance it to RFC as 1914 appropriate. 1916 Goals and Milestones: 1918 May 98 Issue first Internet-Draft on service framework 1919 Jul 98 Submit framework ID to IESG for publication as an RFC. 1920 Aug 98 Issue first Internet-Draft on Call Processing Syntax 1921 Oct 98 Submit Call processing syntax to IESG for consideration 1922 as a Proposed Standard. 1923 Dec 98 Achieve consensus on basics of gateway attribute 1924 distribution protocol 1925 Jan 99 Submit Gateway Attribute Distribution protocol to IESG 1926 for consideration as a RFC (info, exp, stds track TB 1928 B.3. rtg 1930 Working Group Name: Routing Over Low power and Lossy networks 1931 Acronym: roll 1932 Area: Routing Area (rtg) 1933 Charter: charter-ietf-roll-03 (Approved) 1934 Personnel 1935 Chairs: Ines Robles 1936 Michael Richardson 1938 Area Director: Adrian Farrel 1939 Tech Advisor: Rene Struik 1940 Delegates: Robert Cragie 1941 Yvonne-Anne Pignolet 1942 Mailing List Address: roll@ietf.org 1943 To Subscribe: http://www.ietf.org/mailman/listinfo/roll 1944 Archive: http://www.ietf.org/mail-archive/web/roll/ 1945 Jabber Chat Room Address: xmpp:roll@jabber.ietf.org 1946 Logs: http://jabber.ietf.org/logs/roll/ 1948 Charter for Working Group 1950 Low power and Lossy networks (LLNs) are made up of many 1951 embedded devices with limited power, memory, and processing 1952 resources. They are interconnected by a variety of links, such as 1953 IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low 1954 power PLC (Powerline Communication) links. LLNs are transitioning 1955 to an end-to-end IP-based solution to avoid the problem of 1956 non-interoperable networks interconnected by protocol translation 1957 gateways and proxies. 1959 Generally speaking, LLNs have at least five distinguishing 1960 characteristics: 1961 - LLNs operate with a hard, very small bound on state. 1962 - In most cases, LLN optimize for saving energy. 1963 - Typical traffic patterns are not simply unicast flows (e.g. in some 1964 cases most if not all traffic can be point to multipoint) 1965 - In most cases, LLNs will be employed over link layers with 1966 restricted frame-sizes, thus a routing protocol for LLNs should be 1967 specifically adapted for such link layers. 1968 - LLN routing protocols have to be very careful when trading off 1969 efficiency for generality; many LLN nodes do not have resources to 1970 waste. 1972 These specific properties cause LLNs to have specific routing 1973 requirements. 1975 Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have 1976 been evaluated by the working group and have in their current form been 1977 found to not satisfy all of these specific routing requirements. 1979 The Working Group is focused on routing issues for LLN. 1981 There is a wide scope of application areas for LLNs, including 1982 industrial monitoring, building automation (HVAC, lighting, access 1983 control, 1984 fire), connected homes, healthcare, environmental monitoring, urban sensor 1985 networks (e.g. Smart Grid), asset tracking. The Working Group focuses 1986 on routing solutions for a subset of these: industrial, connected 1987 home, building and urban sensor networks for which routing requirements have 1988 been specified. These application-specific routing requirement 1989 documents will be used for protocol design. 1991 The Working Group focuses only on IPv6 routing architectural framework 1992 for these application scenarios. The Framework will take into 1993 consideration various aspects including high reliability in the presence 1994 of time 1995 varying loss characteristics and connectivity while permitting low-power 1996 operation with very modest memory and CPU pressure in networks 1997 potentially comprising 1998 a very large number (several thousands) of nodes. 2000 The Working Group will pay particular attention to routing security 2001 and manageability (e.g., self routing configuration) issues. It will 2002 also need to consider the transport characteristic the routing protocol 2003 messages will experience. Mechanisms that protect an LLN from congestion 2004 collapse or 2005 that establish some degree of fairness between concurrent 2006 communication sessions are out of scope of the Working Group. It is 2007 expected that 2008 upper-layer applications utilizing LLNs define appropriate mechanisms. 2009 The solution must include unicast and multicast considerations. 2011 Work Items: 2013 - Specification of routing metrics used in path calculation. This 2014 includes static and dynamic link/node attributes required for routing in 2015 LLNs. 2017 - Provide an architectural framework for routing and path selection at 2018 Layer 3 (Routing for LLN Architecture) that addresses such issues as 2019 whether LLN routing require a distributed and/or centralized path 2020 computation models, whether additional hierarchy is necessary and how it 2021 is 2022 applied. 2024 Manageability will be considered with each approach, along with 2025 various trade-offs for maintaining low power operation, including the 2026 presence of non-trivial loss and networks with a very large number of nodes. 2027 should 2028 - Produce a routing security framework for routing in LLNs. 2030 - Protocol work: The Working Group will consider specific routing 2031 requirements from the four application documents collectively, and 2032 specify either 2033 a new protocol or extend an existing routing protocol in cooperation 2034 with the 2035 relevant Working Group. 2036 If requirements from the four target application areas cannot be met 2037 with a single protocol, the WG may choose to specify or extend more than 2038 one 2039 protocol (this will require a recharter of the WG). 2041 - Documentation of applicability statement of ROLL routing protocols. 2043 Milestones 2044 Done 2045 Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. 2046 Done 2047 Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. 2048 Done 2049 Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. 2050 Done 2051 Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. 2052 Done 2053 Submit Security Framework to the IESG to be considered as an Informational RFC 2054 Done 2055 Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. 2056 Done 2057 Submit first draft of ROLL routing protocol specification as Proposed Standard. 2058 Done 2059 Submit the ROLL routing protocol specification to the IESG as Proposed Standard. 2060 Done 2061 Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC 2062 Done 2063 WG to adopt RPL applicability statement Home for Automation applications 2064 draft-ietf-roll-applicability-home-building 2065 Done 2066 WG to adopt RPL applicability statement(s) for AMI networks 2067 draft-ietf-roll-applicability-ami 2068 Done 2069 WG to adopt RPL applicability statement for Industrial applications 2070 draft-ietf-roll-rpl-industrial-applicability 2071 Done 2072 WG to adopt reviewed template for applicability statements 2073 draft-ietf-roll-applicability-template 2074 Done 2075 Resolve question of whether to keep this in roll or 6tisch 2076 draft-ietf-roll-rpl-industrial-applicability 2077 Done 2078 submit REVISED thread-analysis document based upon security directorate review to IESG. 2079 draft-ietf-roll-security-threats 2080 Feb 2014 2081 Submit first draft of RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC 2082 Done 2083 Evaluate WG progress, recharter or close 2084 Aug 2014 2085 WG to joint-LC using flow-label for RPL with 6man 2086 draft-thubert-6man-flow-label-for-rpl 2088 B.4. another one 2090 Appendix C. [PROTO-WIKI] Working Group Advice 2092 NOTE TO RFC EDITOR: Prior to publication, this section is to be 2093 moved to an IETF wiki page, for on-going enhancement. 2095 ALSO: The document's reference to this section needs to be 2096 modified to refer to that wiki. 2098 C.1. If you have a formal WG role... 2100 Here is some basic advice to anyone performing working group 2101 administrative or management dutues -- that is, anyone assigned tasks 2102 by the AD or a chair: 2104 o Re-read "The Tao of IETF: A Novice's Guide to the Internet 2105 Engineering Task Force" [Tao]. You've already read it at least 2106 once, right? 2108 o Read [RFC7282]. No, really, I know you say you've read it; go 2109 read it again. Be sure you know what "rough consensus" is, how it 2110 can be identified and how it is used in the IETF. Pay particular 2111 attention to its extended discussion of the handling of 'minority' 2112 views. 2114 C.2. Advice for Chairs 2116 o Become familiar with: [ChairGuide] 2118 o Some WGs do work that requires interaction and cooperation with 2119 other standards bodies. WG administrative staff should be aware 2120 of the possibility of such interactions, as formally described 2121 regarding IEEE in RFC 7241 and ITU-T in RFC 6756. The IETF has 2122 established a formal liaison role for some of these interactions, 2123 as defined in RFC 4691. RFC 4929 describes a specific (and 2124 historically interesting) example of interaction between the IETF 2125 and ITU-T. 2127 o Handling Internet-Drafts as part of the activities of Working 2128 Groups is summarized in RFC 2418bis and described in detail in RFC 2129 7241. The states that a WG document can take are defined in RFC 2130 6174. 2132 o The co-chairs are responsible for behavior of WG participants as 2133 part of the IETF. RFC 7154 can help to identify and deal with 2134 unacceptable behavior. 2136 o Intellectual property rights (IPR) management is crucial to the 2137 IETF and has been the source of serious legal issues in the past. 2138 Read RFC 6702 to understand the IETF disclosure rules and how to 2139 make sure your WG stays in compliance with those rules. Also read 2140 RFC 6701 to learn how you can deal with IPR policy violations. 2142 C.3. Meetings 2144 C.3.1. WG meeting preparation 2146 C.3.1.1. Request meeting slot(s) 2148 A WG will typically meet once during an IETF meeting. The chairs may 2149 choose to request two slots if the WG has a long agenda. Requesting 2150 more than two slots requires approval of the Area Director. 2152 The request will include the expected length, number of participants 2153 and a list of other WGs with which time conflicts should be avoided. 2154 These specific requests should be considered carefully as they are 2155 important for successful scheduling. 2157 C.3.1.2. Create and post agenda 2159 Well before the meeting, the WG administration posts a request for 2160 proposed discussion items, presentations and other agenda items to 2161 the WG mailing list. 2163 The WG administration collects the requests for agenda items and adds 2164 other agenda items as required for WG operation and posts a draft 2165 agenda for WG review. Once the final agenda is ready, the WG 2166 administration posts it through the IETF Meeting Materials manager 2167 web page. 2169 C.3.1.3. Post meeting materials 2171 Any documents to be discussed at the WG meeting must be posted two 2172 weeks before the meeting. The IESG Secretariat enforces an I-D 2173 publication restriction during the two weeks before the IETF meeting. 2175 Any presentations or other materials should be posted through to the 2176 IETF Meeting Materials at least a week before the IETF meeting to 2177 provide participants an opportunity to review those materials. 2179 C.3.1.4. Other meeting prep 2181 There are minute takers and jabber scribes at every WG meeting. It 2182 can save time at the meeting to identify individuals to fill those 2183 roles prior to the meeting. 2185 C.3.2. WG meeting operation 2187 * Confirm meeting room logistics: AV equipment, presentation 2188 materials, etc. 2190 * Pass around attendance records ("blue sheets") 2192 * Bash the agenda 2194 * WG status update 2196 * Proceed through the agenda 2198 * Record significant consensus calls, process actions, technical 2199 decisions 2201 C.3.3. WG Meeting Followup 2203 * Deliver a one paragraph summary of the meeting, including 2204 significant consensus calls, process actions, technical decisions, 2205 for the Area Director before the end of the IETF meeting 2207 * Prepare notes, using notes, jabber log and audio recording of 2208 the meeting; once the notes are ready, post the notes to the IETF 2209 Meeting Materials 2211 C.4. Ongoing WG operation 2213 C.4.1. Managing Individual Documents 2215 Documents typically go through several revisions in the process of WG 2216 development and review. The datatracker is used to manage and 2217 publish the state of an I-D as it progresses toward publication. WG 2218 administration coordinates the editing of the document by the editors 2219 with the input from the WG. The issues tracker is a useful tool for 2220 recording and managing specific issues with an I-D. 2222 The document shepherd manages the processing and publication of the 2223 document after it has been submitted by the WG to the IESG for 2224 publication. The issues tracker can be useful at this stage of the 2225 publication process as well. 2227 C.4.2. Charter Management 2229 * The WG administration reviews and periodically updates the WG 2230 milestones. 2232 Authors' Addresses 2234 Dave Crocker (editor) 2235 Brandenburg InternetWorking 2236 675 Spruce Drive 2237 Sunnyvale, CA 94086 2238 USA 2240 Phone: +1.408.246.8253 2241 Email: dcrocker@bbiw.net 2243 Ralph Droms (editor) 2244 Cisco Systems 2245 1414 Massachusetts Avenue 2246 Boxborough, MA 01719 2248 Email: rdroms@cisco.com