Skip to main content
  • Banishing the bane of bufferbloat

    Bufferbloat affects everyone who uses the Internet, resulting in frustratingly slow web browsing, laggy video calls, and overall poor quality of experience for Internet users and there's a lot of work underway in the IETF to address it.

    • Bjørn Ivar TeigenIETF Participant
    23 May 2023
  • IETF 116 post-meeting survey

    IETF 116 Yokohama was held 25-31 March 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

    • Jay DaleyIETF Executive Director
    26 Apr 2023
  • Catching up on IETF 116

    Recordings are now available for sessions held during the IETF 115 meeting and the IETF Hackathon, where more than 1500 participants gathered in London and online 5-11 November 2022.

      1 Apr 2023
    • Reducing IETF Meeting Scheduling Conflicts

      With many IETF participants active across a number of active working groups and limited time slots in an IETF meeting week, we aim to arrange sessions in the agenda to minimize conflicts that prevent participants from joining sessions that are of interest to them. In each post-meeting survey we ask meeting participants to comment on the scheduling conflicts they experienced in the meeting agenda and we then use this information to improve the meeting agenda.

      • Alexa MorrisIETF Managing Director
      31 Mar 2023
    • Messaging Layer Security: Secure and Usable End-to-End Encryption

      The IETF has approved publication of Messaging Layer Security (MLS), a new standard for end-to-end security that will make it easy for apps to provide the highest level of security to their users. End-to-end encryption is an increasingly important security feature in Internet applications. It keeps users’ information safe even if the cloud service they’re using has been breached.

      • Nick SullivanMLS Working Group Chair
      • Sean TurnerMLS Working Group Chair
      29 Mar 2023

    Filter by topic and date

    Filter by topic and date

    Birds of a Feather at IETF 102

    • Alissa CooperIETF Chair

    15 Jun 2018

    Three community discussion sessions on wide-ranging topics have been approved for the next IETF meeting.

    IETF 102 Birds of a Feather Sessions (Photo by Steven Feather (CC BY-NC-SA 2.0))

    Before each IETF meeting, the Internet Engineering Steering Group (IESG) collects proposals for Birds of a Feather (BOF) sessions. These sessions are designed to help determine the path for new work in the IETF or to generate discussion about a topic within the IETF community. For IETF 102 we approved three BOF sessions, all of which are focused on generating discussion in the community rather than on forming new working groups. Although for long-time attendees it may seem a bit odd to have a meeting devoid of BOFs aimed at working group formation, we created an above-average number of working groups (seven) between IETF 100 and 101, so it seems this is part of the naturally bursty nature of new work in the IETF.

    The DNS Resolver Identification and Use (DRIU) BOF is a response to the creation of new methods for Domain Name System (DNS) stub resolvers to reach recursive resolvers: RFC 7858, produced by the DPRIVE working group, and DNS-over-HTTPS, underway in the DOH working group. As these have been developed, questions have been raised about how to configure stub resolvers using protocols such as Dynamic Host Configuration Protocol (DHCP) and DHCPv6, what security properties these transports have in various configurations, and some broader architectural implications resulting from the availability of these new methods. The DRIU BOF is meant to bring together participants working with these protocols to help prevent overlap and to garner interest in particular topics.

    The Internationalization Review Procedures (I18NRP) BOF was proposed to generate discussion about how work on internationalization -- adding or improving the handling of non-ASCII text in protocols -- should be handled procedurally within the IETF going forward. A number of working groups have dealt directly with specific problems related to identifiers, protocol design, language selection, and other issues over the years, and there have also been a number of Internet Architecture Board (IAB) efforts in this area. IETF work on internationalization has unfortunately stagnated in recent years, so the goal of this discussion is to identify promising proposals for processes that would help kick-start progress. See the mailing list for more.

    Finally, the RFC++ BOF was proposed to discuss an experiment aimed at mitigating long-standing confusion arising from the fact that standards and non-standard documents are mingled within the RFC series. Several different types of documents are published in the RFC series, including IETF standards, informational documents from the IETF, IAB, and IRTF, and independent submissions. The proposed experiment would involve creating new labels for documents of different types and emanating from different sources. This would allow the "RFC" identifier to be reserved for standards-related documents. Discussion of this and related proposals is picking up steam on the mailing list and could benefit from viewpoints from more readers, consumers, and implementers of RFCs, so please consider joining the list and chiming in!

    The IESG received three additional BOF proposals in this cycle: Secure End to End Privacy Enabled Mapping System (re-using a prior acronym, ATICK), Autonomous Asynchronous Management Policy and Protocols (AMP), and Application Transport Layer Security (ATLAS). In each of these cases we identified the potential for promising new IETF work, but felt that either more preparation or more preliminary discussion in a side meeting setting is needed to increase the likelihood of successful BOFs in these areas. Working with our colleagues from the IAB we have identified IAB members to help shepherd these efforts.

    We have just over a month to go before IETF 102 kicks off. Looking forward to lively and productive BOF discussions on the mailing lists and in person in Montreal!


    • [1]RFC 7858

      Specification for DNS over Transport Layer Security (TLS)

      This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage pr…

    Share this page