RFC 2418

IETF Working Group Guidelines and Procedures

📅 published September 1998, from ietf

IETF Working Group Guidelines and Procedures 🎀

Okay bestie, let's start with the basics 💅

RFC 2418 is titled IETF Working Group Guidelines and Procedures. S. Bradner wrote it as the Editor, from Harvard University, and it's dated September 1998. It's a Best Current Practice (BCP 25) and it obsoletes RFC 1603 🦋. It doesn't list anything it updates.

Status of This Memo 📜

This doc specifies an Internet Best Current Practice for the whole Internet Community 🌈, and it's literally asking everyone to discuss it and suggest improvements. Distribution is unlimited, so share away 💖.

The Internet Society holds the copyright for 1998, and all rights are reserved 🔒. The notice reads Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract ✨

So the IETF is responsible for developing and reviewing specifications meant to become Internet Standards 🔥. Its work happens in working groups (WGs) 🧚. This doc covers the guidelines and procedures for forming and running IETF working groups, plus the formal relationship between IETF participants, WGs, and the Internet Engineering Steering Group (IESG). It also covers the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors 👑.

Table of Contents 🗂️

Abstract .........................................................  1
1. Introduction ..................................................  2
  1.1. IETF approach to standardization ..........................  4
  1.2. Roles within a Working Group ..............................  4
2. Working group formation .......................................  4
  2.1. Criteria for formation ....................................  4
  2.2. Charter ...................................................  6
  2.3. Charter review & approval .................................  8
  2.4. Birds of a feather (BOF) ..................................  9
3. Working Group Operation ....................................... 10
  3.1. Session planning .......................................... 11
  3.2. Session venue ............................................. 11
  3.3. Session management ........................................ 13
  3.4. Contention and appeals .................................... 15

4. Working Group Termination ..................................... 15
5. Rechartering a Working Group .................................. 15
6. Staff Roles ................................................... 16
  6.1. WG Chair .................................................. 16
  6.2. WG Secretary .............................................. 18
  6.3. Document Editor ........................................... 18
  6.4. WG Facilitator ............................................ 18
  6.5. Design teams .............................................. 19
  6.6. Working Group Consultant .................................. 19
  6.7. Area Director ............................................. 19
7. Working Group Documents ....................................... 19
  7.1. Session documents ......................................... 19
  7.2. Internet-Drafts (I-D) ..................................... 19
  7.3. Request For Comments (RFC) ................................ 20
  7.4. Working Group Last-Call ................................... 20
  7.5. Submission of documents ................................... 21
8. Review of documents ........................................... 21
9. Security Considerations ....................................... 22
10. Acknowledgments .............................................. 23
11. References ................................................... 23
12. Editor's Address ............................................. 23
Appendix:  Sample Working Group Charter .......................... 24
Full Copyright Statement ......................................... 26

1. Introduction ✨

The Internet is a loosely organized, international collab of autonomous, interconnected networks 🌐. It supports host-to-host communication because everyone voluntarily sticks to the open protocols and procedures defined by Internet Standards. There are also plenty of isolated interconnected networks that aren't hooked up to the global Internet but still use Internet Standards 🧩. Those standards get developed in the Internet Engineering Task Force (IETF). This doc defines the guidelines and procedures for IETF working groups 💅. The Internet Standards Process of the IETF is defined in [1] 📖. The organizations involved in that process are described in [2], and so are the roles of specific individuals 🫶.

