Skip to main content
  • Suggested IETF 119 Sessions for Getting Familiar with New Topics

    These IETF 119 meeting sessions included discussions and proposals that are accessible to a broad range of Internet technologists whether they are new to the IETF or long-time participants.

      26 Feb 2024
    • Google and consortium of local organizations to host first Australian IETF meeting in over 20 years

      Google, auDA, and Internet Association Australia (IAA) provide key support for Brisbane meeting to be held 16-22 March 2024

        23 Feb 2024
      • JSONPath: from blog post to RFC in 17 years

        Today the JSONPath RFC (RFC 9535) proposed standard was published, precisely 17 years after Stefan Gössner wrote his influential blog post JSONPath – XPath for JSON that resulted in some 50 implementations in various languages.

        • Glyn NormingtonRFC 9535 Editor
        21 Feb 2024
      • Stepping towards a Sustainable Internet

        The IAB’s new Environmental Impacts of Internet Technology (E-Impact) program will hold its first virtual interim meeting over two slots on 15 and 16 February 2024. These interim meetings are open to participation, and we invite all interested community members to join, participate, and contribute.

        • Jari ArkkoE-Impact Program Lead
        • Suresh KrishnanE-Impact Program Lead
        7 Feb 2024
      • What’s the deal with Media Over QUIC?

        In 2022, the IETF formed a working group for Media Over QUIC (MoQ)—a media delivery solution that has the potential to transform how we send and receive media during live streaming, real-time collaboration, gaming, and more.

        • Brett BralleyThought Leadership Content Writer, Cisco
        25 Jan 2024

      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