RFC 1603

IETF Working Group Guidelines and Procedures 🎀

Okay bestie, RFC 1603 is giving "how the IETF actually runs its working groups" energy 💅✨. Here's the title-block tea: it's from the Network Working Group, dated March 1994, and it's Informational 🌸. The authors are E. Huizer (SURFnet bv) and D. Crocker (Silicon Graphics, Inc.). The header doesn't list anything it obsoletes or updates 🧚.

Status of this Memo 🫶

Lowkey the most important vibe check: this memo is here to provide information for the Internet community. It does not specify an Internet standard of any kind 🙈. Distribution is unlimited, so pass it around as much as you like 🦋.

Abstract 💜

Okay so the Internet Engineering Task Force (IETF) is the crew responsible for developing and reviewing specifications meant to become Internet Standards 👑. Its activities are organized into working groups (WGs) 🌈. This doc covers the guidelines and procedures for forming and running IETF working groups, and it spells out the formal relationship between IETF participants, the WG, and the Internet Engineering Steering Group (IESG) 🧚. It also defines the basic duties of IETF participants, including the WG Chair and IESG Area Directors 💖.

Table of Contents 📋

   1.   INTRODUCTION..............................................  2
     1.1. IETF approach to standardization........................  3
     1.2. Acknowledgments.........................................  4
   2.   WORKING GROUP (WG) FORMATION..............................  5
     2.1. Criteria for formation..................................  5
     2.2. Charter.................................................  6
     2.3. Charter review & approval...............................  9
     2.4. Birds of a feather (BOF)................................  9
   3.   WORKING GROUP OPERATION................................... 11
     3.1. Session planning........................................ 11
     3.2. Session venue........................................... 12
     3.3. Session management...................................... 14
     3.4. Contention and appeals overview......................... 15
   4.   WORKING GROUP TERMINATION................................. 16
   5.   STAFF ROLES............................................... 17
     5.1. WG Chair................................................ 17
     5.2. WG Editor/Secretary..................................... 19
     5.3. WG Facilitator.......................................... 19
     5.4. Design teams............................................ 19
     5.5. Area Consultant......................................... 19
     5.6. Area Director........................................... 20
     5.7. Area Directorate........................................ 21
   6.   WORKING GROUP DOCUMENTS................................... 21
     6.1. Session documents....................................... 21
     6.2. IETF meeting document archive........................... 21
     6.3. Internet-Drafts (I-D)................................... 23
     6.4. Request For Comments (RFC).............................. 24
     6.5. Submission of documents................................. 24
     6.6. Review of documents..................................... 25
   7.   SECURITY CONSIDERATIONS................................... 26
   8.   REFERENCES................................................ 26
   9.   AUTHORS' ADDRESSES........................................ 27
   APPENDIX:  SAMPLE WORKING GROUP CHARTER........................ 28

1. INTRODUCTION 🌸

This doc lays out the guidelines and procedures for Internet Engineering Task Force working groups 💅. The Internet is a loosely-organized international collaboration of autonomous, interconnected networks. It supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards, a collection of which is commonly known as "the TCP/IP protocol suite" 🧚. The Internet Standards Process is defined in [1]. Development and review of potential Internet Standards from all sources is conducted by the Internet Engineering Task Force (IETF).

The IETF is a large, open community of network designers, operators, vendors, users, and researchers who care about the Internet and the technology used on it 🫶. It's managed by the Internet Engineering Steering Group (IESG). That group includes an IETF Chair, who oversees general IETF operations, and Area Directors, each responsible for a set of IETF activities and working groups 👑. The IETF Executive Director and IESG Secretary are ex-officio participants, as are the IAB Chair and a designated Internet Architecture Board (IAB) member. At present there are 10 areas, though the number and purview of areas change over time:

            User Services               (USV)
            Applications                (APP)
            Service Applications        (SAP)
            Transport Services          (TSV)
            Internet                    (INT)
            Routing                     (RTG)
            Network Management          (MGT)
            Operational Requirements    (OPS)
            Security                    (SEC)
            Standards & Processes       (STD)

Most areas have an advisory group or directorate. The specific name and the details of each group's role differ from area to area, but the main goal is for the group to assist the Area Director, e.g., with the review of specifications produced in the area 🦋. An advisory group is formed by an Area Director (AD) and is made up of experienced members of the IETF and the technical community represented by the area. A small IETF Secretariat provides staff and administrative support for the operation of the IETF.

The primary activities of the IETF happen in committees known as working groups. There are currently more than 60 of these 🌈. Working groups tend to have a narrow focus and a lifetime bounded by completion of a specific task, although there are exceptions.

There is no formal membership in the IETF. Participation is open to all 💖. It can happen online, at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to join IETF meetings and any of its online working group discussions. Participation is by individual technical contributors, rather than by formal representatives of organizations.

This document defines procedures and guidelines for forming and operating working groups in the IETF. It defines the relations of working groups to other bodies within the IETF, and it also defines the duties of working group Chairs and Area Directors with respect to the operation of the working group. The document uses "shall", "will", "must" and "is required" for steps in the process that are essential. For guidelines that are not essential but are strongly recommended to help smooth WG operation, it uses "suggested", "should" and "may" ✨.

