Skip to main content
  • IETF 126 Highlights

    The IETF 126 meeting was held 18–24 July 2026 at the Hilton Vienna Park in Vienna, Austria, and online, hosted by Cisco. The week included the IETF Hackathon and Code Sprint, the New Participants' Program, five Birds-of-a-Feather (BoF) sessions, and more than 100 working group and research group sessions. The Applied Network Research Workshop also took place during the IETF 126 meeting week.

    1 Sep 2026
  • 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

Filter by topic and date

Filter by topic and date

IESG Retreat 2018

4 May 2018

At the end of April the Internet Engineering Steering Group (IESG) gathered in Paris for its 2018 retreat.

Paris panorama

With three new area directors — Ignas Bagdonas in Operations and Management, Martin Vigoureux in Routing, and Benjamin Kaduk in Security — it was a good opportunity for us to get to know one another better and for those of us who have been serving a little longer to come to closure on some topics that we've been debating for quite some time. We also met for one day jointly with the Internet Architecture Board (IAB).

Together with the IAB we discussed "infrastructure ossification," where some widely used IETF protocols have been so successfully extended that they are in danger of becoming too complex to understand fully and implement correctly. An example of this was provided at IETF 101 in a presentation on the "DNS camel". Riffing on that, we explored whether HTTP is another example where the combination of protocol success and protocol complexity have produced similar or different results to the DNS case. We realized that there may be further work to do in the vein of RFC 5218 ("What Makes for a Successful Protocol?") to describe design patterns that can yield wild protocol success in the form of wide deployment without having that successful uptake also be the protocol's undoing.

IESG-Retreat-Dining.jpg
IESG and IAB interactions continue beyond retreat meeting times.

During the IESG-only portion of the retreat we discussed several process-related issues. 

Understanding and navigating IETF processes can be difficult for individuals without previous experience working through them. We spent a significant portion of our time discussing various proposals to help new work flourish in the IETF and to help identify and support new participants. You'll be seeing some changes as a result: more advance notice to remind the community about the Birds of a Feather (BoF) deadline, encouragement embedded in our Important Dates to those thinking about proposing a BoF to alert the IESG about such proposals as soon as possible, and updated material on the IETF web site to make it easier for newcomers to understand the pathways by which new work can begin in the IETF.

We also spent some time on our own and with the IAB talking about a collection of topics related to the RFC series and document processing. We discussed some of the confusion that is caused by our current process for issuing document status changes, and a number of people in the leadership agreed to go think about ways to better combine the arguably mutable elements of our documents (errata, status changes, bis-style updates) with our current concept of immutable RFCs. The IESG also discussed some confusion we have noticed about the relationship between the status of informational RFCs and IETF consensus, and as a result a few ADs signed up to think further about how this could be clarified within the IETF document stream or the RFC series as a whole. We reviewed an upcoming experiment involving a few authors' use of Github to process changes during AUTH48. And we adopted a new procedure for scheduling documents on IESG telechats, such that under normal circumstances documents will be placed on telechats in the order in which their ballots were issued.

As always, feedback on topics that you think the IESG should be tackling is welcome at iesg@ietf.org.

Bibliography

  • [1]RFC 5218

    What Makes for a Successful Protocol?

    The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can ser…


Share this page