* 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.

Template for BOF Entry

Timeframe IETF 95 (Buenos Aires)

Current schedule of "Important Dates" requires that all BOF proposal requests be submitted to Area Directors (ADs) by 2359 UTC Friday, 2016-02-19. 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 2016-03-04.

Applications and Real-Time



  • Name: Alternative Resolution Contexts for Internet Naming (ARCING)
  • Description: RFC 819 described Internet names as a set of directed graphs in an absolute naming context. While that work eventually lead into the creation of the domain name system, it is important to note that it does not imply that there will be a single resolution system for Internet names. While the most common Internet names by far are those which are part of the domain name system, that set of names is not the whole. A number of independent naming and resolution contexts have emerged. In addition to those created for onion routing and multicast DNS, there are large sets associated with the Handle system, URNs, and Internet scale proprietary names (e.g. twitter handles).

It is apparent that the desire to re-use Internet protocols that default to DNS-based resolution in other resolution contexts has created ambiguities in what resolution context should be used for individual names. Those ambiguities may be expressed in operational difficulties (queries in the wrong context) and in concerns about limitations implied for DNS-based names.

The proponent believe that the IETF should describe the architectural issue and document best practices for identifying alternative resolution contexts. Among those best practices might be the creation of a registry that associates specific resolution contexts with the method they have chosen to use for identification. We note that discussions have been ongoing on related topics within the DNSOP WG, but we believe that a broader community is required to discuss and resolve the issue.

  • Agenda
    • Problem statement
    • Alternatives methods for identifying resolution context within existing protocols
    • Registration methods
      • Outside the DNS
      • Within a DNS-subtree
      • Using DNS syntax
      • Discussion
  • Status: TBD
  • Mailing list: arcing@ietf.org
  • Responsible AD: TBD
  • BoF proponents: Ted Hardie, Andrew Sullivan, Suzanne Woolf
  • BoF chairs: TBD
  • Number of attendees: 100
  • Length of session: 2 or 2.5 hours
  • Conflicts: Internet Area, DPRIVE, DNSOP, SAAG, RTCWEB, ACME, MAPRG, STIR, TCPINC, ACCORD BoF, homenet, dnssd

Operations and Management



  • Name: Limited Use of Remote Keys (lurk)
  • Status: Non wg-forming, but if it goes well, we may follow up and charter before Berlin
  • Description: Communication protocols like IPsec, SSH or TLS provide means to authenticate the remote peer. Authentication is based on the proof of ownership of a private key. Currently most trust models assume private keys are associated and owned by the communication peers and that the remote peer is responsible for both the hosted content and for the network delivery. Although these assumptions were largely true in the past, today, the deployment of services on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. In such architectures, the application - like a web browser - expects to authenticate a content provider but is actually authenticating the node delivering the content. In this case, the confusion mostly results from using a secure transport layer to authenticate application layer content.
  • List discussion has established that there is interest in dealing with the "offload TLS without giving the CDN my private key" use-case - hopefully the BoF session will help to clarify if other use-cases also need to be tackled, and with establishing if there is sufficient interest to tackle work in this space.
  • Responsible Area Director: Stephen Farrell
  • BoF Chairs: Yaron Sheffer, Eric Burger
  • Number of people expected to attend: 60
  • Length of session: 2 hours
  • Conflicts to avoid: SEC, httpbis, MILE, STIR
  • Mailing list:
  • Drafts (note: the list has not yet had detailed discussion of these):


  • Name: Alternatives to Content Classification for Operator Resource Deployment (ACCORD)
  • Description: Mobile Radio Access Networks (RANs) have historically allowed content-type based classification to associate service descriptions with flows, with the goal of efficient use of the often volatile radio bearer. The increased use of TLS and other encrypted transports eliminates this metadata from the view of the operator and forces a re-examination of this method.

While having endpoints expose classification of this and other metadata to the RAN outside the encrypted channel would restore this, it would degrade the confidentiality expected and require extensive coordination among application developers, user endpoint manufacturers and RAN operators. To avoid the disadvantages of that approach, we wish to examine both what specific network treatments need to be elicited for the efficient operation of RANs, if any, and what the minimal communication to elicit those treatments would be.

  • Agenda
    • Review of current 3GPP architectural use of content-based​ classification for radio resource allocation (Kevin Smith)
    • Alternatives for current or future architectures:
    • Zero-bit AQM alternative
    • 1 bit alternative signal
    • Delay, throughput, and reliability, hmm, haven’t we seen that before? RFC 791 TOS bits refresher.
    • Modern DSCP marking
    • Discussion
  • Status: not WG forming
  • Mailing list: accord@ietf.org
  • Responsible AD: Spencer Dawkins
  • BoF proponents: Ted Hardie, Brian Trammell, Joe Hildebrand
  • BoF chairs: TBD
  • Number of attendees: 100
  • Length of session: 2 or 2.5 hours
  • Conflicts: Transport Area, SAAG, RTCWEB, ACME, MAPRG, TCPINC, CDNi, NFVRG​, DISPATCH​

IAB Sessions

Previous meeting BOFs

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)