Looking Ahead, Facing Change

My predecessor Jari Arkko noted upon beginning his term as chair just how much can change from one chair’s term to the next. As I’ve started settling into my new role over these last weeks, I’ve been thinking a lot about what has been changing and what has been staying the same in the IETF.

When I first started participating in the IETF, it didn’t take long for me to realize the importance of the IETF as a venue for creating the building blocks of the internet. The significance of the IETF derives from the combination of what we choose to work on and how we carry out that work. Producing core standardized protocols wouldn’t have nearly the same impact on the internet as the existing body of IETF work if it were done behind closed doors, if a single constituency could dictate the outcome, or if broad interoperability were not the main objective. To my eye, the core principles of the IETF process – open participation, cross-area review, and consensus – contribute to the success of IETF protocols in tandem with the design choices and technical trade-offs inherent in protocol design.

Of course, those process features are also often cited as drawbacks of IETF participation. “The IETF moves too slowly,” some people say. “They’re not adaptable,” “they can’t compete with open source,” “the biggest players aren’t interested in consensus.” Sound familiar? Sure, it’s true more often than not that if you’re trying to find agreement among a large, heterogeneous pool of people, that will require a different investment of work and time than deciding things among you and your close group of friends, or hacking something together all on your own. The challenge I see for the IETF in the coming years is to preserve the benefits of the essence of the IETF model while adapting to changes in the industry and the environment. With collaborative styles of engagement flourishing across both open source and standards development, there is a lot of opportunity for synergy.

How can we do a better job of integrating our work with open source development efforts? How can we evolve our tools and processes to align with how software is being developed and deployed today? How might we apply the model of cross-area review and consensus more broadly than to static text specifications? How can we evolve the administration of the IETF to give the community more flexibility and room to experiment? I have my own thoughts about these questions, but far more important are the ideas and efforts of the IETF community.

Personally I think we have many reasons to be optimistic about tackling these questions, based on recent IETF standards development work as well as ongoing community conversations and activities. Over the last several years we’ve seen protocol development efforts deeply intertwined with and informed by running code, with the concurrent development of 10 or more independent implementations, for instance in the case of HTTP/2 and TLS 1.3. We’ve seen broad interest across the industry in the kind of security expertise that has become a hallmark of the IETF, and resulting security and privacy improvements being developed for web, email, DNS, DHCP, real-time, and other kinds of traffic. We’ve seen tremendous energy behind the specification of YANG data models and their integration across the industry into standards processes. And community discussion and activity continues to grow around the IETF Hackathons, use of Github, remote participation, and IASA 2.0.

I’m excited to work with the community on how we face the changes around us while retaining the core of what makes the IETF most effective. We have lots of existing venues for discussions of specific aspects of this, but of course you can always send me your thoughts or post them to the IETF discussion list.