IETF 116 Highlights and other thoughts

Disclaimer: I’m not writing this post in my capacity as IAB chair, rather as IESG member. And the content in this post is based on input from the whole IESG.

This report is slightly late as the Internet Engineering Steering Group (IESG) and Internet Architecture Board (IAB) met mid-May for their annual retreat.

Before focusing on IETF 116, I would like to look back a bit further with some high-level observations that might help put recent meetings in context. Actually, I like numbers, so let’s start with some!

The IESG monitored IETF email list activity and Internet-Draft (I-D) submissions during the pandemic. Even with just these high-level numbers it was noticeable that while the work of existing working groups (WGs) seemed to progress steadily (and in some cases maybe even more regularly!), the number of new (“-00”) I-D submissions was lower than before, perhaps indicating an impact on new work of working fully online during the pandemic. This becomes even more evident when we look at the number of Birds of a Feather (BoFs) during the pandemic. With the exception of IETF 111 (where two of the BoFs were having a second meeting), there was only one BoF for each of the meetings from 108 to 112. As soon as we returned (at least partially) to in-person meetings for IETF 113 in Vienna, we saw an immediate increase to 3 BoFs and back to 5-6 BoFs for the IETF 114 and IETF 115 meetings. 

While I think the reasons for the lack of new work proposals during the pandemic might be more complex, the lack of hallway discussion was quite clearly a contributing factor. 

Comparing participant numbers for IETF 116 to IETF 113, IETF 114 and IETF 115, I would say we are basically back to normal—or at least back to a new normal. At the beginning of 2022, it was amazingly good to see people in person again after such a long time of staring at a screen in your home office, including sorely missed time for chatting over a drink, of course. It was even more amazing to meet with more and more people during 2022 for each meeting. I have to say that I now value the ability to meet, talk, and resolve some problems quickly in-person more than I did before the pandemic. 

Still, one important improvement we achieved during the time of online-only meetings was to better integrate remote participants at IETF meetings. This can clearly be seen as, independent of the increasing in-person participation since IETF 113, remote participation remained high. Of course, remote participation is still not the same as in-person participation, and time zone differences remain challenging. But, it is easier than ever now to skip traveling to a meeting or two and decide to contribute remotely, for personal, business, or environmental reasons. 

There is for sure room for more improvement in remote participation, as well as continued discussion about the cadence of in-person meetings. I consider this an active area of work for the IETF community.

In addition to the technical work at IETF 116, I would like to note the high number of new and local participants. With nearly 1000 in-person participants, the meeting was in a comparable range to pre-pandemic numbers. Together with more than 500 remote participants, the overall number of participants even increased compared to IETF 106 in November 2019, and was comparable to previous meetings. 

I had the opportunity to talk to a couple of participants who joined for the first time in person during the IETF 116 New Participants' Social Hour, and I was impressed with the positive feedback and high level of engagement. Every new participant I spoke with was from Asia and had good expertise on IETF-relevant topics. They had previously followed the IETF online at least to some extent and were now taking the opportunity to join the meeting in-person. They all enjoyed engaging with the community and learning more about the IETF. This is yet another reason why meeting people in person from time to time remains important.

Okay, let’s look at what happened at IETF 116 from a technical point of view. IETF 116 hosted 5 BoFs, with one (BPF/eBPF) in the process of being chartered as a working group right now. BPF is a really exciting activity. (e)BPF is a widely deployed technology to sandbox programs in a privileged context such as the operating system kernel. This technology has a well-established community but given the now wider uptake beyond the Linux kernel, the community is looking for stable documentation and a process for future extensions. While there was some discussion about whether the scope of the work fits within the IETF, it is nice to see that the existing, well-established BPF community assessed our process and procedures as desirable, and approached us to standardize their work. Given the expert overlap between the IETF and (e)BPF communities, I’m really excited and curious to see this group coming along! 

The other three entirely new BoFs were vCon, SML (Structured Email) and keytrans (Key Transparency). vCon aims to specify a container format to ensure the integrity and privacy of all data belonging to a conversation. Probably not a small piece of work but there seem to be many use cases and quite some interest. SML aims to standardize machine-readability for the automated transactional email. And keytrans is looking into distributing the end-user public keys for E2E encryption in a safe, publicly-auditable way. All are challenging topics, but definitely areas where work is needed.