The IETF is a huge, open community of network designers, operators, vendors, users, and researchers who care about the Internet and the tech running on it 🌸. Its main work happens in committees called working groups. There are currently more than 100 of them 🤯. (Check the IETF web page for an up-to-date list of working groups at http://www.ietf.org.) Working groups usually have a narrow focus and a lifetime that ends when a specific set of tasks is done, though there are exceptions 🍓.

To keep things organized, working groups are grouped into areas, and each area has its own focus. For example, the security area handles security-related technology 🔐. Each area is managed by one or two Area Directors (ADs). There are currently 8 areas, but that number changes from time to time 🦋. (The IETF web page lists the current areas, their Area Directors, and which working groups belong to each area.)

Lots of areas have an advisory group or directorate formed by their Area Directors 🧠. These are made up of experienced IETF members and people from the technical community that the area represents. The name and role of each group vary from area to area, but the main goal is to help the Area Director(s), for example by reviewing specifications produced in the area 👑.

The IETF area directors are picked by a nominating committee, which also picks an overall IETF chair. The nominations process is described in [3] 🗳️.

The area directors, plus the IETF Chair, form the Internet Engineering Steering Group (IESG) 🌟. The IETF Executive Director sits on the IESG ex officio, and so do the IAB Chair and a designated Internet Architecture Board (IAB) liaison 💜. The IESG approves IETF Standards and approves publication of other IETF documents (see [1]) ✅.

A small IETF Secretariat gives staff and admin support so the IETF can run 🧚.

There's no formal membership in the IETF. Participation is open to everyone 🎉. You can take part online, in person at face-to-face sessions, or both. Anyone in the Internet community with the time and interest is encouraged to join IETF meetings and any of the online working group discussions 🫶. Participation is by individual technical contributors, not by formal representatives of organizations.

This doc sets out the procedures and guidelines for forming and running working groups in the IETF 🎀. It defines how working groups relate to other bodies within the IETF, and it also defines the duties of working group Chairs and Area Directors when it comes to running a working group. When this document uses the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", they're interpreted as described in RFC 2119 [6] 🔑. RFC 2119 explains how these key words are used so the intent of standards track documents is as clear as possible 💖. This doc uses the same key words to keep WG operation smooth and cut down on confusion about the processes ✨.

1.1. IETF approach to standardization 🧩

You really need to be familiar with The Internet Standards Process [1] to fully get the philosophy, procedures, and guidelines in this doc 📚.

1.2. Roles within a Working Group 🎭

The document "Organizations Involved in the IETF Standards Process" [2] describes the roles of a bunch of people within a working group, including the working group chair and the document editor 💁. This doc expands on those descriptions later on ✨.

2. Working group formation 🌷

IETF working groups (WGs) are the main way IETF specifications and guidelines get developed, and many of them are meant to become standards or recommendations 🏆. A working group can be set up at the initiative of an Area Director, or it can be started by one person or a group of people. Anyone who wants to create an IETF working group MUST get the advice and consent of the IETF Area Director(s) for the area the working group would fall under, and MUST go through the formal steps detailed in this section 🫡.

Working groups are usually created to tackle a specific problem or to produce one or more specific deliverables (a guideline, a standards specification, etc.) 🎯. They're generally expected to be short-lived 🦋. Once the group meets its goals and objectives, it gets terminated. A working group can also be terminated for other reasons (see section 4) 🥀. Alternatively, with the agreement of the IESG, the Area Director, the WG Chair, and the WG participants, the objectives or assignment of the working group can be extended by changing its charter through a rechartering process (see section 5) 🔄.

2.1. Criteria for formation ✨

okay so before a working group even gets off the ground, the Area Director(s) and the IESG run it through a whole vibe check 💅 They're looking at a bunch of things:

  • Are the issues that the working group plans to address clear and relevant to the Internet community?
  • Are the goals specific and reasonably achievable, and achievable within a reasonable time frame?
  • What are the risks and urgency of the work, to determine the level of effort required?
  • Do the working group's activities overlap with those of another working group? If so, it may still be appropriate to create the working group, but this question must be considered carefully by the Area Directors as subdividing efforts often dilutes the available technical expertise.
  • 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, 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 must be broad enough that a working group would not be seen as merely the activity of a single vendor.
  • Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group?
  • 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.
  • Does the IETF have a reasonable role to play in the determination of the technology? There are many Internet-related technologies that may be interesting to IETF members but in some cases the IETF may 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.
  • Are all known intellectual property rights relevant to the proposed working group's efforts issues understood?
  • 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 may be limited?
  • 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.
  • 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), using his or her best judgement, will decide whether to pursue the formation of the group through the chartering process. 🔥

2.2. Charter 🎀

so a working group needs a charter, and it's mostly negotiated between the prospective working group Chair and the relevant Area Director(s). The IESG gives the final approval, with advice from the Internet Architecture Board (IAB). Think of a charter as a contract between a working group and the IETF to get a set of tasks done 🤝 A charter:

  1. Lists relevant administrative information for 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.

