* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Birds of a Feather Meetings (IETF Pre-WG Efforts)

This page provides one common place that lists "possible IETF pre-WG efforts", known as Birds of a Feather ("BoF") meetings. Anybody who proposes a BoF is strongly encouraged to register the BoF effort here at such time as appropriate; e.g., during steps 1 and 2 in RFC 5434. Also see https://www.ietf.org/wg/bof-procedures.html.

The IAB will also attempt to provide BoF Shepherds as described in their document on the subject only on request from the IESG. If you feel that your BoF would benefit from an IAB BoF Shepherd, please discuss this with your Area Director.

To allow the Secretariat to schedule a BoF slot if it is approved, each entry MUST include the following items:

  • Long name and abbreviation
  • Description, including whether the BoF is intended to form a WG or not
  • The responsible Area Director (AD)
  • BoF Chairs (or the ADs as placeholders)
  • Number of people expected to attend
  • Length of session (1, 1.5, 2, or 2.5 hours)
  • Conflicts to avoid (whole Areas and/or WGs)
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Template for BOF Entry - Please do not edit the BoF Example Page directly.

Timeframe IETF 106 (Singapore)

The current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 23:59 UTC Friday, 2019-10-04. The IAB and IESG will hold a joint teleconference to discuss the proposals. ADs will be expected to approve or disapprove the BOF request on that teleconference, ensuring that the Secretariat has all of the information to put the first draft of the agenda together on or before 2019-10-11.

Applications and Real-Time


Long Name: WebTransport

Abbreviation: webtrans

Description: WebTransport complements WebSocket by providing Web applications access to better performing network communications allowed by modern protocols such as HTTP/3 and QUIC. WebTransport provides a mechanism for reliable and unreliable bidirectional client-server transmission of data in a way that provides security guarantees and fits into the Web security model. There is interest in the W3C to make a WebTransport API available to the Web, the potential new WEBTRANS IETF Working Group would define the protocols and protocol extensions underlying this new Web API.

This is a working group forming BoF.

Responsible Area Directors: ART area ADs

BoF Proponents:

Number of people expected to attend: 35 (so make it 100)

Length of session (1, 1.5, 2, or 2.5 hours): 2 hours

Conflicts to avoid: quic httpbis core tls dnssd tsvarea taps ice


Relevant Internet Drafts:

Protocols or practices that already exist in this space: WebSocket (RFC 6455) -- WebTransport intends to compliment what WebSocket did for QUIC and other transport protocols More related work described in https://tools.ietf.org/html/draft-vvv-webtransport-overview-00#section-1.1

Modifications to existing protocols or practices: The plan is to define extensions to QUIC and HTTP/3. The proposed extensions are described in draft-vvv-webtransport-quic and draft-vvv-webtransport-http3, respectively.

Entirely new protocols or practices: draft-vvv-webtransport-quic defines a new application-level protocol on top of QUIC. The proposed working group would have to design a TCP-based fallback protocol with QUIC-compatible semantics, for cases where UDP is blocked.

Open source implementations: Chromium is currently implementing a client Google QUIC library will support both client and server





Operations and Management




Name: Reliable and Available Wireless (RAW)


  • The wireless and wired media are fundamentally different at the physical level, and while the generic Problem Statement for DetNet applies to the wired as well as the wireless media, the methods to approach determinism differ from those used to support time-sensitive networking over wires. Wireless networks operate on a shared medium, and thus transmissions cannot be fully deterministic due to uncontrolled interferences, including the self-induced multipath fading.
  • However, scheduling of transmissions can alleviate those effects by leveraging redundancy by replication or Forward Error Correction, and diversity in the spatial, time and frequency domains, providing a more predictable and available service. But using redundancy and diversity implies consumption of precious resources and there is a always a tension between energy conservation, shared spectrum efficiency, and quality of service that must be resolved dynamically.
  • The radio conditions may change -way- faster than a centralized routing can adapt and reprogram, mostly so when programming a path deep inside a wireless mesh. RAW separates the routing time scale at which a complex path is recomputed from the forwarding time scale at which the forwarding decision is taken for an individual packet. RAW operates at the forwarded time scale. The RAW problem is to decide, within the redundant solutions that are proposed by the routing, which will be used for each individual packet to ensure the DetNet service while minimizing the waste of resources. A RAW solution would consist in a set of tools that evaluate the media in real time and another that controls the use of redundancy and diversity that is available along the path.
  • A wireless solution needs to adapt to the recent advances in scheduled MAC/PHY technologies such as Wi-Fi6 and 5G. The crowd that understands the particular issues of making wireless more deterministic comes from different horizons and does not necessarily share the main interests of the DetNet WG at this time (e.g., encapsulation over MPLS and pseudowires). Folks from MANET would be highly welcome and common skills and tools would certainly apply, but both mobile and adhoc are highly antagonistic to determinism.

Status: WG Forming


  • Items, drafts, speakers, timing
  • Or a URL

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.





IAB Sessions


  • Long Name: "Community Process for RSE Model Evolution"
  • Abbreviation: RSEME
  • Responsible Area: IAB
  • Chairs: Heather Flanagan
  • Length: 90 minutes
  • Conflicts: Any BoFs? or GEN area meetings; as small a number of other conflicting attendees as possible.
  • Mailing list: rfc-interest@rfc-editor.org
  • Number of people: 150
  • Description: As a follow-on to the virtual interim meetings convened to gather community input on the process for RSE model evolution, this meeting will discuss proposals for the structure of the process.

Previous meeting BOFs

Timeframe IETF 106 (Singapore)?

Timeframe IETF 105 (Montreal)

Timeframe IETF 104 (Prague)

Timeframe IETF 103 (Bangkok)

Timeframe IETF 102 (Montreal)

Timeframe IETF 101 (London)

Timeframe IETF 100 (Singapore)

Timeframe IETF 99 (Prague)

Timeframe IETF 98 (Chicago)

Timeframe IETF 97 (Seoul)

Timeframe IETF 96 (Berlin)

Timeframe IETF 95 (Buenos Aires)

Timeframe IETF 94 (Yokohama)

Timeframe IETF 93 (Prague)

Timeframe IETF 92 (Dallas)

Timeframe IETF 91 (Honolulu)

Timeframe IETF 90 (Toronto)

Timeframe IETF 89 (London)

Timeframe IETF 88 (Vancouver)

Timeframe IETF 87 (Berlin)

Timeframe IETF 86 (Orlando)

Timeframe IETF 85 (Atlanta)

Timeframe IETF 84 (Vancouver)

Timeframe IETF 83 (Paris)

Timeframe IETF 82 (Taipei)

Timeframe IETF 81 (Quebec City)

Timeframe IETF 80 (Prague)

Timeframe IETF 79 (Beijing)

Timeframe IETF 78 (Maastricht)

Timeframe IETF 77 (Anaheim)

Timeframe IETF 76 (Hiroshima)

Timeframe IETF 75 (Stockholm)

Timeframe IETF 74 (San Francisco)

Timeframe IETF 73 (Minneapolis)

Timeframe IETF 72 (Dublin)

Timeframe IETF 71 (Philadelphia)

Timeframe IETF 70 (Vancouver)

Timeframe IETF 69 (Chicago)

Timeframe IETF 68 (Prague)

Timeframe IETF 67 (San Diego)

Timeframe IETF 66 (Montreal)

Timeframe IETF 65 (Dallas)