Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 2418, 7221 (if approved) R. Droms, Ed. Updates: 2026 (if approved) Cisco Systems Intended status: Best Current Practice September 1, 2015 Expires: March 4, 2016 IETF Working Group Guidelines and Procedures draft-crocker-rfc2418bis-wgguidelines-01 Abstract IETF activities are primarily organized into open-participation working groups (WGs). This document describes the formation, requirements, structure, and operation of IETF working groups. This includes the formal relationships and duties of participants. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 4, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Crocker & Droms Expires March 4, 2016 [Page 1]
Internet-Draft WG Guidelines & Procedures September 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology and References . . . . . . . . . . . . . . . 4 1.3. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . 5 2. Basic Structure and Requirements . . . . . . . . . . . . . . 6 2.1. Working Group Charter . . . . . . . . . . . . . . . . . . 6 2.2. Deliverables . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Mailing List . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Area Directors . . . . . . . . . . . . . . . . . . . . . 8 2.5. Chair(s) . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Document Writer . . . . . . . . . . . . . . . . . . . . . 9 2.7. Participants . . . . . . . . . . . . . . . . . . . . . . 9 2.8. Rough Consensus Decision Making . . . . . . . . . . . . . 9 3. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Home Page . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Issue-tracking Tickets . . . . . . . . . . . . . . . . . 11 3.4. Meeting Materials . . . . . . . . . . . . . . . . . . . . 11 3.5. Internet-Drafts (I-D) . . . . . . . . . . . . . . . . . . 12 3.6. Request For Comments (RFC) . . . . . . . . . . . . . . . 12 4. Working Group Internal Operation . . . . . . . . . . . . . . 12 4.1. Prime Directives . . . . . . . . . . . . . . . . . . . . 12 4.2. General Organizing . . . . . . . . . . . . . . . . . . . 13 4.3. Discussion and Progress . . . . . . . . . . . . . . . . . 15 4.4. IETF Open Decision-Making . . . . . . . . . . . . . . . . 16 4.5. Mailing List Primacy . . . . . . . . . . . . . . . . . . 16 4.6. Discussion Venues . . . . . . . . . . . . . . . . . . . . 17 4.7. Session Planning . . . . . . . . . . . . . . . . . . . . 20 4.8. Meeting Drafts and Documents . . . . . . . . . . . . . . 21 4.9. Meeting Record Keeping . . . . . . . . . . . . . . . . . 21 5. Document Development & Lifecycle . . . . . . . . . . . . . . 21 5.1. Basic Sequence . . . . . . . . . . . . . . . . . . . . . 22 5.2. Early Document Review . . . . . . . . . . . . . . . . . . 23 5.3. Document Coordination Between Working Groups . . . . . . 23 5.4. Working Group Last-Call . . . . . . . . . . . . . . . . . 24 5.5. Final External Review of Documents . . . . . . . . . . . 24 6. Staff Roles . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Development . . . . . . . . . . . . . . . . . . . . . . . 26 6.2. Advice . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. WG External Administration . . . . . . . . . . . . . . . . . 27 7.1. Working group Formation . . . . . . . . . . . . . . . . . 27 7.2. Charter Content . . . . . . . . . . . . . . . . . . . . . 32 Crocker & Droms Expires March 4, 2016 [Page 2]
Internet-Draft WG Guidelines & Procedures September 2015 7.3. Submission & Publication of Documents . . . . . . . . . . 33 7.4. Working Group Termination . . . . . . . . . . . . . . . . 34 7.5. Contention and appeals . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1. References - Normative . . . . . . . . . . . . . . . . . 35 9.2. References - Informative . . . . . . . . . . . . . . . . 36 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 38 Appendix B. Sample Working Group Charters . . . . . . . . . . . 38 B.1. DPRIVE . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.2. iptel . . . . . . . . . . . . . . . . . . . . . . . . . . 40 B.3. rtg . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.4. another one . . . . . . . . . . . . . . . . . . . . . . . 45 Appendix C. [PROTO-WIKI] Working Group Advice . . . . . . . . . 45 C.1. If you have a formal WG role... . . . . . . . . . . . . . 45 C.2. Advice for Chairs . . . . . . . . . . . . . . . . . . . . 45 C.3. Meetings . . . . . . . . . . . . . . . . . . . . . . . . 46 C.4. Ongoing WG operation . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction The IETF ([RFC3995],[About]) is an open community of network designers, operators, vendors, users, and researchers concerned with the development and operation of Internet technical specifications. Activities of the IETF are primarily performed by committees known as Working Groups [WG]. For administrative purposes, they are organized into topical [Areas]. Working groups are formally chartered, typically with a narrow focus and lifetime bounded by the completion of a specific set of tasks. This document describes the formation, requirements, structure, and operation of IETF working groups. This includes the formal relationships and duties of participants. At base, working groups are driven by: o Goals o Rules o Tasks o Participants That is, a collection of participants, who fill various roles, work toward some common goal(s), according to IETF requirements. This document is principally organized according to these distinctions. Crocker & Droms Expires March 4, 2016 [Page 3]
Internet-Draft WG Guidelines & Procedures September 2015 1.1. Background This version is organized as an aid to (new) working group participants both as an introduction and as a later reference. o It describes existing IETF rules and practices and does not describe or suggest any changes. Specifically this version of the document: o Replaces general IETF tutorial material that it had with pointers to independent versions o Incorporates work from a number of targeted efforts over the years o Reorganizes content to aid direct use by working group participants o Distinguishes between formal IETF requirements and processes, versus common practices chosen by working groups, where the latter are primarily discussed in a non-normative external IETF Wiki (Appendix C) that can be continually revised by the community. A useful introduction to the IETF is The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force [Tao]. Familiarity with The Internet Standards Process [RFC2026] is essential for a complete understanding of the philosophy, procedures and guidelines described in this document. 1.2. Terminology and References When used in this document the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are normative and are to be interpreted as described in [RFC2119]. NOTE: Summary text about other documents is solely advisory. Unless explicitly stated otherwise, it MUST NOT be taken as pre- empting the content of those documents. Throughout the document, there are portions prefaced with a (Task) label. These call out specific actions that are required, suggested, or permitted. Besides being meant to draw the eye to action items that are distinct from surrounding discussion text, these provide an approximate list of tasks that might be assigned to various roles in the working group, as discussed in Section 6. Crocker & Droms Expires March 4, 2016 [Page 4]
Internet-Draft WG Guidelines & Procedures September 2015 1.3. OPEN ISSUES NOTE TO RFC EDITOR: Remove this section before publication. This list is an invitation for information, pointers, corrections, and additional/different text. In some cases, resolution will require discussion and some version of IETF consensus. Roles/Titles: What are the formal WG roles/titles that are a) documented, b) can be written into a charter, and c) can be assigned via the Datatracker? E.g., Consultant vs. Tech Adviser. What are the formal permissions for "Delegated authority"? What are options and what are choices within options? Doc Publication: In terms of process, what is formally required vs. typical vs. wg choice. Eg, a) required - wg last call? -- maybe not required, but advisable to avoid an appeal; b) Formal: publication as wg item, when pushing doc out of wg to iesg/rfc editor. WG Ops vs. Tasks: Macro vs micro -- Overall wg management, eg, meetings and task sequencing; vs. managing a task, eg, doc revisions, issue tracking, writer/wg relationship. Familiarity: Besides RFC 2026, what other IETF docs are "required" for the reader to have familiarity with? Charter negotiation: WHO NEGOTIATES A CHARTER??? Distinguish required vs. flexible. Emphasize open and accountable. Citations: What other RFCs, IESG Statements, etc. need to be cited? Mailing List Hosting: (Secretariat queried) Are IETF working group mailing lists now required to be hosted at the IETF? Milestones: make sure example charter in Appendix A includes milestones Suspension: Email -- " the Area Director, with the approval of the IESG, MAY request that the mailing list maintainer block the ability of the offending individual to post to the mailing list." Is it the AD that does this? Who really does? Docs on Agenda: "Any document which does not meet this publication deadline can only be discussed in a working group session with the Crocker & Droms Expires March 4, 2016 [Page 5]
Internet-Draft WG Guidelines & Procedures September 2015 specific approval of the working group chair(s)." Current operation is that /all/ items on an agenda are explicitly approved by the chair/wg??? -- distinguish "IETF" deadline from "WG- specific" requirement(s)." Wiki? What should be moved to the Wiki or added to it? Normative? Review references for normative/non-normative placement listing in doc. Reporting? Resolve various IETF website pages concerning submission and archive of notes, etc? Milestone Revision: Revised milestones MUST be approved by the cognizant Area Director. Is any other review or approval needed, such as from the IESG? 2. Basic Structure and Requirements The IETF permits wide variation in the conduct of working group affairs. Still, there is a core of required organization and required operation. This section describes that core. 2.1. Working Group Charter A working group is based on a formal a charter, which is a contract between a working group and the IETF to perform a set of tasks. A charter: o Lists relevant administrative information for the working group o Specifies the direction or objectives of the working group and describes the approach that will be taken to achieve the goals o Enumerates a set of milestones together with time frames for their completion Details concerning charters are provided in Section 7.2. 2.2. Deliverables A working group's charter specifies deliverables to be achieved. (Section 7.2) These are usually documents to be published in the Request for Comments series [RFC-Editor]. The means of achieving those deliverables is only lightly constrained: whatever permits a working group to conduct a fair, open and accountable process, while achieving working group rough consensus, is permitted. The challenge with this flexibility is formulating the details of internal working Crocker & Droms Expires March 4, 2016 [Page 6]
Internet-Draft WG Guidelines & Procedures September 2015 group structure and process in a manner that ensures timely achievement. In other words, the group needs to efficiently balance fair and open discussion, proper attention to legitimate concerns, and making forward progress. 2.3. Mailing List A process that is truly open and inclusive makes participation as easy as possible, for the widest range of participants as possible. For the IETF, that means that the primary venue for working group activities MUST be the mailing list associated with the group. (Section 7.2) Further, the mailing list MUST be the only venue for formally assessing working group rough consensus. "Decisions" made at venues other than the working group mailing list MUST be treated as preliminary, and MUST be explicitly documented and confirmed through the mailing list. (Task) It is important to ensure that the discussions on this list are relevant and that they converge to consensus agreements. (Task) It can help to summarize a discussion periodically. (Task) It also can help later review to ensure that outcomes are well and explicitly documented (to avoid repetition). The Chair also MAY choose to schedule organized on-line "sessions" with agenda and deliverables. These can be structured as true meetings, conducted over the course of several days (to allow participation across the Internet). Mailing lists related to IETF activities are usually hosted at the IETF, but generally MAY be hosted elsewhere. (Task) A message archive MUST be maintained in a public place which can be accessed via FTP or via the web. As a service to the community, the IETF Secretariat operates a mailing list archive for working group mailing lists. In order to take advantage of this service, working group mailing lists MUST include the address: {ACRONYM}-archive@ietf.org Crocker & Droms Expires March 4, 2016 [Page 7]
Internet-Draft WG Guidelines & Procedures September 2015 (where {ACRONYM} is the abbreviated name for the working group) in the mailing list, so that a copy of all mailing list messages is recorded in the Secretariat's archive for the list. Multiple versions of list archives are available, as indicated in the "Archives" section of [MailList]. One form is located at: http://www.ietf.org/mail-archive/web/{ACRONYM}/current/maillist.html where {ACRONYM} is the abbreviated name for the working group. For robustness, WGs SHOULD maintain an additional archive separate from that maintained by the Secretariat. 2.4. Area Directors IETF Working Groups are administratively aggregated into "areas". Each working group has a designated ("cognizant") Area Director [AD] ([AD-Desc],[Areas]), to formally select chairs for the working group and to provide oversight. 2.5. Chair(s) Working Group Chairs are formally responsible for ensuring that the working group makes forward progress through a fair and open process. They have wide discretion in the conduct of WG business. However within the bounds of IETF formal requirement, Chairs are always accountable to the rough consensus (Section 2.8) of the working group participants, as well as to the Area Director who appointed them. Chairs ensure that a number of procedural, administrative and project management tasks are performed, either directly or by others assigned to the tasks. Chairs have the authority and the responsibility to make decisions, on behalf of the working group, regarding all matters of internal working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention. The choices for assignment of tasks are highly dependent upon the nature of the working group topic, the nature of the work to be done, and the nature of working group participation. When a topic is well- understood, the deliverables straightforward and the participants generally knowledgeable and compatible, a very streamlined working group organization can be quite reasonable. As topic and/or participation get more challenging, working group operation typically needs to be more actively and formally managed, typically requiring Crocker & Droms Expires March 4, 2016 [Page 8]
Internet-Draft WG Guidelines & Procedures September 2015 administrative tasks to be spread among other participants and processes for discussion and decision-making more structured. 2.6. Document Writer Most IETF working groups focus their efforts on a document, or set of documents, that capture the results of the group's work. A working group designates one or more people to serve as the Writer for a particular document. The Document Writer is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group. As a general practice, the Working Group Chair and Document Writer positions are filled by different individuals to help ensure a clear distinction between process management and content generation. This helps the resulting documents to accurately reflect the consensus of the working group. However this separation is not a firm requirement. Especially in a small, narrow, simple effort among a cohesive group, it might be convenient and efficient for the Chair and Writer roles to be combined. The Document Writer is variously called an "author" or an "editor". The IETF does not have consistent rules for distinguishing use of these terms. However, see Section 3 of [RFC7221] for a suggested distinction between primary responsibility for creating concepts and content, versus responsibility for recording content developed by the working group itself. 2.7. Participants The foundation of a working group is its participants. Within the scope of the charter, working group participants represent the entire Internet, indicating what output is needed from the working group effort -- including who will use it and why -- and providing guidance, ideas, text, discussion, and assessment. For all substantive choices, the 'rough consensus' of the participants determines the real work of the group. NOTE: WG participants MUST conform to the requirements for disclosure of conflicts of interest in [RFC2028]. 2.8. Rough Consensus Decision Making The IETF does not have "members" and it's open processes can not make decisions by "voting". Rather, a community sense of strongly- dominant agreement, in the absence of compelling objections, is used to make decisions. This is called Rough Consensus [RFC7282]. Within working group processes, this is the required means for making Crocker & Droms Expires March 4, 2016 [Page 9]
Internet-Draft WG Guidelines & Procedures September 2015 working group decisions, but more importantly it is a model for considering issues. Expediency: In the abstract, nearly all working group activities and decisions are subject to Rough Consensus. In practice, working group chairs often make decisions based on the assumption of working group support. This practice is essential for working group efficiency, but its risk is that the chair's choices will not actually be in sync with the working group's desires. Consequently, all participants carry the responsibility of voicing concerns they consider significant, even when no other participant has spoken up. Substantiveness: A major challenge in considering Rough Consensus appears to be distinguishing between active and passive support. Active support is indicated by participants that are actively engaged in discussing the topic, whereas passive has, at most, pro forma expressions of support, without any obvious indication that the topic is both understand and important to the participant. The dangers of passive support are that it could mean the topic is not adequately understood and/or that the topic will not obtain community followup, such as deployment and use. Minorities: The other major challenge, as discussed in [RFC7282], is that "minority" concerns are not adequately addressed. In particular in the interest of moving the working group effort along, it is easy to marginalize such concerns because they are expressed by few participants. What this risks is failure to attend to problems that are serious and will affect utility of the work later. There is, of course, a competing pressure that 'minority' voices could stall the working group. So the core working group challenge with a minority concern is to adequately consider its nature and adequately consider its effect, while still making forward progress. 3. Documents 3.1. Home Page Each working group has an associated web page, listing working group documents and pointing to a variety of related other pages. The working group home page is located at: http://datatracker.ietf.org/wg/{ACRONYM}/documents/ where {ACRONYM} is the abbreviated name for the working group. Crocker & Droms Expires March 4, 2016 [Page 10]
Internet-Draft WG Guidelines & Procedures September 2015 3.2. Wiki Working groups can have access to an editable wiki, if requested by a Chair, for use as the working group sees fit. It is located at: http://trac.tools.ietf.org/wg/{ACRONYM}/trac/wiki where {ACRONYM} is the abbreviated name for the working group. 3.3. Issue-tracking Tickets (Task) As topics, issues and suggestions increase for a working group, it can be helpful to document them in an issue tracking system. One can be provided through the working group wiki, if requested by a Chair, at the tab for "View Tickets": http://trac.tools.ietf.org/wg/{ACRONYM}/trac/report where {ACRONYM} is the abbreviated name for the working group. 3.4. Meeting Materials Any organized working group session (meeting) will have planning and reporting material, including: o Agenda o Presentations o Notes o Transcripts (e.g., jabber logs) (Task) The planning and presentation material needs to be made available in advance of the session. (Task) They and the reporting materials also need to be preserved for later reference. Details about IETF Meeting Materials are provided in [MeetMaterials], [MeetMaterialTool]. NOTE: The IETF web site has related information that appears to be out of date, such as [AgendaNotes]. Crocker & Droms Expires March 4, 2016 [Page 11]
Internet-Draft WG Guidelines & Procedures September 2015 3.5. Internet-Drafts (I-D) Working group efforts are typically driven by specific documents. Some are used to fuel working group discussion while others are the deliverable product under development. Documents are processed as Internet Drafts [I-D], which are strictly working documents and have no official standards status whatsoever. They might, eventually, turn into a standards-track document or they might sink from sight. Formal adoption of Internet Drafts in a working group is discussed in [RFC7221]. Also, there are naming conventions, to identify Internet Drafts that have been adopted by a working group, as described in Section 7 of [I-D-Guidelines]. 3.6. Request For Comments (RFC) The work of an IETF working group typically targets publication of one or more documents, as part of the Request For Comments (RFC) series. ([RFC-IETF], [RFC-Editor], [RFC2026]) This series is the archival publication record for the Internet community. There are multiple, independent streams that produce documents published as RFCs; the IETF stream is one of these. A document can be written by an individual in a working group, by a group as a whole with a designated Writer, or by others not involved with the IETF. The RFC Editor provides guidance for writing an RFC. [RFC7322] NOTE: The RFC series is a publication mechanism only and publication does not determine the IETF status of a document. RFCs are processed through a number of independent 'streams', of which those produced with IETF approval represent one. The IETF status is determined through separate, explicit status labels assigned by the IESG on behalf of the IETF. In other words, the reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards. [RFC1796] 4. Working Group Internal Operation 4.1. Prime Directives The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are nearly autonomous and each determines most of the details of its own operation with respect to organization, planning, session participation, discussion style, means of reaching closure, etc. o The core rule for operation is that acceptance or agreement is achieved via working group "rough consensus". (Section 2.8) Crocker & Droms Expires March 4, 2016 [Page 12]
Internet-Draft WG Guidelines & Procedures September 2015 A number of procedural questions and issues will arise over time. The Working Group Chair(s) have ultimate responsibility for management of the group process, keeping in mind that the overall purpose of the group is to make progress towards reaching rough consensus in realizing the working group's goals and objectives. There are few hard and fast rules on organizing or conducting working group activities, but a set of guidelines and practices has evolved over time that have proven successful. Some basic choices are listed in (Section 6). These are discussed at length in the associated wiki. (Appendix C) (Task) Actual choices for the details of working group operation are determined by the working group participants and the Chair(s). For some working groups, this can be accomplished by having the Chair perform all management-related activities. In other working groups -- particularly those with large or divisive participation -- it is helpful to allocate process and/or secretarial functions to other participants. Process management pertains strictly to the style of working group interaction and not to its content. It ensures fairness and detects redundancy. The secretarial function encompasses document editing. It is quite common for a working group to assign the task of specification Writer to one or two participants. Sometimes, they also are part of the design team, described below. (Section 6) Of course, each WG will have participants who might not be able (or want) to do any work at all. Most of the time the bulk of the work is done by a few dedicated participants. It is the task of the Chair to motivate enough experts to allow for a fair distribution of the workload and the necessary representation of Internet community requirements. 4.2. General Organizing Working groups sometimes develop and operate organically, needing very little assertive management by the Chairs. Such groups are nearly self-regulating and that is entirely acceptable, but it also is rare. When a working group has to do simple tasks, and the working group is cohesive and knowledgeable, there is little need for much formality in working group management. Most working groups are not so fortunate. For them, active management might be required, to determine such things as the sequence of work, the design teams for doing core work, issue-tracking, the approach for resolving issues, and even discussion facilitation. Crocker & Droms Expires March 4, 2016 [Page 13]
Internet-Draft WG Guidelines & Procedures September 2015 4.2.1. Characterizing the Effort (Task) It can help to evaluate the work to be done and the participation in the working group that will do it: * Consider the community knowledge of the problem space * Consider the plausible solution space, in terms of complexity and clarity * Consider the composition of the working group, in terms of size, shared knowledge, interaction style, and focus on achieving productive results 4.2.2. Plan of Work Working groups typically produce more than one document. While there might appear to be a natural sequence for developing them, consider that some foundational documents that logically need to be done first might also need to be revised later, as the working group gains more experience with its topic(s). (Task) Given a sequence of documents, what are the subordinate steps that will achieve necessary milestones? It can help to chart this explicitly in the working group Wiki. (Section 3.2) 4.2.3. Tasks vs. Roles A working group requires significant administrative and management work. What is flexible is who performs the work. The choices for assigning one or more tasks to a participant filling a particular role will depend upon the assessment of the Chair(s). For example, as the scale or complexity or contentiousness of a working group increases, so does its risk of failure and its attendant need for more active and more formal management. This typically means stricter adherence to formal rules of working group process and assignment of various tasks to a wider set of participants in specific roles, so that each task receiver proper focus. Roles that are required or, at least, useful are discussed later, in (Section 6). 4.2.4. Venues Although the working group mailing list is intended to be the primary venue for discussion and MUST be the ultimate venue for assessing working group rough consensus, scheduled meetings can also be Crocker & Droms Expires March 4, 2016 [Page 14]
Internet-Draft WG Guidelines & Procedures September 2015 important. (Some successful efforts have taken place only on mailing lists, with no interactive meetings, but these are rare.) Meetings can be face-to-face, such as during the thrice-annual IETF Plenary Meeting, or "virtual" via teleconference or chat session. Face-to-face meetings can (and often do) include provisions for virtual participation to accommodate participants who cannot attend in person. See: Section 4.6, Section 4.7, Section 4.6.4. 4.3. Discussion and Progress The challenge to managing working group discussion is to balance the need for open and fair consideration of the issues against the need to make forward progress. The working group, as a whole, has the final responsibility for striking this balance. (Task) The Chair has the responsibility for overseeing the process but MAY delegate direct process management to a formally- designated Facilitator. It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if: (Task) Main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion. It is also good practice to: (Task) Note important decisions/consensus reached by email in the notes of the next 'live' session, and to summarize briefly the decision-making history in the final documents the WG produces. (Task) To facilitate making forward progress, a working group MAY decide to reject or defer the input from a participant, based upon the following criteria: Old: The input pertains to a topic that already has been resolved and is redundant with information previously available; Minor: The input is new and pertains to a topic that has already been resolved, but it is felt to be of minor import to the existing decision; Crocker & Droms Expires March 4, 2016 [Page 15]
Internet-Draft WG Guidelines & Procedures September 2015 Timing: The input pertains to a topic that the working group has not yet opened for discussion; or Scope The input is outside of the scope of the working group charter. 4.4. IETF Open Decision-Making The IETF values and demands open, inclusive decision-making by working groups. A process that is truly open and inclusive makes participation as easy as possible, for the widest range of participants as possible. For the IETF, that means that the official venue for working group formal decision-making MUST be the mailing list associated with the group AND NOWHERE ELSE. Working groups make decisions through a "rough consensus" process (Section 2.8), which entails considerably more than merely determining that a majority are for or against a particular choice. IETF rough consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group needs to prevail, absent compelling arguments against. In particular note the role of "minority" views, as discussed in [RFC7282]. It can be especially challenging to gauge the level of consensus on a mailing list. There are two different cases where a working group might be trying to understand the level of consensus via a mailing list discussion. But in both cases the volume of messages on a topic is not, by itself, a good indicator of consensus since one or two individuals might be generating much of the traffic. (Task) Enough time MUST be given to the verification process for the mailing list readers to understand and consider any objections that might be raised on the list. The normal two week last-call period SHOULD be sufficient for this. 4.5. Mailing List Primacy Discussions relating to working group topics MAY happen anywhere, amongst any group of people, on a spontaneous or continuing basis and as a closed or open set. Closed groups that persist with a continuing role in providing substantive input to the working group's content are called 'design teams'. They can be self-forming or created by the Chair(s). The working group, itself, can provide a variety of open discussion venues, over the life of the working group, as discussed below. However discussions are conducted, "decisions" made at venues other Crocker & Droms Expires March 4, 2016 [Page 16]
Internet-Draft WG Guidelines & Procedures September 2015 than the working group mailing list MUST be treated as preliminary, and MUST be explicitly documented and confirmed through the mailing list. An example method is to post a note summarizing: o the discussion o the proposed resolution o the rationale for proposing its adoption This provides working group participants with enough foundational material to understand the proposal and comment on it or even support it. It also creates a record on the official email archive. If discussion is held entirely over the mailing list, determination of the level of consensus might be harder to do, since most people subscribed to mailing lists do not actively participate in discussions. It is left to the discretion of the working group chair how to evaluate the level of consensus. The most common method used is for the working group chair to state what they believe to be the consensus view and at the same time, request comments from the list about the stated conclusion. 4.6. Discussion Venues Each working group will determine the balance of email versus interactive (face-to-face, online, ...) sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; interactive, real-time meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group participants. In determining the balance, the WG MUST ensure that its process does not serve to exclude contribution by email-only participants. (Task) Remember that consensus reached during an interactive MUST be reviewed on the mailing list. 4.6.1. Tradeoffs Each working group will determine the balance of email versus interactive (face-to-face, online, ...) sessions that is appropriate for achieving its milestones. The choices are affected by various factors, including the working group's milestone schedule -- that is, degree of urgency -- complexity of the work, number of active discussants, and the schedule and support of those discussants. Crocker & Droms Expires March 4, 2016 [Page 17]
Internet-Draft WG Guidelines & Procedures September 2015 However there tends to be a significant tradeoff between doing work at interactive sessions, versus working group inclusiveness. Interactive sessions demand that a participant's schedule permit availability during the sessions. Even when held online, this can be a significant burden for some participants. Even if their formal schedule is sufficiently flexible, the fact of different participant timezones tends to work to the disadvantage of some participants. If the meetings are face-to-face, the schedule and monetary demands are dramatically higher and, obviously, further restrict participation. A mailing list venue permits the widest and most-convenient participation, by allowing for time-shifted debate among participants in multiple time zones. Its asynchrony also permits the most thoughtful presentation of views and the most thoughtful consideration of them. Interactive, real-time meetings often provide richer and higher speed communication with lower latency and therefore permit better focus. They therefore can be more efficient for reaching a consensus among a core of the working group participants, especially for narrow and contested choices. Any tools that permit real-time, or time-shifted, interaction and information exchange could be used, without affecting the basic principle that decisions are exposed and confirmed on the mailing list -- Facebook, Twitter, github, issue tracker, etc. Note that these do not provide a formal, IETF archive of the activity, although their record can be useful to cite. The mode of interaction can (and probably ought) be different in different situations. Regardless, the choice of operational style MUST be made through rough consensus of all working group mailing list participants. In determining the balance, the working group MUST ensure that its process does not serve to exclude substantive contribution by email-only participants. A basic principle is that although face-to-face discussion, either during a plenary week or at an interim meeting, might sometimes be considered essential to make rapid progress or to resolve tricky issues, this MUST NOT be discriminatory against those unable to attend. As far as technically and financially possible, facilities for passive and active remote participation SHOULD be provided. Similarly, "virtual" interim meetings in which all participants are remote MUST NOT be discriminatory against those unable to attend. Crocker & Droms Expires March 4, 2016 [Page 18]
Internet-Draft WG Guidelines & Procedures September 2015 The choice of operational style MUST be made by the working group itself. Again: consensus reached during an interactive session is purely preliminary. The proposed decision and its basis MUST be reviewed on the mailing list, and rough consensus developed and documented there. 4.6.2. Mailing List Discussion Management It can be quite useful to conduct email exchanges in the same manner as an interactive session, with published schedule and agenda, as well as on-going summarization and consensus polling, even though message-posting and responding continues to be asynchronous amongst participants. WG chairs should guide WG email debate when necessary, for example by encouraging participants to stay on topic, remain polite, avoid repetition, etc. It is helpful to encourage distinct threads with meaningful subject headers for distinct topics. As with face-to-face sessions occasionally a participant might engage in behavior on a mailing list which disrupts the WG's progress. (Task) In these cases the Chair SHOULD attempt to discourage the behavior by communication directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair MUST involve the Area Director in the issue. (Task) As a last resort and after explicit warnings, the Area Director, with the approval of the IESG, MAY request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. (If the mailing list software permits this type of operation.) Even if this is done, the individual MUST NOT be prevented from receiving messages posted to the list. Other methods of mailing list control MAY be considered but MUST be approved by the AD(s) and the IESG. 4.6.3. IETF Plenary Meetings If a WG needs a session at an IETF meeting, the Chair MUST apply for time-slots as soon as the first announcement of that IETF meeting is made by the IETF Secretariat to the WG-chairs list. Session time is a scarce resource at IETF meetings, so placing requests early will facilitate schedule coordination for WGs requiring the same set of experts. Crocker & Droms Expires March 4, 2016 [Page 19]
Internet-Draft WG Guidelines & Procedures September 2015 (Task) Some Area Directors MAY want to coordinate WG sessions in their area and request that time slots be coordinated through them. If this is the case it will be noted in the IETF meeting announcement. (Task) Requirements and procedures for obtaining a session slot at an IETF Meeting are specified in [MeetRequest]. NOTE: While open discussion and contribution is essential to working group success, the Chair is responsible for ensuring forward progress. When acceptable to the WG, the Chair MAY call for restricted participation (but not restricted attendance!) at IETF working group sessions for the purpose of achieving progress. (Task) The Working Group Chair has the authority to refuse to grant the floor to any individual who is unprepared, is covering inappropriate material, or who in the opinion of the Chair is disrupting the WG process. The Chair SHOULD consult with the Area Director(s) if the individual persists in disruptive behavior. 4.6.4. Interim Meetings In addition to mailing list discussion and meeting at the thrice- yearly IETF Meetings, a working group might decide that it should hold an additional, real-time "interim" meeting. This might be through a real-time chat session, group telephone call, online teleconference, or physical, face-to-face meeting. Guidance for the conduct of such sessions is provided by [Interim], with useful tutorial material at [Interim-Train]. Also see: Section 4.7. 4.7. Session Planning Administrative and process details for the conduct of structured meetings are referenced at [IETF-Meetings] and in [Interim] (Task) Sessions MUST be planned, organized and announced well in advance. (Task) For coordinated, structured WG interactions, a draft agenda SHOULD be published well in advance of the actual session. Details about Meeting Materials are provided in [MeetMaterials], [MeetMaterialTool]. Crocker & Droms Expires March 4, 2016 [Page 20]
Internet-Draft WG Guidelines & Procedures September 2015 4.8. Meeting Drafts and Documents NOTE: The requirements here apply to all IETF working group meetings, independent of venue or mode. That is, all official sessions during an IETF Week and all interims. (Task) All relevant documents to be discussed at a session SHOULD be published and available as Internet-Drafts at least two weeks before a session starts, so that working group participants have adequate time to review all documents. 4.9. Meeting Record Keeping NOTE: The requirements here apply to all IETF working group meetings, independent of venue or mode. That is, all official sessions during an IETF Week and all interims. The task(s) of creating records about meeting activity are discussed in [AgendaNotes], above. (Task) An attendance list MUST be circulated (Task) Notes of a session MUST be taken; they SHOULD include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees (Task) Immediately after a session, the WG Chair SHOULD provide the Area Director with a very short report (approximately one paragraph, via email) on the session. 5. Document Development & Lifecycle Working groups produce documents and documents need Writers. (Task) The Chair MUST make sure that Document Writers incorporate changes as agreed to by the WG. It is quite easy for active and productive writers to move into a dominant position, either making changes faster than the working group can absorb, or becoming adversarial with working group preferences. An especially conducive environment for this problem combines original (pre-working group) authors with a more passive working group. However a working group that does not fully and actively support a specification, the greater the risk that it will not achieve deployment and use. Crocker & Droms Expires March 4, 2016 [Page 21]
Internet-Draft WG Guidelines & Procedures September 2015 5.1. Basic Sequence Working group development of a document proceeds through these steps: 1. An individual or a group has something for the WG to discuss and publishes a document on the topic as an individual I-D 2. WG adopts the document as a WG work item, per section 2 of [RFC7221] 3. WG develops the document, per [RFC7221] 4. When the WG is done with development, the chairs organize a WG last call to determine consensus for sending the I-D to the IESG for review and publication 5. Chairs assign a document shepherd who prepares the cover sheet and assumes responsibility for managing the review and publication process 6. The Working Group, through the chairs or the shepherd, make a recommendation to the to the Area Director that a standards action be approved regarding the document [RFC 2026] 7. Area Director reviews the document to determine if the standards action should proceed; this review may include an external review, per [RFC2026] 8. Area Director formally requests an IETF Last Call to determine IETF consensus about whether the I-D is ready for publication, per [RFC2026] 9. Once the IETF Last Call is complete, the AD, the document shepherd, the editors and the WG agree on any changes to the I-D based on the Last Call comments 10. The AD schedules the I-D for discussion during an IESG telechat 11. Prior to the telechat, IESG members post a ballot position on the I-D 12. After the telechat, the I-D may require additional revision; the IESG, the document shepherd, the editors and the WG agree on any changes to the I-D based on the IESG ballot positions and telechat discussion Crocker & Droms Expires March 4, 2016 [Page 22]
Internet-Draft WG Guidelines & Procedures September 2015 13. Once the I-D meets the IESG ballot requirements for publication, the IETF is notified of any associated standards action and the document is forwarded to the RFC Editor 5.2. Early Document Review It is easier to make substantial changes to a specification during its early stages than it is later on. Periodically, the IETF's various late-stage reviews uncover basic concerns with assumptions or approaches in a design. When a working group is pursuing a solution that has unusual design choices or unusual operational characteristics, or has any other feature that might impede its success, or when the working group participants have less experience in producing specifications for Internet-scale use, it is advisable to recruit review and advice from a broad base of experts. 5.3. Document Coordination Between Working Groups A document is adopted by one working group as a deliverable; they are therefore responsible for its development, review and publication. (Section 3.5) When initiated outside a working group environment, the writer(s) usually have a specific -- possibly new -- working group in mind as the development home. However some documents address problems or contain technologies that span multiple Areas or working groups. In such cases, the document is assigned to one of these, with other interested groups participating in the development process. This joint participation can take many forms. One example is a joint Working Group Last Call conducted by the host group but announced on the mailing lists for the other interested groups. As an example, documents that extend DHCP to carry configuration information for other protocols often span multiple working groups. Some of these documents define a simple DHCP option that follows one of the option formats in section 5 of [RFC7227]. Such options can be developed in the working group responsible for the protocol that will use the option, without significant participation of the dhc working group. A joint last call between the two groups might be all that is required. However some documents will define options that have a significantly new option format, or define a new DHCP message or otherwise make a fundamental change to the semantics of DHCP message exchanges. These options or new messages will be developed in the dhc working group, with input from other interested groups, to ensure that there are no conflicts or other issues with the documents that would cause problems with the DHCP standards. Crocker & Droms Expires March 4, 2016 [Page 23]
Internet-Draft WG Guidelines & Procedures September 2015 5.4. Working Group Last-Call When a WG decides that a document is ready for publication it is submitted to the IESG for consideration. In most cases the determination that a WG feels that a document is ready for publication is done by the WG Chair issuing a working group Last- Call. The decision to issue a working group Last-Call is at the discretion of the WG Chair working with the Area Director. A working group Last-Call serves the same purpose within a working group that an IESG Last-Call does in the broader IETF community. ([RFC2026]) 5.5. Final External Review of Documents The IESG reviews all documents submitted for publication as RFCs. Usually minimal IESG review is necessary in the case of a submission from a WG intended as an Informational or Experimental RFC. More extensive review is undertaken in the case of standards-track documents. Prior to the IESG beginning their deliberations on standards-track documents, IETF Secretariat will issue a "Last-Call" to the IETF mailing list. ([RFC2026]) This Last Call will announce the intention of the IESG to consider the document, and it will solicit final comments from the IETF within a period of two weeks. It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review. The IESG review takes into account responses to the Last-Call and will lead to one of these possible conclusions: 1. The document is accepted as is for the status requested. This fact will be announced by the IETF Secretariat to the IETF mailing list and to the RFC Editor. 2. The document is accepted as-is but not for the status requested. This fact will be announced by the IETF Secretariat to the IETF mailing list and to the RFC Editor. (See [RFC2026] for more details.) 3. Changes regarding content are suggested to the Writer(s)/WG. Suggestions from the IESG need to be clear and direct, so as to facilitate working group and Writer correction of the specification. If the Writer(s)/WG can explain to the satisfaction of the IESG why the changes are not necessary, the document will be accepted for publication as under point 1, Crocker & Droms Expires March 4, 2016 [Page 24]
Internet-Draft WG Guidelines & Procedures September 2015 above. If the changes are made the revised document MAY be resubmitted for IESG review. 4. Changes are suggested by the IESG and a change in status is recommended. The process described above for 3 and 2 are followed in that order. 5. The document is rejected. Any document rejection will be accompanied by specific and thorough arguments from the IESG. Although the IETF and working group process is structured such that this alternative is not likely to arise for documents coming from a working group, the IESG has the right and responsibility to reject documents that the IESG feels are fatally flawed in some way. If any individual or group of individuals feels that the review treatment has been unfair, there is the opportunity to make a procedural complaint. The mechanism for this type of complaints is described in [RFC2026]. 6. Staff Roles From initial chartering, through document development and publication, ending with working group termination, there are tasks that are formally required to be done, while others are merely -- though often very -- helpful to do. This document discusses the formal tasks and many of the other, useful tasks. Working groups require considerable care and feeding. In addition to general participation, successful working groups benefit from the efforts of participants filling specific functional roles. Beyond a limited set of formal tasks, there are no rules about who MAY be assigned tasks internal to the working group. This section discusses possible mappings between working group tasks and working group participants who might be assigned roles for performing those tasks. However it is important to remember that such mappings are strictly at the discretion of the chairs, assuming working group agreement. [RFC2028] describes the roles of a number of individuals related to external aspects of working groups, as well including the working group chair and the document Writer. These descriptions are expanded later in this section. Crocker & Droms Expires March 4, 2016 [Page 25]
Internet-Draft WG Guidelines & Procedures September 2015 6.1. Development Document Writer: This role is discussed in Section 2.6. Design Team: It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Operationally, a design team typically is advisory to the Document Writer(s), specifically, or the working group discussion, generally. Design teams can range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair appoints to attack a controversial problem. The output of a design team always MUST be subject to approval, rejection or modification by the WG as a whole. Participant: Discuss issues. Suggest ideas and text. Review documents. Actively pursue resolution of topics. 6.2. Advice Adviser (WG Consultant): At the discretion of the Area Director or Chair, an Adviser MAY be assigned to a working group. Consultants have specific technical background appropriate to the WG and experience in Internet architecture and IETF process. An adviser's role is strictly advisory rather than authoritative. However of course their concerns are likely to gain the attention of reviewers, the Area Director and the IESG. 6.3. Process Area Director: This role is discussed in Section 2.4. Working Group Chair: This role is discussed in Section 2.5. WG Facilitator: When meetings tend to become distracted or divisive, it often is helpful to assign the task of "process management" to one participant. [Facilitate] Their job is to oversee the nature, rather than the content, of participant interactions. That is, they attend to the style of the discussion and to the schedule of the agenda, rather than making direct technical contributions themselves. WG Secretary: Taking notes, producing discussion summaries, and maintaining a list of working group action items are tasks often is performed by one or more designated participants. Crocker & Droms Expires March 4, 2016 [Page 26]
Internet-Draft WG Guidelines & Procedures September 2015 Scribe: A Scribe is tasked with note-taking during a meeting. This might be for real-time use during the session, such as providing quick summaries of on-going discussion via an instant- messaging channel, to assist remote participants. Or it might be basic meeting notes; these are typically summarizations of discussions, rather than detailed 'minutes'. [I-D-Jscribe] 7. WG External Administration 7.1. Working group Formation IETF working groups (WGs) are the primary means of developing IETF specifications and guidelines, many of which are intended to be standards or recommendations. Working groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.). Working groups are generally expected to be short-lived in nature. A working group is typically created by a community initiative, but can also be established at the initiative of an Area Director. Anyone interested in creating an IETF working group MUST obtain the advice and consent of IETF Area Director(s) and MUST proceed through the formal steps detailed in this section. 7.1.1. Criteria for formation When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues: Issues: Are the issues that the working group plans to address clear and relevant to the Internet community? Goals: Are the goals specific and reasonably achievable, and achievable within a reasonable time frame? Risks/Urgency: What are the risks and urgency of the work, to determine the level of effort required? WG Overlap: Do the working group's activities overlap with those of another working group? If so, it can still be appropriate to create the working group, but this question needs to be considered carefully by the Area Directors as subdividing efforts often dilutes the available technical expertise. Interest: Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)? Working groups require considerable effort, Crocker & Droms Expires March 4, 2016 [Page 27]
Internet-Draft WG Guidelines & Procedures September 2015 including management of the working group process, editing of working group documents, and contributing to the document text. IETF experience suggests that these roles typically cannot all be handled by one person; a minimum of four or five active participants in the management positions are typically required in addition to a minimum of one or two dozen people that will attend the working group meetings and contribute on the mailing list. NOTE: The interest needs to be broad enough that a working group would not be seen as merely the activity of a single vendor. Expertise: Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group? Market: Does a base of interested consumers (end-users) appear to exist for the planned work? Consumer interest can be measured by participation of end-users within the IETF process, as well as by less direct means. IETF Relevance: Does the IETF have a reasonable role to play in the determination of the technology? There are many Internet- related technologies that might be interesting to IETF participants but in some cases the IETF might not be in a position to effect the course of the technology in the "real world". This can happen, for example, if the technology is being developed by another standards body or an industry consortium. IPR: Are all known intellectual property rights relevant to the proposed working group's efforts issues understood? Real IETF Work: Is the proposed work plan an open IETF effort or is it an attempt to "bless" non-IETF technology where the effect of input from IETF participants might be limited? Existing Work: Is there a good understanding of any existing work that is relevant to the topics that the proposed working group is to pursue? This includes work within the IETF and elsewhere. SDO Overlap: Do the working group's goals overlap with known work in another standards body, and if so is adequate liaison in place? Considering the above criteria, the Area Director(s) will use their best judgment to decide whether to pursue formation of the group through the chartering process. Crocker & Droms Expires March 4, 2016 [Page 28]
Internet-Draft WG Guidelines & Procedures September 2015 7.1.2. Birds of a Feather (BOF) Often it is not clear whether an issue merits the formation of a working group. To facilitate exploration of the issues the IETF offers the possibility of a Birds of a Feather (BOF) session ([RFC5434]) as well as the early formation of an email list for preliminary discussion. In addition, a BOF can serve as a forum for a single presentation or discussion, without any intent to form a working group. A BOF is a session at an IETF meeting which permits "market research" and technical "brainstorming". Any individual MAY request permission to hold a BOF on a subject. The request MUST be filed with a relevant Area Director, and their approval MUST be obtained before a BOF can be scheduled. The person who requests the BOF MAY be asked to serve as Chair of the BOF. The Chair of the BOF is also responsible for providing a report on the outcome of the BOF. If the Area Director approves, the BOF is then scheduled by submitting a request to agenda@ietf.org with copies to the Area Director(s). A BOF description and agenda are required before a BOF can be scheduled. Available time for BOFs is limited, and BOFs are held at the discretion of the ADs for an area. The AD(s) MAY require additional assurances before authorizing a BOF. For example, o The Area Director MAY require the establishment of an open email list prior to authorizing a BOF. This permits initial exchanges and sharing of framework, vocabulary and approaches, in order to make the time spent in the BOF more productive. o The Area Director MAY require that there be a draft of the WG charter prior to holding a BOF. o The Area Director MAY require that a BOF not be held until an Internet-Draft describing the proposed technology has been issued so it can be used as a basis for discussion in the BOF. In general, a BOF on a particular topic is held only once -- ONE slot at one IETF Plenary meeting. Under unusual circumstances Area Directors MAY, at their discretion, allow a BOF to meet for a second time. BOFs are limited to a maximum of two meetings. Note that all other things being equal, WGs will be given priority for meeting space over BOFs. Also, occasionally BOFs might be held for other purposes than to discuss formation of a working group. Usually the outcome of a BOF will be one of the following: Crocker & Droms Expires March 4, 2016 [Page 29]
Internet-Draft WG Guidelines & Procedures September 2015 o There was enough interest and focus in the subject to warrant the formation of a WG o While there was a reasonable level of interest expressed in the BOF some other criteria for working group formation was not met, per Section 7.1.1 o The discussion came to a fruitful conclusion, with results to be written down and published, however there is no need to establish a WG o There was not enough interest in the subject to warrant the formation of a WG 7.1.3. Charter Development The formation of a working group requires a charter. Development of a charter results from the efforts of interested parties and an Area Director. The substance of IETF working group charters is specified in Section 7.2. The development of the proposed charter is overseen by a shepherding Area Director and can be pursued in a number of ways. The method of developing a charter can vary greatly. In many instances, the development of the charter is carried out on an open mailing list, allowing all interested IETF participants to contribute to the effort. Among other possibilities, charter development might driven by a small group of active proponents. All charter development models allow for interested participants to take ownership in the purpose and outcome of the working group. It is common, but not required, to hold an exploratory Birds of a Feather (BOF) meeting to gauge the level of support for a working group.([RFC5434],Section 7.1.2) Such a BOF can focus on formulating the problem to be solved, considering the key items in a proposed charter, discussing proposed solutions, or some combination of these items. When the prospective Chair(s), the Area Director and the IETF Secretariat are satisfied with the charter form and content, it becomes the foundation of the working group approval process and for the substantive conduct of the working group. 7.1.4. Charter review & approval Proposed working groups often include technically competent participants who are not familiar with the history of Internet Crocker & Droms Expires March 4, 2016 [Page 30]
Internet-Draft WG Guidelines & Procedures September 2015 architecture or IETF processes. This can, unfortunately, lead to good working group consensus about a bad design. (Task) To facilitate working group efforts, an Area Director MAY assign a Adviser from among the ranks of IETF participants. (Section 6) At the discretion of the Area Director, approval of a new WG MAY be withheld in the absence of sufficient Adviser resources. For review of a draft charter, the sponsoring Area Director might consult with their Area Directorate, or others, as deemed appropriate. Once an Area Director supports a version of the working group charter, the approval sequence then is: 1. In parallel: * The charter is submitted for review by the IAB * It is also submitted for approval by the IESG. 2. After a review period of at least a week, in parallel: * the proposed charter is posted to the IETF-announce mailing list as a public notice that the formation of the working group is being considered. * the proposed charter is also posted to the "new-work" mailing list. This mailing list has been created to let qualified representatives from other standards organizations know about pending IETF working groups. 3. After another review period lasting at least a week the IESG MAY approve the charter as-is, or it MAY request that changes be made in the charter, or MAY decline to approve chartering of the working group If the IESG approves the formation of the working group it remands the approved charter to the IETF Secretariat who records and enters the information into the IETF tracking database. The working group is announced to the IETF-announce a by the IETF Secretariat. 7.1.5. Milestones Revision The milestone list is expected to be updated periodically. Updated milestones are (re-)negotiated with the Area Director, as needed, and then are submitted to the IESG Secretariat: Crocker & Droms Expires March 4, 2016 [Page 31]
Internet-Draft WG Guidelines & Procedures September 2015 iesg-secretary@ietf.org 7.1.6. Rechartering a Working Group Charters MAY be renegotiated periodically to reflect the current status, organization or goals of the working group. Rechartering a working group follows the same procedures that the initial chartering does Section 7.1. 7.2. Charter Content Charter development and approval, rechartering, and milestone revision are discussed in Section 7.1. Examples working group charters are shown in Appendix B A charter consists of the following sections: Working group name: A working group name ought to be reasonably descriptive or identifiable. Additionally, the group needs to define an acronym (maximum 8 printable ASCII characters) to reference the group in the IETF directories, mailing lists, and general documents. Chair(s): The working group can have one or more Chairs to perform the administrative functions of the group. The email address(es) of the Chair(s) are included. Generally, a working group is limited to two chairs. (Optional) Other Staff: Optional positions, such as secretary and technical adviser. Area Director(s): The name of the IETF area with which the working group is affiliated and the name and electronic mail address of the associated Area Director(s). Responsible Area: Director The Area Director who acts as the primary IESG contact for the working group. Mailing list: An IETF working group MUST have a general Internet mailing list. The working group charter MUST include: * The address to which a participant sends a subscription request and the procedures to follow when subscribing, * The address to which a participant sends submissions and special procedures, if any, and Crocker & Droms Expires March 4, 2016 [Page 32]
Internet-Draft WG Guidelines & Procedures September 2015 * The location of the mailing list archive. For basic IETF requirements concerning mailing list configuration and use. (Section 2.3) Description of working group: The focus and intent of the group is set forth briefly. By reading this section alone, an individual should be able to decide whether this group is relevant to their own work. To facilitate evaluation of the intended work and to provide on- going guidance to the working group, the charter MUST describe the problem being solved and SHOULD discuss objectives and expected impact with respect to: * Architecture * Operations * Security * Network management * Scaling * Transition (where applicable) Goals and milestones: The working group charter MUST establish a timetable for specific work items. While this MAY be renegotiated over time, the list of milestones and dates facilitates the Area Director's tracking of working group progress and status, and it is indispensable to potential participants identifying the critical moments for input. Milestones MUST consist of deliverables that can be qualified as showing specific achievement; e.g., "Internet-Draft finished" is fine, but "discuss via email" is not. It is helpful to specify milestones for every 3-6 months, so that progress can be gauged easily. 7.3. Submission & Publication of Documents Once a WG has determined that rough consensus exists within the WG for the advancement of a document, the following MUST be done: Crocker & Droms Expires March 4, 2016 [Page 33]
Internet-Draft WG Guidelines & Procedures September 2015 (Task) The version of the relevant document exactly as agreed to by the WG MUST be in the Internet-Drafts directory, formatted according to Section 3.6 (Task) The WG Chair MUST initiate a publication request through the Datatracker entry for the document The copy of the message to the IESG Secretariat is to ensure that the request gets recorded by the Secretariat so that they can monitor the progress of the document through the process. Unless returned by the IESG to the WG for further development, progressing of the document is then the responsibility of the IESG. After IESG approval, responsibility for final disposition is the joint responsibility of the RFC Editor, the WG Chair and the Document Writer. The Chair and/or Document Editor will work with the RFC Editor to ensure document conformance with RFC publication requirements [RFC2223] and to coordinate any editorial changes suggested by the RFC Editor. A particular concern is that all participants are working from the same version of a document at the same time. 7.4. Working Group Termination Working groups are typically chartered to accomplish a specific task or tasks. Upon completion of its goals and achievement of its objectives, the working group is usually terminated. (A working group MAY also be terminated for other reasons, as discussed in Section 7.4.> If there is sufficient community interest the working group will formally become dormant rather than be disbanded -- the WG will no longer conduct formal activities -- so that the mailing list will remain available to review activities related to the working group's topic, including use and issues with documents it has produced. If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, or if the assumptions which that work was based have been modified in discussion or by experience, the Area Director, in consultation with the working group can either: o Recharter to refocus its tasks (See Section 7.1.6) o Choose new Chair(s) Crocker & Droms Expires March 4, 2016 [Page 34]
Internet-Draft WG Guidelines & Procedures September 2015 o Disband If the working group disagrees with the Area Director's choice, it MAY appeal to the IESG. Section 7.5 7.5. Contention and appeals Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved; however, there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, resolution of such conflicts MUST be pursued through a process of open review and discussion. Formal procedures for requesting a review of WG, Chair, Area Director or IESG actions and conducting appeals are documented in The Internet Standards Process [RFC2026]. 8. Security Considerations 9. References 9.1. References - Normative [AgendaNotes] "Formatting and Content of IETF Working Group Agendas and Minutes", <http://www.ietf.org/wg/agenda-minutes-procedures.html>. [IETF-Meetings] "IETF Meetings", <http://www.ietf.org/meeting/>. [Interim] "Interim Meetings", <http://www.ietf.org/meeting/interim-meetings.html>. [MeetMaterials] "Meeting Materials", <http://www.ietf.org/wg/meeting-materials.html>. [MeetMaterialTool] "The IETF Meeting Materials Management Tool", <http://www.ietf.org/old/2009/instructions/ meeting_materials_tool.html>. Crocker & Droms Expires March 4, 2016 [Page 35]
Internet-Draft WG Guidelines & Procedures September 2015 [MeetRequest] "Requesting Meeting Sessions at IETF Meetings", <http://www.ietf.org/old/2009/instructions/ MTG-SLOTS.html>. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", RFC 3995, March 2005. 9.2. References - Informative [About] "About the IETF", <http://www.ietf.org/about/>. [AD-Desc] "Area Director Qualifications", <http://trac.tools.ietf.org/group/iesg/trac/wiki/ AreasDescription>. [Areas] "Areas", <https://www.ietf.org/iesg/area.html>. [ChairGuide] "WG Chairs' Guide, http://wiki.tools.ietf.org/group/wgchairs/", <http://wiki.tools.ietf.org/group/wgchairs/>. [Facilitate] "Facilitation", <http://en.wikipedia.org/wiki/ Facilitation_%28business%29>. [I-D] "Internet-Drafts (I-Ds)", <https://www.ietf.org/id-info/>. [I-D-Guidelines] Russ, R., "Guidelines to Authors of Internet-Drafts", December 2010, <https://www.ietf.org/id-info/ guidelines.html>. [I-D-Jscribe] "The Jabber Scribe Role at IETF Meetings", I-D draft- saintandre-jabber-scribe. [Interim-Train] Atlas, A., Schliesser, B., and S. Turner, "Routing Area Chair Training: Interim Meetings", January 2015, <https://tools.ietf.org/area/rtg/trac/raw- attachment/wiki/WGChairTraining/rtgwg_train_4.pdf>. Crocker & Droms Expires March 4, 2016 [Page 36]
Internet-Draft WG Guidelines & Procedures September 2015 [MailList] "Email Lists", <http://www.ietf.org/list/>. [RFC-Editor] "RFC Editor", <http://www.rfc-editor.org/>. [RFC-IETF] "Request for Comments (RFC)", <http://www.ietf.org/rfc.html>. [RFC1603] Huizer, E. and D. Crocker, "IETF Working Group Guidelines and Procedures", RFC 1603, March 1994. [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995. [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [RFC5434] Narten, T., "Considerations for Having a Successful Birds- of-a-Feather (BOF) Session", RFC 5434, February 2009. [RFC7221] Farrel, A. and D. Crocker, "Handling of Internet-Drafts by IETF Working Groups", RFC 7221, April 2014. [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, May 2014. [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, June 2014. [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, September 2014. Crocker & Droms Expires March 4, 2016 [Page 37]
Internet-Draft WG Guidelines & Procedures September 2015 [Secretaries] Vigoureux, M. and D. King, "IETF Working Groups' Secretaries", I-D draft-secretaries-good-practices, November 2014. [Tao] "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", <http://www.ietf.org/tao.html>. [WG] "Working Groups", <http://www.ietf.org/wg/>. Appendix A. Acknowledgements The original version of this document was developed by Erik Huizer and Dave Crocker. ([RFC1603]) A revised version was edited by Scott Bradner and reviewed by the Poisson Working Group. ([RFC2418]) The current version was prompted by [Secretaries] and the vigorous IETF discussion that ensued. In their typical fashion, the IETF Secretariat staff were extremely helpful in clarifying current IETF administrative practices and rules. Development of the initial version of this document's revision benefited greatly from thoughtful and diligent comments by: Fred Baker, Brian Carpenter, Brian Haberman, Melinda Shore. Appendix B. Sample Working Group Charters NOTE: Can we get a better example? This example does not completely conform to wg charter requirements, especially for the first paragraph of the description. /d B.1. DPRIVE DNS PRIVate Exchange (dprive) Group Name: DNS PRIVate Exchange Acronym: dprive Area: Internet Area (int) Charter: charter-ietf-dprive-01 (Approved) Personnel Chairs: Tim Wicinski <tjw.ietf@gmail.com> Warren Kumari <warren@kumari.net> Area Director: Brian Haberman <brian@innovationslab.net> Mailing List Address: dns-privacy@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy Archive: http://www.ietf.org/mail-archive/web/dns-privacy/ Jabber Chat Room Address: xmpp:dprive@jabber.ietf.org Logs: http://jabber.ietf.org/logs/dprive/ Crocker & Droms Expires March 4, 2016 [Page 38]
Internet-Draft WG Guidelines & Procedures September 2015 Charter for Working Group The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring (RFC 7258). The set of DNS requests that an individual makes can provide an attacker with a large amount of information about that individual. DPRIVE aims to deprive the attacker of this information. (The IETF defines pervasive monitoring as an attack [RFC7258]) The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. Some of the results of this working group may be experimental. The Working Group will also develop an evaluation document to provide methods for measuring the performance against pervasive monitoring; and how well the goal is met. The Working Group will also develop a document providing example assessments for common use cases. DPRIVE is chartered to work on mechanisms that add confidentiality to the DNS. While it may be tempting to solve other DNS issues while adding confidentiality, DPRIVE is not the working group to do this. DPRIVE will not work on any integrity-only mechanisms. Examples of the sorts of risks that DPRIVE will address can be found in [draft-bortzmeyer-dnsop-dns-privacy], and include both passive wiretapping and more active attacks, such as MITM attacks. DPRIVE will address risks to end-users' privacy (for example, which websites an end user is accessing). Some of the main design goals (in no particular order) are: - Provide confidentiality to DNS transactions (for the querier). - Maintain backwards compatibility with legacy DNS implementations. - Require minimal application-level changes. - Require minimal additional configuration or effort from applications or users Milestones Dec 2014 WG LC on an problem statement document draft-bortzmeyer-dnsop-dns-privacy Mar 2015 Crocker & Droms Expires March 4, 2016 [Page 39]
Internet-Draft WG Guidelines & Procedures September 2015 WG selects one or more primary protocol directions Jul 2015 WG LC on primary protocol directions B.2. iptel Working Group Name: IP Telephony (iptel) IETF Area: Transport Area Chair(s): Jonathan Rosenberg <jdrosen@bell-labs.com> Transport Area Director(s): Scott Bradner <sob@harvard.edu> Allyn Romanow <allyn@mci.net> Responsible Area Director: Allyn Romanow <allyn@mci.net> Mailing Lists: General Discussion:iptel@lists.research.bell-labs.com To Subscribe: iptel-request@lists.research.bell-labs.com Archive: http://www.bell-labs.com/mailing-lists/siptel Description of Working Group: Before Internet telephony can become a widely deployed service, a number of protocols must be deployed. These include signaling and capabilities exchange, but also include a number of "peripheral" protocols for providing related services. The primary purpose of this working group is to develop two such supportive protocols and a frameword document. They are: 1. Call Processing Syntax. When a call is setup between two endpoints, the signaling will generally pass through several servers (such as an H.323 gatekeeper) which are responsible for forwarding, redirecting, or proxying the signaling messages. For example, a user may make a call to j.doe@bigcompany.com. The signaling message to initiate the call will arrive at some server at bigcompany. This server can inform the caller that the callee is busy, forward the call initiation request to another server closer to the user, or drop the call completely (among other possibilities). It is very desirable to allow the callee to provide input to this process, guiding the server in its decision on how to act. This can enable a wide variety Crocker & Droms Expires March 4, 2016 [Page 40]
Internet-Draft WG Guidelines & Procedures September 2015 of advanced personal mobility and call agent services. Such preferences can be expressed in a call processing syntax, which can be authored by the user (or generated automatically by some tool), and then uploaded to the server. The group will develop this syntax, and specify means of securely transporting and extending it. The result will be a single standards track RFC. 2. In addition, the group will write a service model document, which describes the services that are enabled by the call processing syntax, and discusses how the syntax can be used. This document will result in a single RFC. 3. Gateway Attribute Distribution Protocol. When making a call between an IP host and a PSTN user, a telephony gateway must be used. The selection of such gateways can be based on many criteria, including client expressed preferences, service provider preferences, and availability of gateways, in addition to destination telephone number. Since gateways outside of the hosts' administrative domain might be used, a protocol is required to allow gateways in remote domains to distribute their attributes (such as PSTN connectivity, supported codecs, etc.) to entities in other domains which must make a selection of a gateway. The protocol must allow for scalable, bandwidth efficient, and very secure transmission of these attributes. The group will investigate and design a protocol for this purpose, generate an Internet Draft, and advance it to RFC as appropriate. Goals and Milestones: May 98 Issue first Internet-Draft on service framework Jul 98 Submit framework ID to IESG for publication as an RFC. Aug 98 Issue first Internet-Draft on Call Processing Syntax Oct 98 Submit Call processing syntax to IESG for consideration as a Proposed Standard. Dec 98 Achieve consensus on basics of gateway attribute distribution protocol Jan 99 Submit Gateway Attribute Distribution protocol to IESG for consideration as a RFC (info, exp, stds track TB B.3. rtg Working Group Name: Routing Over Low power and Lossy networks Acronym: roll Area: Routing Area (rtg) Charter: charter-ietf-roll-03 (Approved) Personnel Chairs: Ines Robles <maria.ines.robles@ericsson.com> Michael Richardson <mcr+ietf@sandelman.ca> Crocker & Droms Expires March 4, 2016 [Page 41]
Internet-Draft WG Guidelines & Procedures September 2015 Area Director: Adrian Farrel <adrian@olddog.co.uk> Tech Advisor: Rene Struik <rstruik.ext@gmail.com> Delegates: Robert Cragie <robert.cragie@gridmerge.com> Yvonne-Anne Pignolet <yvonneanne.pignolet@gmail.com> Mailing List Address: roll@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/roll Archive: http://www.ietf.org/mail-archive/web/roll/ Jabber Chat Room Address: xmpp:roll@jabber.ietf.org Logs: http://jabber.ietf.org/logs/roll/ Charter for Working Group Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. LLNs are transitioning to an end-to-end IP-based solution to avoid the problem of non-interoperable networks interconnected by protocol translation gateways and proxies. Generally speaking, LLNs have at least five distinguishing characteristics: - LLNs operate with a hard, very small bound on state. - In most cases, LLN optimize for saving energy. - Typical traffic patterns are not simply unicast flows (e.g. in some cases most if not all traffic can be point to multipoint) - In most cases, LLNs will be employed over link layers with restricted frame-sizes, thus a routing protocol for LLNs should be specifically adapted for such link layers. - LLN routing protocols have to be very careful when trading off efficiency for generality; many LLN nodes do not have resources to waste. These specific properties cause LLNs to have specific routing requirements. Existing routing protocols such as OSPF, IS-IS, AODV, and OLSR have been evaluated by the working group and have in their current form been found to not satisfy all of these specific routing requirements. The Working Group is focused on routing issues for LLN. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (HVAC, lighting, access control, fire), connected homes, healthcare, environmental monitoring, urban sensor networks (e.g. Smart Grid), asset tracking. The Working Group focuses Crocker & Droms Expires March 4, 2016 [Page 42]
Internet-Draft WG Guidelines & Procedures September 2015 on routing solutions for a subset of these: industrial, connected home, building and urban sensor networks for which routing requirements have been specified. These application-specific routing requirement documents will be used for protocol design. The Working Group focuses only on IPv6 routing architectural framework for these application scenarios. The Framework will take into consideration various aspects including high reliability in the presence of time varying loss characteristics and connectivity while permitting low-power operation with very modest memory and CPU pressure in networks potentially comprising a very large number (several thousands) of nodes. The Working Group will pay particular attention to routing security and manageability (e.g., self routing configuration) issues. It will also need to consider the transport characteristic the routing protocol messages will experience. Mechanisms that protect an LLN from congestion collapse or that establish some degree of fairness between concurrent communication sessions are out of scope of the Working Group. It is expected that upper-layer applications utilizing LLNs define appropriate mechanisms. The solution must include unicast and multicast considerations. Work Items: - Specification of routing metrics used in path calculation. This includes static and dynamic link/node attributes required for routing in LLNs. - Provide an architectural framework for routing and path selection at Layer 3 (Routing for LLN Architecture) that addresses such issues as whether LLN routing require a distributed and/or centralized path computation models, whether additional hierarchy is necessary and how it is applied. Manageability will be considered with each approach, along with various trade-offs for maintaining low power operation, including the presence of non-trivial loss and networks with a very large number of nodes. should - Produce a routing security framework for routing in LLNs. - Protocol work: The Working Group will consider specific routing requirements from the four application documents collectively, and specify either a new protocol or extend an existing routing protocol in cooperation Crocker & Droms Expires March 4, 2016 [Page 43]
Internet-Draft WG Guidelines & Procedures September 2015 with the relevant Working Group. If requirements from the four target application areas cannot be met with a single protocol, the WG may choose to specify or extend more than one protocol (this will require a recharter of the WG). - Documentation of applicability statement of ROLL routing protocols. Milestones Done Submit Routing requirements for Industrial applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Connected Home networks applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Building applications to the IESG to be considered as an Informational RFC. Done Submit Routing requirements for Urban networks applications to the IESG to be considered as an Informational RFC. Done Submit Security Framework to the IESG to be considered as an Informational RFC Done Submit Routing metrics for LLNs document to the IESG to be considered as a Proposed Standard. Done Submit first draft of ROLL routing protocol specification as Proposed Standard. Done Submit the ROLL routing protocol specification to the IESG as Proposed Standard. Done Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC Done WG to adopt RPL applicability statement Home for Automation applications draft-ietf-roll-applicability-home-building Done WG to adopt RPL applicability statement(s) for AMI networks draft-ietf-roll-applicability-ami Done WG to adopt RPL applicability statement for Industrial applications draft-ietf-roll-rpl-industrial-applicability Done WG to adopt reviewed template for applicability statements draft-ietf-roll-applicability-template Done Resolve question of whether to keep this in roll or 6tisch draft-ietf-roll-rpl-industrial-applicability Done submit REVISED thread-analysis document based upon security directorate review to IESG. draft-ietf-roll-security-threats Feb 2014 Submit first draft of RPL applicability statement for Home Automation applications to the IESG to be considered as an Informational RFC Crocker & Droms Expires March 4, 2016 [Page 44]
Internet-Draft WG Guidelines & Procedures September 2015 Done Evaluate WG progress, recharter or close Aug 2014 WG to joint-LC using flow-label for RPL with 6man draft-thubert-6man-flow-label-for-rpl B.4. another one Appendix C. [PROTO-WIKI] Working Group Advice NOTE TO RFC EDITOR: Prior to publication, this section is to be moved to an IETF wiki page, for on-going enhancement. ALSO: The document's reference to this section needs to be modified to refer to that wiki. C.1. If you have a formal WG role... Here is some basic advice to anyone performing working group administrative or management dutues -- that is, anyone assigned tasks by the AD or a chair: o Re-read "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force" [Tao]. You've already read it at least once, right? o Read [RFC7282]. No, really, I know you say you've read it; go read it again. Be sure you know what "rough consensus" is, how it can be identified and how it is used in the IETF. Pay particular attention to its extended discussion of the handling of 'minority' views. C.2. Advice for Chairs o Become familiar with: [ChairGuide] o Some WGs do work that requires interaction and cooperation with other standards bodies. WG administrative staff should be aware of the possibility of such interactions, as formally described regarding IEEE in RFC 7241 and ITU-T in RFC 6756. The IETF has established a formal liaison role for some of these interactions, as defined in RFC 4691. RFC 4929 describes a specific (and historically interesting) example of interaction between the IETF and ITU-T. o Handling Internet-Drafts as part of the activities of Working Groups is summarized in RFC 2418bis and described in detail in RFC Crocker & Droms Expires March 4, 2016 [Page 45]
Internet-Draft WG Guidelines & Procedures September 2015 7241. The states that a WG document can take are defined in RFC 6174. o The co-chairs are responsible for behavior of WG participants as part of the IETF. RFC 7154 can help to identify and deal with unacceptable behavior. o Intellectual property rights (IPR) management is crucial to the IETF and has been the source of serious legal issues in the past. Read RFC 6702 to understand the IETF disclosure rules and how to make sure your WG stays in compliance with those rules. Also read RFC 6701 to learn how you can deal with IPR policy violations. C.3. Meetings C.3.1. WG meeting preparation C.3.1.1. Request meeting slot(s) A WG will typically meet once during an IETF meeting. The chairs may choose to request two slots if the WG has a long agenda. Requesting more than two slots requires approval of the Area Director. The request will include the expected length, number of participants and a list of other WGs with which time conflicts should be avoided. These specific requests should be considered carefully as they are important for successful scheduling. C.3.1.2. Create and post agenda Well before the meeting, the WG administration posts a request for proposed discussion items, presentations and other agenda items to the WG mailing list. The WG administration collects the requests for agenda items and adds other agenda items as required for WG operation and posts a draft agenda for WG review. Once the final agenda is ready, the WG administration posts it through the IETF Meeting Materials manager web page. C.3.1.3. Post meeting materials Any documents to be discussed at the WG meeting must be posted two weeks before the meeting. The IESG Secretariat enforces an I-D publication restriction during the two weeks before the IETF meeting. Crocker & Droms Expires March 4, 2016 [Page 46]
Internet-Draft WG Guidelines & Procedures September 2015 Any presentations or other materials should be posted through to the IETF Meeting Materials at least a week before the IETF meeting to provide participants an opportunity to review those materials. C.3.1.4. Other meeting prep There are minute takers and jabber scribes at every WG meeting. It can save time at the meeting to identify individuals to fill those roles prior to the meeting. C.3.2. WG meeting operation * Confirm meeting room logistics: AV equipment, presentation materials, etc. * Pass around attendance records ("blue sheets") * Bash the agenda * WG status update * Proceed through the agenda * Record significant consensus calls, process actions, technical decisions C.3.3. WG Meeting Followup * Deliver a one paragraph summary of the meeting, including significant consensus calls, process actions, technical decisions, for the Area Director before the end of the IETF meeting * Prepare notes, using notes, jabber log and audio recording of the meeting; once the notes are ready, post the notes to the IETF Meeting Materials C.4. Ongoing WG operation C.4.1. Managing Individual Documents Documents typically go through several revisions in the process of WG development and review. The datatracker is used to manage and publish the state of an I-D as it progresses toward publication. WG administration coordinates the editing of the document by the editors with the input from the WG. The issues tracker is a useful tool for recording and managing specific issues with an I-D. Crocker & Droms Expires March 4, 2016 [Page 47]
Internet-Draft WG Guidelines & Procedures September 2015 The document shepherd manages the processing and publication of the document after it has been submitted by the WG to the IESG for publication. The issues tracker can be useful at this stage of the publication process as well. C.4.2. Charter Management * The WG administration reviews and periodically updates the WG milestones. Authors' Addresses Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA Phone: +1.408.246.8253 Email: dcrocker@bbiw.net Ralph Droms (editor) Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 Email: rdroms@cisco.com Crocker & Droms Expires March 4, 2016 [Page 48]