When the prospective Chair(s), the Area Director and the IETF Secretariat are satisfied with the charter form and content, it becomes the basis for forming a working group. Note that an Area Director MAY require holding an exploratory Birds of a Feather (BOF) meeting, as described below, to gage the level of support for a working group before submitting the charter to the IESG and IAB for approval.

Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group (see section 5). Hence, a charter is a contract between the IETF and the working group which is committing to meet explicit milestones and delivering specific "products". 🌸

Specifically, each charter consists of the following sections:

  • Working group name: A working group name should be reasonably descriptive or identifiable. Additionally, the group 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 more Chairs to perform the administrative functions of the group. The email address(es) of the Chair(s) shall be included. Generally, a working group is limited to two chairs.
  • Area and 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. Most of the work of an IETF working group will be conducted on the mailing list. The working group charter MUST include:
    1. The address to which a participant sends a subscription request and the procedures to follow when subscribing,
    2. The address to which a participant sends submissions and special procedures, if any, and
    3. The location of the mailing list archive. 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 wg_acronym-archive@lists.ietf.org (where wg_acronym is the working group acronym) in the mailing list in order that a copy of all mailing list messages be recorded in the Secretariat's archive. Those archives are located at ftp://ftp.ietf.org/ietf-mail-archive. For robustness, WGs SHOULD maintain an additional archive separate from that maintained by the Secretariat.

  • Description of working group: The focus and intent of the group shall be set forth briefly. By reading this section alone, an individual should be able to decide whether this 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 can be used as an overview of the working group's effort.

To facilitate evaluation of the intended work and to provide ongoing 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 shall 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. This milestone list is expected to be updated periodically (see section 5).

An example of a WG charter is included as Appendix A.

2.3. Charter review & approval 🦋

proposed working groups are often full of technically brilliant people who don't know the history of Internet architecture or how IETF processes work 🧠 and that can, unfortunately, lead to good working group consensus about a bad design 😭 To help out, an Area Director may assign a Consultant from among the ranks of senior IETF participants. (Consultants are described in section 6.) At the discretion of the Area Director, approval of a new WG may be withheld in the absence of sufficient consultant resources.

Once the Area Director (and the Area Directorate, as the Area Director deems appropriate) has approved the working group charter, the charter is submitted for review by the IAB and approval by the IESG. After a review period of at least a week 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. At the same time 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. After another review period lasting at least a week the IESG MAY approve the charter as-is, 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.

2.4. Birds of a Feather (BOF) 🦋

Sometimes you just can't tell if an issue is big enough to deserve its own working group 🤔 So the IETF gives you a way to explore first: a Birds of a Feather (BOF) session, plus an early email list for preliminary chatting. A BOF can also be a one-off spot for a single talk or discussion, with no plan to form a WG at all 💅

A BOF is a session at an IETF meeting for "market research" and "brainstorming" 🧠✨ Anyone can ask to hold one on a topic. The request MUST be filed with a relevant Area Director, and that AD has to approve the BOF before it can go on the schedule. The person who asked for it might also get asked to Chair it 👑

The BOF Chair is also on the hook for writing up a report on how the BOF went 📝 If the Area Director says yes, the BOF gets scheduled by sending a request to agenda@ietf.org, with copies to the Area Director(s). A BOF description and agenda are both required before anything can be scheduled 🗓️

Time for BOFs is limited, so the ADs for an area decide who gets one 🙈 They can ask for extra assurances before they sign off. For example:

  • 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.
  • The Area Director MAY require that a BOF be held, prior to establishing a working group (see section 2.2).
  • The Area Director MAY require that there be a draft of the WG charter prior to holding a BOF.
  • The Area Director MAY require that a BOF not be held until an Internet-Draft describing the proposed technology has been published so it can be used as a basis for discussion in the BOF.

Generally, a BOF on one topic only gets held once (ONE slot at one IETF Plenary meeting) 🎀 In unusual situations, the Area Directors can choose to let it meet a second time. A BOF is never allowed to meet three times 🙅‍♀️ Also, all else being equal, WGs get priority over BOFs when it comes to meeting space 💜 And every now and then a BOF happens for reasons other than forming a working group.

A BOF usually ends in one of these outcomes:

  • There was enough interest and focus in the subject to warrant the formation of a WG;
  • While there was a reasonable level of interest expressed in the BOF some other criteria for working group formation was not met (see section 2.1).
  • 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.