1.1. IETF approach to standardization 💖

Bestie, go read The Internet Standards Process [1] 📚. Knowing that doc is essential if you want the full picture of the philosophy, procedures and guidelines in this one 🧠.

Here's how [1] sums up the goals:

"In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. ... "In outline, the process of creating an Internet Standard is straightforward: a specification undergoes a period of development and several iterations of review by the Internet community and perhaps revision based upon experience, is adopted as a Standard by the appropriate body (see below), and is published. "In practice, the process is somewhat more complicated, due to (1) the number and type of possible sources for specifications; (2) the need to prepare and revise a specification in a manner that preserves the interests of all of the affected parties; (3) the importance of establishing widespread community agreement on its technical content; and (4) the difficulty of evaluating the utility of a particular specification for the Internet community. ... "These procedures are explicitly aimed at developing and adopting generally-accepted practices. Thus, a candidate for Internet standardization is implemented and tested for correct operation and interoperability by multiple, independent parties, and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard."

The IETF standardization process has been marked by informality. As the community of participation has grown, it has become necessary to document procedures, while continuing to avoid unnecessary bureaucracy 🌸. The goals of this balancing act are summarized in [1] as:

"The procedures that are described here provide a great deal of flexibility to adapt to the wide variety of circumstances that occur in the Internet standardization process. Experience has shown this flexibility to be vital in achieving the following goals for Internet standardization: - high quality, - prior implementation and testing, - openness and fairness, and - timeliness."

1.2. Acknowledgments 🫶

Much of this document is due to the copy-and-paste function of a word processor 💀. Several passages have been taken from the documents cited in the reference section. The POISED WG provided discussion and comments. Three people deserve special mention, as especially large chunks of their documents have been integrated into this one: Vint Cerf [7], from whom we borrowed the description of the IETF; and Greg Vaudreuil and Steve Coya, who provided several paragraphs. Also, John Stewart and Steve Crocker did a truly stellar job of proof-reading. However, all the errors you'll find are probably ours 🙈.

2. WORKING GROUP (WG) FORMATION 🎀

IETF working groups (WGs) are the primary mechanism for developing IETF specifications and guidelines, many of which are intended as standards or recommendations 🔥. A working group can be established at the initiative of an Area Director (AD), or it can be started by an individual or a group of individuals. Anyone interested in creating an IETF working group MUST obtain the advice and consent of the appropriate IETF Area Director under whose direction the working group would fall, and MUST proceed through the formal steps detailed in this section 👑.

A working group is typically created to address a specific problem or produce a deliverable (a guideline, standards specification, etc.), and it is expected to be short-lived in nature. Upon completion of its goals and achievement of its objectives, the working group as a unit is terminated. Alternatively, at the discretion of the IESG, Area Director, the WG Chair and the WG participants, the objectives or assignment of the working group can be extended by enhancing or modifying the working group's charter 🦋.

2.1. Criteria for formation ✨

okay so before anyone gets to make a whole new working group, the Area Director and the IESG are gonna check a few things 👀

• Are the issues the group wants to tackle clear and relevant for the Internet community? 🌍
• Are the goals specific and reasonably achievable, and achievable within the time frame the milestones set out? 🎯
• What are the risks and urgency of the work? That tells everyone how much attention it needs 🚨
• Does the group's work overlap with another working group's? If it does, a new group can still be a good idea, but the Area Directors have to think about this one really carefully, because splitting efforts often dilutes the technical expertise that's available 🤔
• Is there enough interest and expertise in the topic, with at least several people willing to put in the work to produce the result (like a protocol specification)? Working groups are a LOT of work: running the group's process, editing its documents, and writing the document text. IETF experience says one person can't usually cover all of that, so four or five active participants are typically required 💪
• Does there seem to be a base of interested consumers (end users) for the planned work? You can see consumer interest when end users show up and take part in the IETF process, and also through less direct signs 🛍️

Considering all of the above, the Area Director decides whether to take the idea forward through the chartering process 📝

2.2. Charter ✍️

Making a working group takes a charter. It's mostly hashed out between a prospective working group Chair and the relevant Area Director, but the IESG gives the final approval, and every charter gets reviewed by the Internet Architecture Board (IAB) 💌 A charter is basically a contract between a working group and the IETF to carry out a set of tasks. A charter:

1. Lists the relevant administrative aspects of the working group;
2. Specifies the direction or objectives of the working group and describes the approach that will be taken to achieve the goals; and
3. Enumerates a set of milestones together with time frames for their completion.

Once the prospective Chair, the Area Director and the IESG Secretary are happy with the charter's form and content, it becomes the basis for forming the working group. The AD may ask for an initial draft of a charter to exist before an exploratory Birds of a Feather (BOF) meeting, as described below 🦋

Charters can get renegotiated now and then to match the group's current status, organization or goals. So yeah, a charter is a contract between the IETF and the working group, where the group commits to hitting explicit milestones and delivering concrete "products" 📦

Specifically, each charter has 6 sections:

Working group name

A working group name should be reasonably descriptive or identifiable. The group also shall 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 may have one or two Chair(s) to handle the administrative functions of the group. The email address(es) of the Chair(s) shall be included 📬

Area and Area Director(s)

This section names the IETF area the working group belongs to, plus the name and electronic mail address of the associated Area Director 🗺️

Mailing list

It is required that an IETF working group have a general Internet mailing list. Most of the work of an IETF working group will be conducted that.

The charter shall 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
• The location of the mailing list archive, if any.

A message archive should be kept in a public place that can be reached via FTP. Being able to retrieve from the archive via electronic mail requests is also recommended. Additionally, the address:

ietf-archive@cnri.reston.va.us

shall be included on the mailing list 💌

NOTE: It is strongly suggested that the mailing list be on a host directly connected to the IP Internet, so the SMTP expansion command (EXPN) can be used and mail archives can be accessed via FTP, gopher and the like. That fits the general IETF rule for openness 🔓 If this is not possible, the message archive and membership of the list must be made available to those who request it by sending a message to the list-request alias.

Description of working group

The focus and intent of the group shall be set out briefly. Someone should be able to read this section alone and decide whether the group is relevant to their own work 👀 The first paragraph must give a brief summary of the problem area, basis, goal(s) and approach(es) planned for the working group. This paragraph will often be used as an overview of the group's effort ✨

The terms "they", "them" and "their" are used in this document as third-person singular pronouns. 🧚

To make the intended work easy to evaluate and give the working group ongoing guidance, the charter shall describe the problem being solved and shall discuss objectives and expected impact with respect to:

• Architecture
• Operations
• Security
• Network management
• Transition (where applicable)

Goals and milestones

The working group charter must set a timetable for the work ⏰ It can be renegotiated over time, but the list of milestones and dates is what lets the Area Director track progress and status, and it's essential for potential participants who want to know the critical moments for input. Milestones shall be deliverables that show a specific achievement. For example, "Internet-Draft finished" is fine, but "discuss via email" is not 🙅 It helps to set milestones every 3-6 months so progress is easy to gauge. The milestone list is expected to be updated periodically. Updated milestones get renegotiated with the Area Director and the IESG as needed, and then they get sent to the IESG Secretary:

IESG-secretary@cnri.reston.va.us

An example of a WG charter is in Appendix A. 🎀

2.3. Charter review & approval 🔍

Working groups often have technically competent people who aren't familiar with the history of Internet architecture or IETF processes, and that can unfortunately lead to a group reaching good consensus about a bad design 😬 To help out, an Area Director may assign an Area Consultant from the ranks of senior IETF participants. (Area Consultants are described in the section of Staff Roles.) At the AD's discretion, approval of a new WG may be withheld if there aren't enough Consultant resources.

