Skip to main content
  • New Internet Architecture Board, IETF Trust, IETF LLC and Internet Engineering Task Force Leadership Announced

    Members of the incoming Internet Architecture Board (IAB), the IETF Trust, the IETF Administration LLC (IETF LLC) Board of Directors, and the Internet Engineering Steering Group (IESG)—which provides leadership for the Internet Engineering Task Force (IETF)—have been officially announced, with new members selected by the 2021-2023 IETF Nominating Committee.

      13 Feb 2023
    • Informing the community on third-party correspondence regarding the W3C

      In accordance with our policy of transparency, this blog post is being published in order to keep the community informed about recent correspondence with lawyers acting on behalf of the Movement for an Open Web.

      • Lars EggertIETF Chair
      8 Feb 2023
    • Six Applied Networking Research Prizes Awarded for 2023

      Six network researchers have received Internet Research Task Force Applied Networking Research Prize (ANRP), an award focused on recent results in applied networking research and on interesting new research of potential relevance to the Internet standards community.

      • Grant GrossIETF Blog Reporter
      9 Jan 2023
    • Travel grants allow Ph.D. students to participate at IETF meeting in-person

      Sergio Aguilar Romero and Martine Sophie Lenders, both Ph.D. students in technology fields, attended and participated in the IETF 115 meeting in London with assistance through travel grants from the Internet Research Task Force.

      • Grant GrossIETF Blog Reporter
      7 Jan 2023
    • Impressions from the Internet Architecture Board E-Impact Workshop

      The IAB ran an online workshop in December 2022 to begin to explore and understand the environmental impacts of the Internet. The discussion was active, and it will take time to summarise and produce the workshop report – but the topic is important, so we wanted to share some early impressions of the outcomes.

      • Colin PerkinsIAB Member
      • Jari ArkkoIAB Member
      6 Jan 2023

    Filter by topic and date

    Filter by topic and date

    Highlights from IETF 103

      19 Nov 2018

      From November 3 to 9, the IETF community gathered for its 103rd meeting in the bustling city of Bangkok. This was our first meeting in Thailand. The incredible hospitality, sleek venue, and delicious food provided a setting well-suited to a productive and enjoyable meeting.

      Bangkok 2
      Photo of Bangkok, Thailand

      We kicked off the meeting with our usual weekend events, the Code Sprint and IETF Hackathon. Each hackathon continues to draw more participants than the last, with 250 on-site and 32 remote participants collaborating on 28 different projects this time. 

      Notable new projects included two that leveraged or integrated with Linux Foundation open source networking projects: one focused on implementing the latest version of the IPPM working group’s in-situ OAM in Vector Packet Processing (VPP), and one focused on SD-WAN service creation using the Open Network Automation Platform (ONAP) orchestration framework. We closed out the weekend with a packed HotRFC session with lightning talks about new drafts, new software, new research ideas, and new problem spaces.

      IETF Hackathon Bangkok
      IETF Hackathon Bangkok

      The Security Area saw some of the more intense debates of the week. Discussions during the RATS BoF revealed that participants are considering a diverse set of use cases and architectural assumptions, with disagreement about how broadly to scope potential IETF work and what actors needed to be considered in the design. There was considerable agreement that, at a minimum, standardizing an attestation token format may provide value, so charter discussions may lead in that direction. 

      In the TLS working group there has been a long-running debate about the susceptibility of the mechanism described in draft-ietf-tls-dnssec-chain-extension to attack. The mechanism is aimed at making it easier for TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. The working group declined to continue progressing the work given that TLS extensions can be specified and granted IANA code points without the need to publish a standards-track RFC, and the difficulty of constructing a robust solution that addresses all use cases.

      In the Routing Area as well as the Applications and Real-Time Area, discussions at IETF 103 will be leading to proposals for new working groups or existing working group re-charters. The TEAS working group will be re-chartering to focus on API work. Participants in the Routing Area Working Group (RTGWG) held discussions about chartering a new focused working group to look at control plane and user plane separation. The HTTPBIS working group will be re-chartering and adding the next version of the HTTP protocol–now to be officially known as “HTTP/3”–to its charter. The DNS-over-HTTPS (DOH) working group  did not meet in Bangkok, but given the interest in DoH, the group will be staying open until IETF 104 to see if new work items come in over the coming months. At that point participants will decide whether to re-charter or close the group and propose a new group with a different DNS/web focus.

      In the Transport Area, the QUIC working group closed in on a key decision concerning the “spin” bit, which is a single bit in the QUIC protocol header to facilitate passive measurement of round-trip time for QUIC flows. After more than a year of debate about the efficacy of using the spin bit for measurement and the risks of its presence revealing endpoint location information, the rough consensus in the room was to include the spin bit in the QUIC packet format, but not require its use, and to require implementations not to use it for at least a certain fraction of their traffic. Meanwhile, the Transport Area Working Group (TSVWG) had a fruitful discussion about the future of network management in light of broader deployment of encrypted transports like QUIC.

      In the Operations and Management Area there were a couple of lengthy discussions that are likely to be continued at interim meetings in the coming months. The ANIMA working group spent significant time discussing a draft that describes processes for enrolling devices in an “autonomic” network, with the assistance of a voucher service provided by the device manufacturer. The core of the debate concerns how much control the manufacturer should be able to have over devices once they are in the field or resold, compared to the device owner. The NETMOD working group considered five different options for versioning schemes for YANG models, as the current versioning scheme documented in RFC 7950 has proved brittle as bugs in published models have been discovered. Look out for substantial further discussion in both areas before IETF 104.

      Several long-standing network-layer engineering problems were the subject of extensive discussions in the Internet Area. The 6MAN working group is tackling the decades-old problem of how to efficiently and reliably discover the maximum transmission unit (MTU) size along a path. That discussion is benefitting from close collaboration with transport experts. The DNSSD working group made substantial headway in reconciling two different approaches for doing DNS-based service discovery without leaking personal information or information about offered or requested services.

      IETF 103 also involved several important discussions about how we get our work done in the IETF. The GROW working group is considering experimenting with publishing “living documents” that can be updated more frequently and more easily than RFCs. That proposal will be fleshed out more thoroughly in the coming weeks. Participants in the WUGH BOF seemed to be coalescing around a basic set of conventions and tools to establish a uniform way for working groups to use GitHub for IETF work if they so chose. Charter text for a small, focused working group in that area will be forthcoming. And during the plenary open microphone session with the IESG, we heard from several participants about conduct in IETF working groups and openness to newcomers. The IESG is continuing to digest that feedback and brainstorm about how to make improvements.  

      IETF 103 Plenary
      IETF 103 Plenary

      Taking advantage of being co-located with IEEE802 and back-to-back meeting weeks, two joint sessions were held over the weekend. One session was a Data Center Workshop and the other session was a joint meeting of IETF’s DETNET working group and IEEE 802’s TSN group.

      Finally, this was the first IETF meeting where the NOC configured the IETF network to perform RPKI ROA validation and drop routes with “invalid” origins, resulting in approximately 6100 discarded routes. Huge thanks to them for helping to improve our routing security, and for everything else they do to help us have successful meetings.

      We’ll gather again as a community at IETF 104 in Prague, March 23-29. Until then, see you on the mailing lists!

      Share this page