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

    IETF 104 Preview

    • Alissa CooperIETF Chair

    20 Mar 2019

    For our 104th meeting we will be returning to one of the IETF’s favorite cities: Prague, Czech Republic.

    We are on track to break our IETF Hackathon attendance record, with more than 275 people signed up to work on more than 40 projects over the weekend of March 23-24. This weekend we will also host the Code Sprint focusing on building tools for the IETF community, a tutorial explaining how to author Internet-Drafts in the new RFC format that is rolling out starting next week, and the HotRFC session featuring lightning talks about new ideas and opportunities for collaboration.

    Charles Bridge photo by Brian Campbell - no caption

    This is also the second time in less than a year that we are benefitting from co-location with Netdev, the technical conference on Linux Networking. Netdev is taking place March 20-22 in Prague and features a variety of talks relevant to IETF protocols, including a keynote by yours truly.

    As we move into the meeting week itself, we will have six sessions focused on potential new work, spanning nearly all of the IETF’s technical areas. Check out my previous blog post for details on those.

    One of the most compelling aspects of the IETF meeting week is the opportunity for cross-cutting discussions about technology developments that have the potential for broad impact on the networking industry and the Internet. IETF 104 will feature discussions on a number of topics that fit this mold, including:

    • Deployment considerations for DNS confidentiality. The last several years have seen the standardization of RFC 7858 (DOT) and RFC 8484 (DOH), new encrypted transports for recursive DNS resolution. A fiery debate about deployment models, resolver selection, and many other aspects has ensued. Expect to see the many facets of these discussions explored in real-time during the DOH, DNS PRIVate Exchange (DPRIVE), and DNS Operations (DNSOP) working group sessions, as well as during one or more side meetings.

    • Segment routing (SR). Segment routing is a source-routing paradigm that allows for end-to-end policy to be applied within an operational domain without maintaining flow state in the network. With the architecture, use cases, and other foundational RFCs published, the specific protocol extensions needed to realize SR are moving towards maturity. Check out the discussions in the Source Packet Routing in Networking (SPRING), IPv6 Maintenanc (6MAN), Multiprotocol Label Switching (MPLS), Inter-Domain Routing (IDR), and BGP Enabled ServiceS (BESS) working groups.

    • QUIC. The march to standardize an alternative transport protocol to TCP that is more performant, secure, and flexible to deploy continues. In addition to the QUIC working group’s sessions, look for discussion of operational aspects in Transport Area Open Meeting (TSVAREA), HTTP aspects in Hypertext Transfer Protocol working group (HTTPBIS) session, and a research talk in the IRTF Open Meeting (IRTFOPEN).

    • In-situ Operations, Administration, and Maintenance (IOAM). IOAM inserts operational and telemetry information in a packet while that packet traverses a network path, allowing for measurement in cases where sending out-of-band measurement traffic is unworkable. The core specification will be discussed in IP Performance Measurement (IPPM) with protocol-specific extensions and encapsulations to be discussed in Service Function Chaining (SFC) and IPv6 Maintenance (6MAN).

    • YANG versioning. A design team formed out of the Network Modeling (NETMOD) working group has been hard at work evaluating a variety of requirements and proposals for improving how YANG data models are versioned and updated. Given how pervasive YANG data modeling is becoming, the implications of this effort have the potential for broad impact on configuration, management, and routing.

    Those with more of a research focus will be pleased to know that every Internet Research Task Force (IRTF) Research Group (RG) is meeting at IETF 104 (which is a bit unusual since RGs tend to meet elsewhere during the year as well). Of special note will be the quantum Internet tutorial taking place during the Monday afternoon Quantum Internet Proposed Research Group (QIRG) meeting.

    Wednesday will be organized a bit differently than at a typical IETF meeting. The IESG is continuing to experiment with inclusion of unstructured time during the meeting week, in response to interest from participants. Wednesday afternoon will feature unstructured time with meeting rooms available for side meetings. During this time we will also host a Technology Deep Dive - Modern Router Architecture session designed to explain how a modern router is architected, and how it differs from the mental model/traditional view of how a router works. We will finish the day with the administrative plenary where we will recognize outgoing IETF leaders and introduce those new to the leadership, including the first presentation and open mic session for the nascent IETF Administration LLC Board of Directors.

    Finally, I’m personally excited to see the first meeting of the GitHub Integration and Tooling (GIT) working group in action, where participants are seeking to document a set of policies and practices to support the optional use of GitHub by IETF working groups. Those already making use of GitHub to manage IETF work and those interested in starting should plan on joining.

    We always have productive meetings in Prague and IETF 104 is shaping up to be no exception. Many thanks to meeting co-hosts CZ.NIC and Cisco for helping to make this meeting happen. I hope to see everyone in Prague, or participating remotely at IETF 104!


    • [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…

    • [2]RFC 8484

      DNS Queries over HTTPS (DoH)

      This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

    Share this page