3. Working Group Operation ✨

The IETF has basic rules for open, fair participation and for really thinking through technical alternatives 🌈 Inside those rules, working groups run themselves 💅 Each one decides most of the details of how it operates, like how sessions go and how it reaches closure. The main rule is that agreement gets reached through working group "rough consensus" 🫶 And WG participants should definitely look at the rules for disclosing conflicts of interest in [2] 👀

Over time, all sorts of procedural questions pop up, and it's the Working Group Chair(s)' job to run the group process. They have to remember the whole point is making progress toward rough consensus on the WG's goals and objectives 🎯

There aren't many hard-and-fast rules for organizing WG activities, but over time a set of guidelines and practices has built up that has worked really well ✨ They're listed here, though the actual choices usually get made by the WG participants and the Chair(s) 🧚

3.1. Session planning 📅

For organized, structured WG interactions, the Chair(s) MUST publish a draft agenda well ahead of the actual session 💖 The agenda should include 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.

Publishing the WG agenda means sending a copy to the working group mailing list and to agenda@ietf.org 📬

All WG actions shall happen in a public forum, and wide participation is encouraged 🌸 A lot of the business happens over email distribution lists, but the group may also meet now and then to check on task status and progress, sort out specific issues, and plan what's next 🦋 IETF Plenary meetings are the main place for these face-to-face WG sessions. It's common (though not required) for active "interim" face-to-face meetings, phone calls, or video calls to happen too 📞 Interim meetings follow the same rules for advance notice, reporting, open participation, and process as every other WG meeting 💜

All WG sessions, including the ones held outside IETF meetings, shall be reported by making minutes available 📝 Minutes should include the session's agenda, a summary of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for making sure session minutes get written and distributed, though someone the Chair designates can actually do the work 🙌 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@ietf.org 💌

3.2. Session venue 🏡

Each working group gets to decide the right balance of email and face-to-face sessions for hitting its milestones ⭐ Email gives the widest participation 🌍 Face-to-face meetings often give better focus, so they can be more efficient at reaching consensus among the core group of participants 🤝 When balancing things, the WG must make sure its process doesn't shut out people who only take part by email 🫶 Decisions made in a face-to-face meeting about topics that haven't been discussed on the mailing list, or that are significantly different from the consensus already reached on the list, MUST be reviewed on the mailing list 🔍

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 meeting to the WG-chairs list 🏃‍♀️ Session time is a scarce resource at IETF meetings, so applying early helps with scheduling for WGs that need the same experts 🧩

The application for a WG session at an IETF meeting MUST be made to the IETF Secretariat at agenda@ietf.org 💅 Some Area Directors like to coordinate WG sessions in their area, and ask that time slots go through them. If that's the case, the IETF meeting announcement will say so. A WG scheduling request MUST contain:

  • The working group name and full title;
  • 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 should not be scheduled for the same time slot(s); and
  • Optionally a request can be added for the WG session to be transmitted over the Internet in audio and video 🎥
NOTE: Open discussion and contribution are essential to WG success, but the Chair is the one making sure things keep moving forward 🚦 When it's acceptable to the WG, the Chair may call for restricted participation (but not restricted attendance!) at IETF working group sessions to get stuff done 💀 The Working Group Chair then has the authority to refuse the floor to anyone who is unprepared, is covering inappropriate material, or, in the Chair's opinion, is disrupting the WG process 🙅‍♀️ If someone keeps being disruptive, the Chair should consult with the Area Director(s).

On-line 💻

Email exchanges can work really well when they're run like a face-to-face session, with a published schedule and agenda, plus ongoing summaries and consensus polling 📋

Lots of WG participants think the mailing list is the best place to talk through issues and make decisions 💜 The WG itself gets to pick its operating style, though. It's worth remembering that internet email reaches a much wider crowd of interested people than attending IETF meetings does, since going to a meeting takes a lot of time and money ✈️