Once the Area Director (and the Area Directorate, if the AD thinks that's right) has approved the charter, it gets submitted for review by the IAB and approval by the Internet Engineering Steering Group, using the criteria described previously 📋

The Internet Architecture Board (IAB) reviews the proposed WG's charter to figure out how the proposed work relates to the overall architecture of the Internet Protocol Suite 🏗️

The approved charter goes to the IESG Secretary, who records it and enters the information into the IETF tracking database. The database then returns the charter in a form it has formatted. Finally, the IESG Secretary announces the working group to the IETF mailing list 📣

2.4. Birds of a feather (BOF) 🐦

Sometimes it isn't clear whether an issue deserves a working group at all. To explore issues like that, the IETF offers Birds of a Feather (BOF) sessions, plus early email lists for preliminary discussion. A BOF can also just be a forum for one presentation or discussion, with no plan to form a working group 💬

A BOF is a session at an IETF meeting where you can do "market research" and technical "brainstorming" 🧠 Anyone can ask to hold a BOF on a subject. The request must be filed with the relevant Area Director. The person who asks for the BOF is usually appointed as its Chair, and the BOF Chair is also responsible for reporting on the BOF's outcome 📝

The AD may require email discussion before authorizing a BOF. That lets people share framework, vocabulary and approaches, so the time spent in the BOF is more productive ⏳ The AD may also require that a BOF be held before a working group is established, and the AD may require that there be a draft of the WG charter before a BOF is held.

Usually, a BOF ends in one of these outcomes:

• There was enough interest and focus in the subject to warrant the formation of a WG;
• The discussion came to a fruitful conclusion, with results to be written down and published, however there is no need to establish a WG; or
• There was not enough interest in the subject to warrant the formation of a WG.

BOF sessions are in higher demand at IETF meetings than ever 📈 So the following rules apply to BOFs:

• All BOFs must have the approval of the appropriate Area Director. The Secretariat will NOT schedule or allocate time slots without the explicit approval of the Area Director 🚫
• The purpose of a BOF is to conduct a single, brief discussion or to ascertain interest and establish goals for a working group. All BOF organizers are required to submit a brief written report of what happened during the BOF session, together with a roster of attendees, to the IESG Secretary for inclusion in the Proceedings 📚
• A BOF may be held only once (ONE slot at one IETF Plenary meeting).
• Under unusual circumstances an Area Director may, at their discretion, allow a BOF to meet for a second time. Typically (though not a requirement) this is to develop a charter to be submitted to the IESG.
• BOFs are not permitted to meet three times.
• A BOF may be held for single-event discussion, or it may pursue creating normal IETF working groups for ongoing interactions and discussions. When the request for a BOF comes from a formally-constituted group rather than an individual, the rules for handling the request are the same as for all other BOFs and working groups 🤝
• When necessary, WGs will be given priority for meeting space over BOFs. WGs get the spotlight 🌈

3. WORKING GROUP OPERATION 🎀

Okay so the IETF has basic rules about open and fair participation and about really thinking through every technical option 💅. Inside those limits, working groups are autonomous, which means each one decides most of the details of how it runs, like how sessions work and how it wraps things up ✨. The core rule is that acceptance or agreement happens through working group "rough consensus" 🫶.

A bunch of procedural questions will pop up over time, and it's the Working Group Chair's job to manage the group process 👑. The big goal to keep in mind is that the whole group exists to make progress toward rough consensus while hitting its goals and objectives 🧚.

There are very few hard and fast rules for organizing or running WG activities, but a set of guidelines and practices has evolved over time and actually works 🙌. They're listed here, though the real choices are usually made by the WG participants and the Chair 🌸.

3.1. Session planning 📋

For coordinated, structured WG interactions, the Chair must publish a draft agenda well in advance of the actual session 🗓️. The agenda needs to contain at least:

• The items for discussion;
• The estimated time necessary per item; and
• A clear indication of what documents the participants will need to read before the session in order to be well prepared 📚.

Publication shall include sending a copy to the working group mailing list and to the IETF-Announce list. Notices for the IETF-Announce list should be sent to:

ietf-announce-post@cnri.reston.va.us

All working group actions shall be taken in a public forum, and wide participation is encouraged 📣. A working group will do much of its business over electronic mail distribution lists 💌, but it may meet periodically to discuss and review task status and progress, to resolve specific issues, and to direct future activities 🦋. It is common, but not required, that a working group will meet at the trimester IETF Plenary events 🍓. Interim sessions may also be scheduled for telephone conference, video teleconference, or face-to-face (physical) sessions 📞.

All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available 📝. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair 🙈. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings and for posting in the IETF Directories, and they are to be sent to:

minutes@cnri.reston.va.us

3.2. Session venue 🏡

Each working group will decide the balance of email and face-to-face sessions that's right for hitting its milestones ⭐. Email is the most inclusive option, since it lets the widest group of people take part 🌈. Face-to-face meetings often give better focus, so they can be more efficient for reaching consensus among the core group of WG participants 💜. When figuring out that balance, the WG must make sure its process doesn't shut out contribution from email-only participants 🫶. Also, decisions reached during IETF meetings are NOT final. They must be shared on the mailing list so the WG can verify consensus 🔥.

IETF Meetings ✈️

If a WG needs a session at an IETF meeting, the Chair must apply for time slots as soon as the IETF Secretariat makes the first announcement of that IETF meeting to the WG-chairs list ⏰. Session time is a scarce resource at IETF meetings, so the earlier you place requests, the easier it is to coordinate schedules for WGs that need the same set of experts 🧚.

The application for a WG session at an IETF meeting shall be made to the IETF Secretariat. Some Area Directors may also want to coordinate WG sessions in their area, and request that time slots be coordinated through them 🎀. After receiving all of the time slot requests from WGs in the area, the Area Director(s) form a draft session agenda for their area, which is then sent to the WG chairs of that area. Once it's approved, it goes to the IETF Secretariat 💅.

An application must contain:

• The amount of time requested;
• The rough outline of the WG agenda that is expected to be covered;
• The estimated number of people that will attend the WG session;
• Related WGs that must not be scheduled for the same time slot(s); and
• Individuals whose attendance is desired 🍓.

The Secretariat allots time slots based on the session agenda made by the Area Director(s) 🗂️. If the proposed session agenda for an area doesn't fit into the IETF meeting agenda, the IETF Secretariat will adjust it to fit, after consulting the Area Director(s) and the relevant chairs 🧩. The Secretariat will then form a draft session agenda and distribute it among the Working Group Chairs for final approval 💖.

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. The Working Group Chair then has the authority to refuse to grant the floor to any individual who is unprepared or otherwise covering inappropriate material 🙅‍♀️.

On-line 💻

It can be super useful to run email exchanges the same way you'd run a face-to-face session, with a published schedule and agenda, plus ongoing summarization and consensus polling 📊.

Lots of WG participants think the mailing list is the best place to talk through issues, resolve them, and make decisions 💌. The WG itself picks its operational style. It's worth noting, though, that Internet email discussion can reach a much wider base of interested people than attending IETF meetings can, because attending takes a lot of time and money ✨.

3.3. Session management 🗳️

Working groups make decisions through a "rough consensus" process 🌸. IETF consensus doesn't require that every participant agrees, though that's of course preferred 🫶. In general, the dominant view of the working group shall prevail. (However, "dominance" is not to be determined on the basis of volume or persistence, but rather on a more general sense of agreement 🙄.) Consensus can be determined by balloting, humming, or any other means the WG agrees on (by rough consensus, of course) 🎶.

Managing a WG session is a balancing act: the group has to weigh 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 that balance. The Chair oversees the process but may delegate direct process management to a formally designated Facilitator 🧚.

Sometimes it makes sense to revisit a topic, re-evaluate alternatives, or improve the group's understanding of a relevant decision 🔁. Still, you can avoid unnecessary repeated discussions if the Chair makes sure the main arguments (and the outcome) get summarized and archived once a discussion has concluded 🗃️. It's also good practice to note important decisions or consensus reached by email in the minutes of the next "live" session, and to briefly summarize the decision-making history in the final documents the WG produces 📝.

To keep things moving, a Working Group Chair may want to steer a discussion toward rejecting or deferring a member's input, based on the following criteria 🚦:

• Old: The input pertains to a topic that has already 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;
• 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 💅.

3.4. Contention and appeals overview

okay so bestie, strife happens 💀 In group design processes it's basically guaranteed, especially when a working group has a whole bunch of different constituencies in the room 🙈 Strife and contention are most likely in exactly that situation. BUT, and this is a big but ✨, differences in view are vital to the success of the IETF, so healthy debate is totally encouraged 🫶 Sometimes debates go full warfare 😭 For those moments, the IETF has an extensive review and appeals process 💅

Formal procedures for requesting review and conducting appeals are documented in The Internet Standards Process [1]. Here's the quick version though 🦋

In fact the IETF approach to reviews and appeals is quite simple 💖 When an IETF participant feels that matters have not been conducted properly, they SHOULD state their concern to a member of IETF management. So basically the process relies on people who have concerns actually raising them 🙌 If the result isn't satisfactory, there are several levels of appeal available, to ensure that review is possible by a number of people uninvolved in the matter in question 🎀

Reviews and appeals step through four levels, each in turn 👑

WG Chair

An appeal MUST begin with the management closest to the operation of the working group, even if the concern applies to their own handling of working group process 🧚

Area

If discussion and review with the WG Chair do not produce a satisfactory result, the complainant MAY bring their concern to the cognizant Area Director 🌸

IESG

If a concerned party is not satisfied with the results of the area-level review, then they MAY bring the matter to the IESG Chair and the Area Director for Standards & Processes. The IESG Chair and the Standards & Processes AD will bring the issue before the full IESG for an additional review and will report the resolution back to the parties 💜

IAB

The IAB provides a final opportunity to appeal the results of previous reviews. If a concerned party does not accept the outcome of the IESG review, then they MAY take their concern to the IAB, by contacting the IAB Chair ✨

Concerns entail either a disagreement with technical decisions by the working group or with the process by which working group business has been conducted. Technical disagreements MAY be about specific details or about basic approach. When an issue pertains to preference, it SHOULD be resolved within the working group. When a matter pertains to the technical adequacy of a decision, review is encouraged whenever the perceived deficiency is noted. For matters having to do with preference, working group rough consensus will dominate 🍓

When a matter pertains to working group process, it is important that those with a concern be clear about the manner in which the process was not open or fair, and that they be willing to discuss the issue openly and directly. In turn, the IETF management will make every effort to understand how the process was conducted, what deficiencies were present (if any) and how the matter SHOULD be corrected. The IETF functions on the good will and mutual respect of its participants, so continued success requires continued attention to working group process 🫶🌈

---

4. WORKING GROUP TERMINATION ✨

Working groups are typically chartered to accomplish a specific task. After that task is complete, the group will be disbanded. However, if a WG produces a Proposed or Draft Standard, the WG will become dormant rather than disband (i.e., the WG will no longer conduct formal activities, but the mailing list will remain available to review the work as it moves to Draft Standard and Standard status.) 🦋

If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, the group, in consultation with its Area Director, can either:

1. Recharter to refocus on a smaller task,
2. Choose new Chair(s), or
3. Disband.

If the working group disagrees with the Area Director's choice, it MAY appeal to the IESG 💅

---

5. STAFF ROLES 🎀

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 👑

5.1. WG Chair

The Working Group Chair is concerned with making forward progress through a fair and open process, and has wide discretion in the conduct of WG business. The Chair MUST ensure that a number of tasks are performed, either directly or by others assigned to the tasks. This encompasses at the very least the following:

Ensure WG process and content management

The Chair has ultimate responsibility for ensuring that a working group achieves forward progress and meets its milestones. 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 Editor to one or two participants. Often, they also are part of the design team, described below. 🧠

Moderate the WG email list

The Chair SHOULD attempt to ensure that the discussions on this list are relevant and that they converge to consensus agreements. The Chair SHOULD make sure that discussions on the list are summarized and that the outcome is well documented (to avoid repetition). The Chair also MAY choose to schedule organized on-line "sessions" with agenda and deliverables. These are structured as true meetings, conducted over the course of several days (to allow participation across the Internet). Participants are expected to allocate time to the meeting, usually in the range of 1-2 hours per day of the "meeting" ⏰

Organize, prepare and chair face-to-face & on-line formal sessions

The Chair SHOULD plan and announce sessions well in advance. (See section on Session Planning for exact procedures.) 📣

Communicate results of sessions

The Chair and/or Secretary MUST ensure that minutes of a session are taken and that an attendance list is circulated. See the section on Session Documents for detailed procedures.

Immediately after a session, the WG Chair MUST immediately provide the Area Director with a very short report (approximately one paragraph, via email) on the session. This is used in an Area Report as presented in the Proceedings of each IETF meeting. 📝

Distribute the work

Of course each WG will have participants who MAY 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. 💪

Document development

Working groups produce documents, and documents need authors. The Chair will make sure that authors of WG documents incorporate changes as discussed by the WG. See the section on Session Documents for details procedures. ✍️

Document publication

The Chair and/or Secretary will work with the RFC Editor to ensure document conformance with RFC publication requirements 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. 🔍

5.2. WG Editor/Secretary

Taking minutes and editing working group documents is often performed by a specifically designated participant or set of participants. In this role, the Editor's job is to record WG decisions, rather than to perform basic specification. 📒

5.3. WG Facilitator

When meetings tend to become distracted or divisive, it often is helpful to assign the task of "process management" to one participant. 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. 🫧

5.4. Design teams

The majority of the detailed specification effort within a working group MAY be done by self-selecting sub-groups, called design teams, with the (implicit or explicit) approval of the working group. The team MAY hold closed sessions for conducting portions of the specification effort. In some cases design teams are necessary to make forward progress when preparing a document. All work conducted by a design team MUST be available for review by all working group participants, and the design team MUST be responsive to the direction of the working group's consensus. 🤝

5.5. Area Consultant

At the discretion of the AD, a Consultant MAY be assigned to a working group. Consultants are senior participants in the IETF community. They have technical background appropriate to the WG and experience in Internet architecture and IETF process. 🌟

5.6. Area Director

Area Directors are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF. This very general description encompasses at the very least these detailed tasks related to working groups: 🗂️

Area planning

The Area Director determines activities appropriate to the area. This MAY include initiating working groups directly, rather than waiting for proposals from IETF participants.

Coordination of WGs

The Area Director coordinates the work done by the various WGs within (and sometimes even outside) the relevant area.

IETF Meeting Schedule

The Director tries to coordinate sessions in such a way that experts can attend the relevant sessions with a minimum of overlap and gaps between sessions. (See section on WG sessions for details.) 🗓️

Reporting

The Area Director reports to the IETF on progress in the area.

Reviewing

The Area Director MAY appoint independent reviewers prior to document approval. The Area Director tracks the progress of documents from the area through the IESG review process, and reports back on this to the WG Chair(s). 🔎

Progress tracking

The Area Director tracks and manages the progress of the various WGs with the aid of a regular status report on documents and milestones that is generated by the IESG Secretary. The Area Director forwards this report to the WG chairs. This in turn helps the chairs to manage their WGs. 📊

5.7. Area Directorate

An area directorate consists of senior members of the technical community and is appointed by the Area Director, who then tasks them with technical oversight and review of specific area activities. An Area Director chairs the directorate. At the request of the AD, directorate members conduct specification reviews and MAY be assigned as Area Consultants, to provide architectural assistance. 🦄

---

6. WORKING GROUP DOCUMENTS 📜

6.1. Session documents ✨

okay bestie, the big rule here: all the relevant docs for a session (including the final agenda) SHOULD be published and available at least two weeks before the session starts 📅💖. Get ahead of it, no cap!

It is strongly suggested that the WG Chair make sure an anonymous FTP directory is ready for the upcoming session 🧚. All relevant documents (including the final agenda and the minutes of the last session) SHOULD be placed in this directory 📂. The vibe is that everyone can FTP every file in there and double-check they've got everything 🫶. It's also helpful to offer electronic mail-based retrieval for those docs 📬.

6.2. IETF meeting document archive 🗂️

Prepping for an IETF meeting is so much easier when you can reach every doc being reviewed 🙈. Right now they're scattered everywhere: some in the internet-drafts Internet Repository, some in WG archives, and some just dropped on mailing lists. There are literally too many things to browse, and a bunch of docs get changed right before a meeting 😭.

The InterNIC Directory and Database Services runs a current-ietf-docs archive so people can grab everything relevant for the upcoming IETF meeting 🎀. This database gets removed two weeks after the IETF meeting 🗑️.

The completeness of this archive depends on authors and WG Chairs submitting docs 🙌. Each WG Chair is requested to submit the agenda to this archive 📋.

Structure of the archive:

Docs on ds.internic.net get stored under the right WG name, under the right area name, in this directory:

/pub/current-ietf-docs

Each area also has a bof directory for docs to be discussed in a BOF meeting 🌸. At the area level, a plenary directory gets created for docs or presentation material related to a plenary session 🦋. If filenames clash, the InterNIC's administrator sorts it out and lets the submitter know by email 📧. Examples:

/pub/current-ietf-docs/app/osids
/pub/current-ietf-docs/int/sip

Access via anonymous FTP:

Anon FTP to ds.internic.net and change directory to:

/pub/current-ietf-docs/

then browse and grab the doc you want 🧁.

Access via gopher:

Connect to gopher.internic.net and select the menu item:

4.  InterNIC Directory and Database Services (AT&T)/

and then the menu item:

3.  Documents to be reviewed at the *** IETF

You can also use the public-access gopher client by running:

telnet gopher.internic.net

Submission of documents via anonymous FTP:

FTP to ds.internic.net and log in as anonymous. Change directory to:

/incoming/current-ietf-docs

Put the doc using this filename convention:

<area>.<wgname>.<filename>

e.g.:

plenary.mondayVGs.ps
app.osids.agenda
app.osids.internic-talk-VGs.ps

Note that area and WG names are their official short-form acronyms 🔤.

Submission of documents via electronic mail:

Send mail to:

admin@ds.internic.net

with this subject line:

IETF - <area>.<wgname>.<filename>

e.g.:

IETF - app.osids.agenda

NOTE: Instead of sending a fresh copy of a doc that's already available, you MAY ask the InterNIC's administrators to create a link to an existing internet-draft/RFC/ID 🔗.

NOTE: If you don't remember your area or WG acronym, grab the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous FTP 🙏.

6.3. Internet-Drafts (I-D) 📝

The Internet-Drafts directory is there for WGs to post and share early copies of WG docs 💌. It's replicated at various locations around the Internet 🌐. Posting early is encouraged as soon as a doc is reasonably stable 🚀.

Here's the important tea: Internet-Drafts are working documents with no official standards status whatsoever 🚫. They might eventually turn into a standards-track doc, or they might sink from sight 🫠. I-Ds get submitted to:

internet-drafts@cnri.reston.va.us

The format of an Internet-Draft MUST be the same as for an RFC [2]. Also, an I-D MUST contain:

• Beginning, standard, boilerplate text which is provided by the Secretariat;
• The I-D filename; and
• The expiration date for the I-D.

The complete specification of requirements for an Internet-Draft is found in the file 1id-guidelines.txt in the internet-drafts directory at an Internet Repository site 🗺️.

6.4. Request For Comments (RFC) 📜

The work of an IETF WG usually results in one or more docs published as part of the Request For Comments (RFCs) [2] series 💫. This series is the archival publication record for the Internet community 🏛️. A doc can be written by an individual in a WG, by a group as a whole with a designated Editor, or by others not involved with the IETF 🙋. The designated author doesn't have to be the group Chair(s) ✨.

NOTE: The RFC series is a publication mechanism only, and publication does not determine the IETF status of a doc. Status is determined through separate, explicit status labels assigned by the IESG on behalf of the IETF. In other words, all Internet Standards are published as RFCs, but NOT all RFCs specify standards. 🤯

For a description of the various RFC categories, the reader is referred to [1, 4, 5, 6] 📚.

6.5. Submission of documents 📤

When a WG decides a doc is ready for publication, the following MUST be done:

• The version of the relevant doc as approved by the WG MUST be in the Internet-Drafts directory;
• The relevant doc MUST be formatted according to RFC rules [2].
• The WG Chair sends email to the relevant Area Director, with a copy to the IESG Secretary. The mail SHOULD contain the reference to the doc, and the request that it be progressed as an Informational, Experimental, Prototype or standards-track (Proposed, Draft or Internet Standard) RFC 📨.

The IESG Secretary will acknowledge receipt of the email 👀. Unless it's returned to the WG for further development, progressing the doc is then the responsibility of the IESG. After IESG approval, responsibility for final disposition is the joint responsibility of the RFC Editor and the WG Chair and Editor 🤝.

6.6. Review of documents 🔍

Usually, a submission intended as an Informational or Experimental RFC only needs minimal review. However, if the WG or the RFC Editor thinks an extensive review is appropriate, the Area Director MAY be asked to conduct one. This review MAY either be done by the AD and other IESG participants, or the IESG MAY ask for an independent review (e.g., by someone not part of the WG in question) from the Area Directorate or elsewhere 🕵️‍♀️.

A review will lead to one of three possible conclusions:

1. The document is accepted as is.

This fact will be announced by the IESG Secretary to the IETF mailing list and to the RFC Editor. Publication is then handled between the RFC Editor and the author(s) 🎉.

2. Changes regarding content are suggested to the author(s)/WG.

Suggestions MUST be clear and direct, so the WG and author(s) can fix the specification easily 🛠️. Once the author(s)/WG have made these changes, or have explained to the satisfaction of the reviewers why the changes aren't necessary, the document will be accepted for publication as under point 1, above 💅.

3. The document is rejected.

This will need strong and thorough arguments from the reviewers. The whole IETF and WG process is structured so this outcome is not likely to come up for docs coming from a WG 🙅‍♀️. After all, the intentions of the document will already have been described in the WG charter, and reviewed at the start of the WG 📋.

If any individual or group feels the review treatment has been unfair, there's the opportunity to make a procedural complaint. The mechanism for procedural complaints is described in the section on Contention and Appeal ⚖️.

Before the IESG makes a final decision on a standards-track document, the IESG Secretary will issue a "Last Call" to the IETF mailing list 📣. This Last Call will announce the IESG's intention to consider the document, and it will solicit final comments from the IETF within a period of two weeks ⏳. It's important to note that a Last Call is intended as a brief, final check with the Internet community, to make sure no important concerns have been missed or misunderstood 🔎. The Last Call cannot serve as a more general, in-depth review 🙅‍♀️.

7. SECURITY CONSIDERATIONS 😱

Plot twist: this whole section is one sentence. Security issues are not discussed in this memo. 💀

8. REFERENCES 📚

[1] Internet Architecture Board and Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", RFC 1602, IAB, IESG, March 1994.

[2] Postel, J., "Instructions to RFC Authors", RFC 1543, USC/Information Sciences Institute, October 1993.

[3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to the F.Y.I. Notes", RFC 1150, Proteon, USC/Information Sciences Institute, March 1990.

[4] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311, USC/Information Sciences Institute, March 1992.

[5] Postel, J., Editor, "Internet Official Protocol Standards", STD 1, RFC 1600, IAB, March 1994.

[6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May 1990.

9. AUTHORS' ADDRESSES 💌

Erik Huizer
SURFnet bv
P.O. Box 19035
3501 DA  Utrecht
The Netherlands

Phone: +31 30 310290
Fax: +31 30 340903
EMail: Erik.Huizer@SURFnet.nl


Dave Crocker
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
P.O. Box 7311
Mountain View, CA 94039

Phone: +1 415 390 1804
Fax: +1 415 962 8404
EMail: dcrocker@sgi.com

APPENDIX: SAMPLE WORKING GROUP CHARTER 🎀

okay bestie, last stop! this appendix is a sample charter for a working group called mmusic. it's basically the whole game plan: who's running it, where people talk, what they're building, and when they plan to hit each milestone 🦋

        Multiparty Multimedia Session Control (mmusic)

        Charter

        Chair(s):
            Eve Schooler  <schooler@isi.edu>
            Abel Weinrib  <abel@bellcore.com>

        Transport Area Director(s)
            Allison Mankin  <mankin@cmf.nrl.navy.mil>

        Mailing lists:
            General Discussion:confctrl@isi.edu
            To Subscribe:      confctrl-request@isi.edu
            Archive:           venera.isi.edu:~/confctrl/confcrtl.mail

Description of Working Group

the demand for internet teleconferencing has shown up, but the infrastructure to back it up is barely there yet 😭 multimedia session control is one piece of that infrastructure. it means managing and coordinating multiple sessions, their multiple users, and multiple media (like audio and video). the Multiparty Multimedia Session Control Working Group is chartered to design and specify a protocol that handles these jobs 💖

the protocol will negotiate session membership, the underlying communication topology, and the media configuration ✨ specifically, it'll support a user starting a multimedia multiparty session with other users over the Internet (the "calling" part). it does this by letting a teleconferencing app on one workstation explicitly rendezvous with teleconferencing apps running on remote workstations. a standard protocol means different teleconferencing implementations can actually interoperate at the session level 🫶

the group is focusing on a session negotiation protocol built for tightly-controlled conferences. right now the MBONE mostly carries loosely-controlled sessions. those are sessions with little to no interaction among members, no arbitration facility, no security, and no coordination of quality-of-service options for time-critical media 💀 users can find sessions with the sd utility or other out-of-band stuff, like email. but there's clearly also a need for tightly-controlled sessions. these give you mechanisms for directly contacting other users to start a session, and for negotiating conference parameters like membership, media encodings, and encryption keys. these sessions should also support renegotiation during a session, for example to add or delete members or change the media encoding. in the limiting case, the protocol might also support loosely-controlled sessions 🌸

the main goal is to specify the session control protocol for use within teleconferencing software over the Internet. the group will focus on the parts of the session control problem that are well understood, while keeping an eye on evolving research issues 👑 to that end, the group has made an inventory of existing conferencing systems and their session control protocols. it will document the requirements of the existing prototypes as a basis for protocol development, and it will iteratively refine the protocol based on implementation and operational experience 🌈

the group will also coordinate with other multimedia conferencing efforts. that includes directory services for cataloguing users and conferences, the RTP and RTCP protocols developed by the Audio/Video Transport Working Group, resource reservation and management at the network level, and schemes for multicast address allocation 🧚

Goals and Milestones

here's the timeline, bestie. no skipping ahead 📅

            May 93     Hold an on-line working group meeting to discuss
                       the conference control framework, the relevant
                       terminology, a functional taxonomy and how
                       different conversational styles place
                       requirements on session protocols.

            Jun 93     Submit the Conference Session Control Protocol to
                       the IESG for consideration as an Experimental
                       Protocol.

            Aug 93     Post an Internet-Draft describing the Session
                       Control Requirements.

            Nov 93     Post an Internet-Draft of the Session Control
                       Protocol.

            Mar 94     Submit a revised Internet-Draft based on
                       implementation experience.

---

that's the whole charter, iykyk 💅🦋