The Domain Boundaries (dbound2) BOF was held to re-open the dbound WG with a new approach and new energy to tackle developing a specification to represent differing administrative control between "related" DNS names (such as example.com and foo.example.com). Looks like a good new start for a happy end as well!

Also at IETF 116 there were two new, at that time proposed, research groups meeting for the first time. Research and Analysis of Standard-Setting Processes Research Group (RASPRG) is bringing together researchers and other interested parties to study the standardization process itself, based on various data that is publicly available in the IETF document, mailing list, and other tools like the datatracker. And, the Usable Formal Methods Proposed Research Group (UFMRG) works on formal protocol specification and validation techniques such as languages for specifying algorithms or tools to help derive formal models from natural language and semi-structured specifications. A chance to support the IETF community to write the best possible standards and, similarly as RASPRG, also an opportunity to assist human interactions during the standards setting process. Very interesting!

I would quickly like to also mention working groups that were chartered shortly before the IETF 116 meeting or for the first time during IETF 116. These are More Instant Messaging Interoperability (MIMI), Secure Asset Transfer protocol (SATP), Time-variant Routing (TVR), Computing-aware Traffic Steering (CATS), and The Post-Quantum Use in Protocols (PQUIP). MIMI specifies the minimal set of mechanisms required to make modern Internet messaging services interoperable. The group was chartered shortly after a BoF held during 115 and, given the broad interest, now holds weekly interim meetings since their first meeting at 116. SATP works on a base architecture and protocol for secure asset transfers from one gateway to another. While blockchain based systems are the main use case, I believe the work shows the strength of the IETF is designing common building blocks. 

TVR defines information and data models for time-based, scheduled changes to a network. The main use case is satellite communication, which is getting more and more deployed and is a really exciting Internet workspace, but it can also be used for e.g. scheduled downtimes for energy saving, which is at least equally exciting and timely. Similarly in order to make the future Internet more resource and energy efficient, the CATS WG is working on analyzing the problem of steering network traffic while taking computing services and resources into account in order to produce an architecture to expose network conditions to endpoints and load balancing/service selection at layers 4 and 7. PQUIP working group is a new standing venue to discuss post-quantum cryptography (PQC) (operational and engineering) transition issues in order to make IETF protocols and security mechanisms ready and secure for the future. 

In the scope of new work, there are currently also various discussions on the impact of Internet services on the environment. The Internet is for sure a tool that helps to reduce this impact for many industries, as well as in our individual lives. But of course that doesn’t mean that we should not consider how to further optimize the technology of the Internet. E.g. a first step could be to get better measurement tools to assess the energy consumption of communication systems. This and other considerations were discussed at the IAB AID workshop last December and presented as well as continued to discuss during the IAB Open at IETF 116. In addition, work on metric was presented in OPSWG and a side meeting was held to more generally discuss potential new work in the IETF that can support energy saving or other features that reduce the environment impact. I’m sure this activity continues as it is so important. And I’m sure there are things we can do in the IETF, also all players need to work together to really make a difference.

And finally, to point out a few randomly selected highlights from existing working groups, I would first like to first mention that the Multiplexed Application Substrate over QUIC Encryption (MASQUE) working group, a group in which I have been very active myself, have concluded its two main deliverables with CONNECT-UDP and CONNECT-IP to allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection, has now rechartered to work on maintenance and extensions. Talking about proxies, the Oblivious HTTP Application Intermediation (OHAI) working group also concluded its main work item with approval by the IESG to publish draft-ietf-ohai-ohttp as an RFC just before the IETF 116 meeting. Nice and speedy execution, even though the IESG review caused some additional discussion, which was eventually solved by people openly talking to each other and aiming for a common solution. 

As of news from the domain world, shortly before IETF 116, draft-ietf-dnsop-alt-tld was approved for publication. This document reserved the string .alt for use as a "TLD" by non-DNS name resolution systems. This was coordinated with ICANN). And if you care about IPv6 and Extension header—which we all should—have a look at the IPv6 Maintenance (6man) working group. They just finished two documents on processing IPv6 extension header as well as hop-by-hop options. Long story short: really good and important work! 

I feel I’m overusing the term “exciting” now but it really is thrilling to see important work ready for deployment as well as all the new work being started with many new participants joining the community. It is nice to see everybody working together to make the Internet more secure and future-proof! I hope to see many of you at the IETF 117 meeting in San Francisco, 22-29 July 2023, which promises another round of broad and exciting work!