Just like with face-to-face sessions, sometimes one or more people might act in a way on a mailing list that messes with the WG's progress 😤 In that case, the Chair should try to discourage the behavior by reaching out to the person directly, not on the open mailing list 🫂 If it keeps happening, the Chair must involve the Area Director 📣 As a last resort, and only after explicit warnings, the Area Director, with IESG approval, may ask the mailing list maintainer to block the person from posting to the list (if the mailing list software can do that) 🚫 Even then, the person must not be stopped from receiving messages posted to the list 📩 Other ways of controlling the mailing list may be considered, but they have to be approved by the AD(s) and the IESG 🔒

3.3. Session management 💅

Okay so working groups make decisions through a "rough consensus" process 🫶. IETF consensus does not require everyone to agree, though obviously that's preferred 💖. Generally, the dominant view of the working group shall prevail. (Ngl, "dominance" isn't about who posts the most or who repeats themselves the loudest. It's more of a general sense of agreement 🙈.) Consensus can be figured out by a show of hands, humming, or literally any other method the WG agrees on (rough consensus, obvs). Note that 51% of the working group does not qualify as rough consensus, and 99% is better than rough ✨. It's up to the Chair to decide whether rough consensus has been reached 👑.

It can be super tricky to gauge consensus on a mailing list 😭. There are two different situations where a WG might be trying to figure out consensus through list discussion. But in both cases, the number of messages on a topic isn't, by itself, a good sign of consensus, since one or two individuals can be generating most of the traffic 💀.

In the case where consensus was reached during a face-to-face meeting and is being verified on a mailing list, the people who were in the meeting and expressed agreement must be taken into account 🎀. Say there were 100 people in the meeting and only a few people on the list disagree with what the meeting decided. Then the consensus should be seen as being verified ✨. Enough time should be given to the verification process so list readers can understand and consider any objections raised on the list. The normal two week last-call period should be sufficient for this 🦋.

The other case is when the discussion has been held entirely over the mailing list. This one's harder to measure, since most people subscribed to mailing lists don't actively participate in discussions 🙈. It's left to the discretion of the working group chair how to evaluate the level of consensus. The most common method is for the chair to state what they believe the consensus view is and, at the same time, request comments from the list about that stated conclusion 💜.

The challenge with managing WG sessions is balancing 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. The Chair has the responsibility for overseeing the process but may delegate direct process management to a formally-designated Facilitator 🧚.

It's 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 can be avoided if the Chair makes sure the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to a conclusion. It's also good practice to note important decisions/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 decide to reject or defer input from a member, based on 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;
  • 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 ⚖️

Disputes can pop up at various stages of the IETF process 😤. The process is designed, as much as possible, so compromises can be made and genuine consensus achieved. But sometimes even the most reasonable and knowledgeable people just can't agree 💔. To get to openness and fairness, these conflicts must be resolved through a process of open review and discussion 🫶.

Formal procedures for requesting a review of WG, Chair, Area Director or IESG actions, and for conducting appeals, are documented in The Internet Standards Process [1] 📖.

4. Working Group Termination 🌅

Working groups are typically chartered to accomplish a specific task or tasks. Once the tasks are complete, the group will be disbanded 👋. However, if a WG produces a Proposed or Draft Standard, the WG will frequently become dormant rather than disband. (So it stops doing formal activities, but the mailing list stays up so people can keep reviewing 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, or if the assumptions that work was based on have been modified in discussion or by experience, the Area Director, in consultation with the working group, can either:

  1. Recharter to refocus its tasks,
  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 (see section 3.4) 🙏.

5. Rechartering a Working Group 🔄

Updated milestones are renegotiated with the Area Director and the IESG, as needed, and then submitted to the IESG Secretariat: iesg-secretary@ietf.org 📬.

Rechartering (other than revising milestones) a working group follows the same procedures that the initial chartering does (see section 2). The revised charter must be submitted to the IESG and IAB for approval. Just like the first time, the IESG may approve the new charter as-is, it may request changes be made in the new charter (including having the Working Group continue to use the old charter), or it may decline to approve the rechartered working group. In that last case, the working group is disbanded 💀.

6. 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. The Area Director must agree to the specific people performing the WG Chair and Working Group Consultant roles, and they serve at the discretion of the Area Director 👑.

6.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.

The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of 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 Chair's responsibility encompasses at 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. The Chair is also responsible for ensuring that the working group operates in an open and fair manner. 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's 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's quite common for a working group to assign the task of specification Editor to one or two participants. Sometimes they're also 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 online "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) 🌍.

Organize, prepare and chair face-to-face and online formal sessions 🎙️.

Plan WG Sessions 🗓️

The Chair must plan and announce all WG sessions well in advance (see section 3.1).

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 section 3.1).

