Guide to IETF Working Groups

A basic guide to IETF Working Groups and how they operate.

Introduction

The vast majority of the IETF's work is done in its many Working Groups, of which there are well over one hundred. This guide is aimed at people who are new to IETF Working Groups and explains the basics of how they work, how to participate in one, and what to expect.

A Working Group is really just a mailing list with a bit of supervision and facilitation. Anyone can "join" a Working Group just by subscribing to the mailing list, no permission or account required. Once subscribed, anyone can post to a Working Group mailing list. All messages are publicly archived.

All activity in a Working Group is covered by the Note Well, the set of policies governing participation in the IETF.

The full list of active Working Groups is on Datatracker.

Organization and management of Working Groups

Each Working Group has a charter, approved by the IESG, that describes the specific problems or deliverables (a guideline, a standards specification, etc) it has been formed to address. Charters state the scope of work for the Working Group, and lay out goals and milestones that show how this work will be completed. Some charters also specify what the Working Group will not do,

Each Working Group is chartered within an Area and has a responsible Area Director who appoints one, two, or sometimes three chairs to manage the Working Group.

The chairs are responsible for the quality of the Working Group's output. They must keep the Working Group productive and making progress on its drafts, by manage discussion and by scheduling meetings when appropriate. The chairs must also manage the formal processes around Working Group documents and ensure the Working Group complies with IETF policies. Chairs can appoint a Working Group Secretary to assist them.

See BCP 11: Entities Involved in the IETF Standards Process and BCP 25: IETF Working Group Guidelines and Procedures for more details.

Consensus decision making

The general rule on how Working Groups make decisions is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree, and that those in the minority have had a chance to explain why and their points have been addressed, even if they were not agreed with. It is up to the chairs to decide when the Working Group has reached rough consensus; sometimes the responsible AD will also do so. The chairs may use a poll to help with this, but this is not formal voting and should not be mistaken as such.

This consensus-based approach can take a much longer time to reach a conclusion than a formal vote, but many IETF participants regard it as essential for developing protocols that work reliably at Internet scale.

Note, the IETF used to use 'humming' as a method of determining consensus but this practice has largely ceased as it disadvantages remote participants. References to humming still appear in IETF literature.

See RFC 7282: On Consensus and Humming in the IETF for more details.

Working Group documents

Working Group documents are Internet-Drafts that the Working Group has decided to adopt as official working documents, following a formal call for adoption by the chairs. This call for adoption will generally only come after extensive review and discussion. Sometimes a Working Group will consider several alternatives before selecting a particular Internet-Draft as a Working Group document. A Working Group will often take ideas from several of these alternatives to create a single Working Group document.

The WG chairs appoint who will be the authors or editors of Working Group I-Ds; often those who wrote the initial draft continue work on behalf of the Working Group. There is often more than one author/editor for Working Group documents, particularly for complex documents. When multiple documents are combined, the chairs determine who will be listed as authors on the title page and who will be acknowledged as contributors in the body of the document.

As a Working Group document is progressing, participants suggest changes on the Working Group's mailing list (or online if the document is maintained somewhere accessible). The document authors/editors are expected to follow the discussion and make changes when there is consensus so that the contents of the document accurately reflect Working Group decisions. When a document editor does not follow the consensus, the chairs will either be more forceful about getting changes that match the consensus or replace the document editor with someone more responsive.

When a Working Group document is ready to progress beyond the Working Group, the chairs will assign a "shepherd" to take over the final process. The role of the document shepherd is described in RFC 4858: Document Shepherding from Working Group Last Call to Publication. A chair who knows the history of the document within the Working Group, often does the shepherd write-up.

RFC 7221: Handling of Internet-Drafts by IETF Working Groups covers Working Group document processes in depth.

Face-to-face sessions at IETF meetings

Most Working Groups meet face-to-face at IETF meetings (with excellent remote participation support) as these are generally highly productive sessions. It's the job of the chairs to request face-to-face sessions and set the agenda for those. If you want something discussed at the meeting, be sure to let the chairs know about it.

The most important thing to do before coming to a face-to-face meeting is to read the Working Group mailing list and documents ahead of time so that you can understand what is being said. Meetings are explicitly not for education: they are for developing the Working Group documents, and often the presentations expect you to be up to date with the current state of documents and discussions.

Any agreements reached at a face-to-face meeting must also gain consensus on the mailing list after the session, and you'll therefore often hear the phrase "to be confirmed on the list." There are numerous examples of important decisions reached in meetings that are later overturned on the mailing list.

At the start of a face-to-face session, the chairs will normally ask for a volunteer to take notes. This is an excellent way to learn more about the work, the IETF process, and the other participants. They may also ask for a volunteer 'scribe' to monitor the chat and report on any questions or key points raised.

Interim Working Group meetings

Working Groups sometimes hold interim meetings between IETF meetings. Like regular IETF meetings, someone needs to take notes, and the group needs to take attendance. Decisions tentatively made during an interim Working Group meeting must still be confirmed on the mailing list. Interim meetings are subject to the IETF Note Well. Most interim meetings are virtual these days and have the same reporting requirements as face-to-face virtual meetings.

The IESG has rules for advance notice the on time and place of interim Working Group meetings, as well as reporting the results of the meetings. The purpose of these rules is to make interim meetings accessible to as many Working Group participants as possible and to maintain the transparency of the Working Group process.

Working Group resources

Each Working Group has a set of pages in Datatracker with information on the chairs, charter, documents, meetings, mailing list, and more.

Some Working Groups use GitHub repositories to manage their documents and track issues and changes. See RFC 8874: Working Group GitHub Usage Guidance and RFC 8875: Working Group GitHub Administration for more details on how this is intended to work.

Staying on track, making progress and resolving disputes

While the chairs are tasked with ensuring the Working Groups stays on track and continues to make progress, this is something all participants should actively contribute to.

The mailing list and face-to-face meetings are supposed to focus on only what is in the charter and not wander off on other "interesting" topics. Of course, looking a bit outside the scope of the Working Group is occasionally useful, but the large majority of the discussion should be on the topics listed in the charter.

Discussions will get stuck on contentious points, and the chair will need to steer people toward productive interaction, and then declare when rough consensus has been met and the discussion is over.

Sometimes there is a disagreement on whether or not a particular topic is within the scope of the charter. One possible resolution for this, is for the Working Group to agree to work towards a re-charter so that the topic is in scope.

Occasionally, there is a disagreement between an individual chair and participant, in which case another chair will aim to resolve it. If a participant disagrees with a decision of the chairs, such as a call on consensus, and this cannot be resolved within the Working Group, they should bring their concerns to the responsible Area Director.

Any participant who believes they have been mistreated, in violation of the Code of Conduct, should raise this privately with the chairs or go directly to the Ombudsteam.

Closing a Working Group

When a Working Group has fulfilled its charter, it is supposed to cease operations, unless it is re-chartered for follow-on work. In the IETF, it is a mark of success that the Working Group closes up because it fulfilled its charter, and the list of concluded Working Groups is long.

Some Working Group mailing lists continue on after the Working Group is closed, to enable ongoing discussion of the same topics.