An Unofficial Guide to Participating in the IETF

This is intended to be a helpful guide for those who are new to the IETF and interested in participating in a working group there. See the IETF getting started guide for additional and authoritative information.

All IETF participants need to be aware of the Note Well terms; they govern issues such as intellectual property, standards process, and professional behaviour.

• Understanding IETF Working Groups
  • Participating in Working Groups
  • Your Contributions
• Understanding Internet-Drafts
• Attending Meetings
• Gaining Consensus
  • Appealing Decisions
• Finishing Work
  • The Post-Working Group Process
  • Re-Chartering

Understanding IETF Working Groups

Most IETF standards are created in working groups (WGs). Working groups are created by the Internet Engineering Steering Group (IESG) in consultation with the IETF community, and fall into an IETF Area. Each Area has a small number of Area Directors, who collectively make up the IESG.

The scope of work for a given working group is defined by its charter. The charter also contains milestones, which indicate an approximate timeline for the work. Working groups cannot exceed or violate their charters, which is why some discussions will be ruled out of scope.

Working groups chairs are charged with assuring that the work progresses, scheduling meetings, appointing editors, and judging consensus. Chairs are appointed by the relevant Area Director.

Information about all IETF working groups – including their charters, adopted and related documents, and meetings – can be found on the IETF datatracker site under the ‘Groups’ menu.

See the Internet Standards Process and Working Group Processes for more information.

Participating in Working Groups

The IETF has no concept of membership; anyone who shows up (e.g., at a meeting; on the relevant mailing list) can contribute.

Furthermore, participation in the IETF is considered to be on an individual basis. This is a guiding norm in the community – everyone understand that you might work for a particular company, but your statements are not representative of them; rather, they are thought of as your statements and opinions.

This also means that saying that your statements represent others’ views (either those of your employer or others outside the IETF) is frowned upon.

Most activity in a working group will happen on the mailing list designated in its charter, as well as meetings. Therefore, if you intend to participate in a group, you should be subscribed to that list.

Some working groups also use GitHub to manage issues and drafts. If a group does use GitHub, it’s important to understand its policies regarding GitHub usage.

Professional behaviour is expected in IETF working groups; see the IETF Code of Conduct and Anti-Harassment Procedures.

In particular, while discussion is often robust, we criticise ideas, not people. Furthermore, the chairs may guide discussion; for example, when the group “rat-holes” on topics that are not productive.

Your Contributions

All statements in meetings, on the mailing list, in relevant GitHub organisations, and other relevant venues are considered to be contributions to the IETF, and covered by these policies:

• Intellectual Property Rights in IETF Technology
• Rights Contributors Provide to the IETF Trust

The IETF operates in the open. Your contributions are made publicly, and meetings may be recorded and made public. See the IETF Privacy Statement for details.

Understanding Internet-Drafts

Most work focuses on Internet-Drafts (I-Ds), the documents that might eventually become Request for Comments (RFCs).

Individual participants can publish drafts at any time. This is a good way to make a proposal to the group, although proposals can also be made in e-mail and elsewhere.

By convention, an individual draft uses the naming convention draft-ietf-yourname-wgname-title, where yourname is a short label for you, wgname is the short label for the working group you wish to draw the attention of (found in its charter), and title is a short identifier for the draft. For example, draft-nottingham-httpbis-another-header.

The working group will adopt one or more drafts as official work items. To do so, the chair(s) will issue a Call for Adoption to gain consensus on that work item.

It is important to understand that adopted drafts are only the starting point for new work; there is no presumption of consensus on their contents. Thus, when answering a call for adoption, focus on whether you believe that the document is a reasonable launching point for discussions, rather than its specific contents.

Editors for adopted drafts are selected by the chair(s). By convention, adopted drafts are named draft-ietf-wgname-title.

Tools and documentation are linked from the Internet-Draft authors site; we recommend Martin Thomson’s template for most people. Drafts can be manually submitted on datatracker site.