Immediately after a session, the WG Chair MUST provide the Area Director with a very short report (approximately one paragraph, via email) on the session. This one's a must-do, no cap 🚨.

Distribute the workload 🏋️

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's the Chair's job 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 must make sure that authors of WG documents incorporate changes as agreed to by the WG (see section 6.3) ✍️.

Document publication 🚀

The Chair and/or Document Editor will work with the RFC Editor to ensure document conformance with RFC publication requirements [5] 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 🙌.

Document implementations 🧪

Under the procedures described in [1], the Chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status, along with documentation about testing the interoperation of these implementations 🧑‍💻.

6.2. WG Secretary 📒

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

6.3. Document Editor ✏️

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 generally designates a person or persons to serve as the Editor for a particular document. The Document Editor 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 Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed 🌈.

6.4. WG Facilitator 🎀

okay so when meetings start getting distracted or divisive 😭, it's super helpful to give one participant the job of "process management" 🧚. Their whole thing is watching over how people are interacting, not what they're saying. They keep an eye on the vibe of the discussion and the agenda schedule, and they don't jump in with their own technical takes 💅. very focused, very respectful ✨

6.5. Design teams 🦋

it's honestly so useful, and kinda inevitable 💜, for a small sub-group of a working group to cook up a proposal for a particular problem. That sub-group is called a design team. To keep it small and agile, it's totally fine for it to have closed membership and private meetings 🔒. Design teams can be anything from a casual hallway chat between people to a formal group of expert volunteers that the WG chair or AD appoints to tackle a spicy, controversial problem 🌶️. BUT, and this is important bestie 🫶, the output of a design team is always subject to approval, rejection or modification by the WG as a whole. The whole WG gets the final say 👑.

6.6. Working Group Consultant 🌸

the Area Director gets to decide whether a Consultant gets assigned to a working group 💅. Consultants bring specific technical background that fits the WG, plus experience in Internet architecture and IETF process 🧠✨.

6.7. Area Director 👑

Area Directors are responsible for making sure the working groups in their area produce output that is coherent, coordinated, architecturally consistent and timely 🎯. That output is their contribution to the overall results of the IETF. Main character energy, no cap 🔥.

7. Working Group Documents 📚

7.1. Session documents 🗓️

all the relevant documents for a session should be published and available as Internet-Drafts at least two weeks before the session starts ⏰. If a document misses that publication deadline, it can only be discussed in a WG session with the specific approval of the working group chair(s). Since members really need time to review everything, granting that exception should only happen under unusual conditions 🙈. The final session agenda should be posted to the working group mailing list at least two weeks before the session, and sent at that same time to agenda@ietf.org for publication on the IETF web site 📬.

7.2. Internet-Drafts (I-D) 📝

the Internet-Drafts directory is provided to working groups as a place to post and share in-process copies of WG documents 🗂️. It's replicated at various locations around the Internet 🌍. It's encouraged that draft documents get posted as soon as they're reasonably stable 💖.

It's stressed here, and I need you to hear this 🥹: Internet-Drafts are working documents and have no official standards status whatsoever. They may, eventually, turn into a standards-track document, or they may sink from sight 🫠. Internet-Drafts are submitted to: internet-drafts@ietf.org 📨.

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

  • Beginning, standard, boilerplate text which is provided by the Secretariat on their web site and in the ftp directory;
  • 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 📖. The organization of the Internet-Drafts directory is found in the file 1id-organization in the Internet-Drafts directory at an Internet Repository site. That file also has the rules for naming Internet-Drafts 🏷️. (See [1] for more information about Internet-Drafts.)

7.3. Request For Comments (RFC) 🎀

the work of an IETF working group often ends up published as one or more documents in the Request For Comments (RFCs) [1] series ✨. This series is the archival publication record for the Internet community 🏛️. A document can be written by an individual in a working group, by a group as a whole with a designated Editor, or by others who aren't involved with the IETF 🖊️.

NOTE: okay this one is a big deal 🚨. The RFC series is a publication mechanism only, and publication does not determine the IETF status of a document. 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 [4] 💀.

