Skip to main content
  • IETF email infrastructure transition planned for 11 September

    A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) is scheduled for 11 September 2026 starting at 2200UTC, with message delivery delayed up to 60 minutes. Further updates will be provided closer to the transition.

    28 Aug 2026
  • Post-Quantum Authentication: Up Next

    Post-quantum key establishment has moved from standards into deployment. Post-quantum authentication has not moved nearly as far, and specification work is no longer the only constraint. The IAB is holding a workshop in Prague on 11 and 12 October 2026 to bring deployment experience together with the people working on the relevant protocols and standards.

    27 Aug 2026
  • IETF 126 post-meeting survey: what we heard

    The IETF 126 Vienna meeting was held 18-24 July 2026 and the results of the post-meeting survey are now available.

    27 Aug 2026
  • Meet our new IETF NOC Lead

    Joe Clarke has been appointed as the new IETF NOC Lead and in this post Joe introduces himself and sets out his priorities for the IETF Network.

    10 Aug 2026
  • Secretariat restructuring and staffing update

    There have been a few changes in IETF Administration LLC staffing since January of this year (2026) including the recent insourcing of the Secretariat, which are summarised here to give an overall view of the staffing structure.

    30 Jul 2026

Filter by topic and date

Filter by topic and date

The Role of Working Groups

28 Jul 2013

A while ago I wrote about the issue of the IETF document process being quite heavy-weight in its final stages. Documents go through a lot of review and changes in their last few months. Some of this is natural as the document gains more exposure.

A while ago I wrote about the issue of the IETF document process being quite heavy-weight in its final stages. Documents go through a lot of review and changes in their last few months. Some of this is natural as the document gains more exposure.

But often difficult tradeoffs get re-discussed at this stage, late surprises are discovered, and significant document changes occur. And since the documents are within the responsibility the IETF steering group (IESG) during the final stages, this leads to a situation where much of this process is managed by the steering group. But letting the working groups drive their technology and be responsible for changes would be better. A distributed organisation scales better, and the working groups are also equipped to involve the individual participants.

We are now experimenting with three changes to improve this situation. These changes are small, but we are hoping that they will have a positive effect.

  1. Perform some reviews that are now happening at IETF Last Call a bit earlier. This will put the working group in a bigger role in resolving cross-area and general issues.
  2. In the IETF, each document that passes through the approval process has a document shepherd. They are usually the working group chairs. We have started to invite document shepherds on IESG voice calls when there’s a document that is likely to require discussion. This will make it possible for the document shepherd to be involved in all the discussions.
  3. When a document has a number of issues, hand over the process back to the working group, as opposed to the IESG tracking the issues. Among other things, this will ensure that changes are discussed in an open working group list and agreed through consensus.

While these changes do not by themselves decrease the amount of work done in the final stages, we believe that if successful, this experiment will enable working groups to deal with issues before IETF Last Call and IESG review and empower the working groups to be in charge of the documents throughout their life cycle. We are also hoping that document quality will improve and number of issues discussed in the IESG will be lower.

Discussions are ongoing with the IETF working group chairs and review teams about the practical details of this experiment. Review team members may be asked to review a document when the work has finished in the working group but before an IETF Last Call is started. Working group chairs may ask for these reviews, and if they do, they will be managing the discussion with the reviewer and the working group carefully.

The IETF review teams - such as the Security Directorate (SecDIR), Applications Area Directorate (APPSDIR), or the General Area Review Team (Gen-ART) – have gained a significant role in ensuring that the IETF produces high-quality, understandable and implementable RFCs. In order to avoid overloading these teams, the teams may only take on some early reviews. The experiment will be evaluated after six months to determine whether the practice has been useful.


Share this page