Attending Meetings

In the IETF, there are three kinds of meetings:

• Face-to-face meetings in the IETF plenary weeks three times a year
• Hybrid face-to-face and virtual ‘interim’ meetings; usually 2-3 days
• Virtual interim meetings

Face-to-face meetings are higher-bandwidth opportunities to discuss the nuances of issues, make progress on documents, and share information between participants. It also helps to build relationships between participants, which can aid in finding consensus.

To be as inclusive as possible, all meetings allow remote participation, usually using the IETF meetecho tools.

Meetings will be announced on the working group mailing list, and are listed on the group’s datatracker page.

When attending a meeting, please follow these guidelines:

• If you want to speak, please join the queue (if one is being maintained)
• In-person attendees should speak clearly and loudly for remote participants’ benefit
• Avoid speaking over other participants, and avoid having side conversations
• Identify yourself clearly when first speaking

Meetings will be minuted. Please consider volunteering to help keep minutes, and be sure to check the draft minutes for accuracy regarding any statements yo make.

Note that per above, decisions are not made in meetings; rather, they are confirmed on the mailing list. In a meeting, we only get a ‘sense of the room.’

Gaining Consensus

The IETF practices rough consensus. Decisions are not required to have unanimous assent; if someone disagrees with a decision and they have had an opportunity to explain their position, they can be declared “in the rough.”

Generally, the chair(s) will guide discussion to assure that all viewpoints have an opportunity to be heard, while managing the risk of becoming fixated on one viewpoint or issue (“rat-holing”).

For important decisions, the chair(s) will issue a Call for Consensus on the mailing list. When this happens, expressing your position is important, because it is difficult for them to interpret silence.

Decisions in the IETF are never made by voting – strong arguments are preferred over large numbers of supporers. Therefore, if you disagree with the decision, you should clearly explain the reason, since “I don’t want to” doesn’t carry any useful information.

On Consensus and Humming in the IETF explores how IETF consensus works in practice.

Appealing Decisions

If you disagree with a decision, you should first notify the chairs and explain why. If that cannot resolve the issue and you cannot live with the result, the decision can be appealed to the Area Director.

When appealing, you need to show a substantial process or technical issue; merely being in the rough is not likely to change their minds.

If the Area Director appeal does not resolve your issue, further appeals are possible. See The Internet Standards Process and Working Group Procedures for details of the appeal process.

Finishing Work

Once a draft’s issues list is empty and the editor(s) and chair(s) believe it is ready, a Working Group Last Call (WGLC) is issued on the mailing list.

Working Group Last Call establishes consensus that the document is ready to progress. Here, expressing support on the maling list is especially important, to help the chairs judge consensus for publication.

It is possible to raise new issues in Working Group Last Call, but they should be new; re-hashing discussions where consensus has already been established is discouraged.

The Post-Working Group Process

After Working Group Last Call successfully concludes (i.e., all raised issues are dealt with, and the chair(s) judge that there is consensus to proceed), the document is sent to the group’s Area Director.

The AD does an initial evaluation of the document, and may send it back if they find issues.

After any issues found by the AD are dealt with, they initiate *IETF Last Call, which is a whole-of-IETF review. Simultaneously, a number of *directorate reviews are initiated; these are reviews by pools of volunteer experts for issues like security, internationalisation, and operability.

At the end of IETF Last Call, the IESG will do its own set of reviews and may identify additional issues.

For all of the issues identified in the process above, minor ones will be dealt with by the chair(s) and/or editor(s); major issues may require working group discussion.

Once the IESG approves the document (with possible changes), it will go into the RFC Editor queue.

Re-Chartering

After a group ships its deliverables, it might become aware of new work in its area. To accommodate that, it can request that its charter be revised.

Charter revisions require IESG and IETF-wide review. This is not necessarily onerous, depending on the nature of the changes.