7.4. Working Group Last-Call 📣

when a WG decides a document is ready for publication, it may be submitted to the IESG for consideration 🚀. In most cases, the WG Chair decides the WG feels a document is ready by issuing a working group Last-Call 🙌. Whether 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 does the same job inside the working group that an IESG Last-Call does in the broader IETF community (see [1]) 💜.

7.5. Submission of documents 📤

once a WG has determined that at least rough consensus exists within the WG for advancing a document, the following must be done 🥰:

  • The version of the relevant document exactly as agreed to by the WG MUST be in the Internet-Drafts directory.
  • The relevant document MUST be formatted according to section 7.3.
  • The WG Chair MUST send email to the relevant Area Director. A copy of the request MUST also be sent to the IESG Secretariat. The mail MUST contain the reference to the document's ID filename, and the action requested. The copy of the message to the IESG Secretariat is there so the Secretariat records the request and can monitor the document's progress through the process 🗃️.

Unless the IESG returns it to the WG for further development, progressing the document is then the responsibility of the IESG 🏃‍♀️. After IESG approval, final disposition is the joint responsibility of the RFC Editor, the WG Chair and the Document Editor 🫶.

8. Review of documents 🔍

the IESG reviews all documents submitted for publication as RFCs. Usually, minimal IESG review is necessary for a submission from a WG intended as an Informational or Experimental RFC 🌱. More extensive review is undertaken for standards-track documents 🔬.

Before the IESG starts its deliberations on standards-track documents, the IETF Secretariat will issue a "Last-Call" to the IETF mailing list (see [1]) 📢. This Last Call announces the IESG's intention to consider the document, and it solicits final comments from the IETF within a period of two weeks ⏳. It's important to note that a Last-Call is meant to be a brief, final check with the Internet community, to make sure no important concerns were missed or misunderstood 🧐. The Last-Call should not serve as a more general, in-depth review 🙅‍♀️.

The IESG review takes responses to the Last-Call into account 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 [1] for more details). 🤔
  3. Changes regarding content are suggested to the author(s)/WG. Suggestions from the IESG MUST be clear and direct, so as to facilitate working group and author correction of the specification. If the author(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, 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 is 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 so this alternative is not likely to arise for documents coming from a working group, the IESG has the right and responsibility to reject documents it feels are fatally flawed in some way ☠️.

If any individual or group of individuals feels the review treatment has been unfair, there's the opportunity to make a procedural complaint. The mechanism for this type of complaint is described in [1] ⚖️.

9. Security Considerations 🔐

okay bestie, this section is SERIOUS 😤🔐, so read it with your whole chest 💀.

Documents describing IETF processes, such as this one, do not have an impact on the security of the network infrastructure or of Internet applications 🛡️.

It should be noted that all IETF working groups are required to examine and understand the security implications of any technology they develop. This analysis must be included in any resulting RFCs, in a Security Considerations section. Merely noting a significant security hole is no longer sufficient 🚫. IETF-developed technologies should not add insecurity to the environment in which they are run 🙏🔒.

10. Acknowledgments 💜

this revision relies heavily on the previous version (RFC 1603), which was edited by Erik Huizer and Dave Crocker 🫶. It has been reviewed by the Poisson Working Group 🐟✨.

11. References 📚

[1] Bradner, S., Editor, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[2] Hovey, R., and S. Bradner, "The Organizations involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.

[3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 2282, February 1998.

[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards", RFC 1796, April 1995.

[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.

12. Editor's Address ✨

Okay bestie, here's where you can find the editor! 💌

Scott Bradner Harvard University 1350 Mass Ave. Cambridge MA 02138 USA

📞 Phone +1 617 495 3864 📧 EMail: sob@harvard.edu

Appendix: Sample Working Group Charter 🎀

Okay so this appendix is giving us a full example of what a working group charter looks like. It's literally a blueprint, so you can see how all the pieces fit together. Obsessed! 😭

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. It's giving infrastructure, no cap! 🧚

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 of advanced personal mobility and call agent services. Main character energy, literally! 💅

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. 🌸

  1. 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. 🦋
  2. 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

Copyright (C) The Internet Society (1998). All Rights Reserved. 💖

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 🫶

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever, periodt! 💜

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

📦 where this page comes from