* 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 http://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)
  • Does it require WebEX? If so, why?
  • Does it require Meetecho? If so, why?
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Template for BOF Entry

Timeframe IETF 93 (Prague)

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


Name: CAPtive PORTal interaction (CAPPORT)

Description: Improve the interaction with captive portals. Captive portals are used in many locations (e.g coffeeshops, hotels). With a move to a more secure Internet, the interception techniques become increasingly problematic. The user experience also leaves much to be desired. This BoF seeks to understand if there is sufficient energy to work on the problem and design a protocol for interacting with captive portals.

Agenda [ To be filled in ]

Status: WG Forming

Responsible AD: Barry Leiba

BoF proponents: Warren Kumari (warren@kumari.net), Mark Nottingham (mnot@mnot.net)

BoF chairs: Warren Kumari (warren@kumari.net), Mark Nottingham (mnot@mnot.net) (proposed)

Number of people expected to attend: 100

Length of session: 1.5 hours (we are fine with longer, whatever works best for scheduling)

Conflicts to avoid: 1st: DANE, DPRIVE, OpsAWG (WK co-chairs these), httpbis 2nd: DNSOP, appawg

Does it require WebEX? No

Does it require Meetecho? Yes

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

Mailing List: ​https://www.ietf.org/mailman/listinfo/captive-portals

Other info: https://github.com/httpwg/wiki/wiki/Captive-Portals

Draft charter: TBD

[ Note: This is a proposed BoF - we are still determining if we sufficient interest to burn meeting time, but figured worth filling in the form now. We had a bar BoF in Dallas with significant interest. See: https://github.com/httpwg/wiki/wiki/Captive-Portals ]



Operations and Management



Name: Deterministic Networking (detnet)


Operational Technology (OT) refers to industrial networks that are typically used for monitoring systems and supporting control loops, as well as movement detection systems for use in process control (i.e., continuous manufacturing) and factory automation (i.e., discrete manufacturing). Due to its different goals, OT has evolved in parallel but in a manner that is radically different from Information Technology/Information? and Communications Technology (IT/ICT), focusing on highly secure, reliable and deterministic networks, with limited scalability over a bounded area.

In OT environments, deterministic networks are characterized as providing a guaranteed bandwidth with extremely low packet loss rates, bounded latency, and low jitter.

In parallel, the need for determinism in professional and home audio/video markets drove the formation of the Audio/Video Bridging (AVB) standards efforts in IEEE 802.1. With the demand for connectivity and multimedia in transportation, AVB is being evaluated for application in vehicle head units, rear seat entertainment modules, amplifiers, camera modules, and engine control systems. Automotive AVB networks share the OT requirements for deterministic networks characteristics.

This wider application scope for deterministic networks has led to the IEEE 802.1 AVB Task Group becoming the Time-Sensitive Networking (TSN) Task Group (TG), covering industrial and vehicular applications. The networks in consideration are extending beyond the LAN boundaries and require secure deterministic forwarding and connectivity over a Layer 2/Layer 3 network. The properties of deterministic networks will have specific requirements for the use of routed networks to support these applications.


Status: WG Forming



BoF proponents: Jouni Korhonen <jouni.korhonen@broadcom.com>, Pascal Thubert <pthubert@cisco.com>


Number of people expected to attend: 150

Length of session: 2 hours

Conflicts to avoid: PCE, TEAS, CCAMP, 6TiSCH

Does it require WebEX? Yes

Does it require Meetecho? Yes

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


Name: Automated Certificate Management Environment (ACME)

Description: Discussion of work that is going on with automated certificate management, following on to the BoF session in Dallas and the mailing list discussion since then.


Status: WG Forming

Responsible AD: Kathleen Moriarty

BoF proponents: Ted Hardie <ted.ietf@gmail.com>, Rich Salz <rsalz@akamai.com>

BoF chairs: Ted Hardie, Rich Salz

Number of people expected to attend: 100

Length of session: 2 hours

Conflicts to avoid: Security Area, RTCWEB, webpush, httpbis

Does it require WebEX? No

Does it require Meetecho? Yes

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

Name: Interface to Network Security Functions (I2NSF)


In a nutshell, I2NSF wants to define interfaces to the flow based network security functions hosted by service providers at different premises.

Network security functions (NSFs) are provided and consumed in increasingly diverse environments. Users of NSFs could consume network security services hosted by one or more providers, which may be their own enterprise, service providers, or a combination of both. Likewise, service providers of NSFs may offer their customers network security services that consist of multiple security products and/or functions from different vendors. NSFs may be provided by physical and/or virtualized infrastructure. Without standard interfaces to express, monitor, and control security policies that govern the behavior of NSFs, it becomes virtually impossible for security service providers to automate their service offerings that utilize different security functions from multiple vendors.

The primary goal of I2NSF is to define an information model, a set of software interfaces and data models for controlling and monitoring aspects of NSFs (both physical and virtual). Other aspects of NSFs such as device or network provisioning and configuration are out of scope. Controlling and monitoring of NSFs should include the use of policies to specify, query, monitor, and control the NSFs by one or more management entities. Since different security vendors support different features and functions on their devices, I2NSF will focus on flow based NSFs that provide treatment to packets/flows, such as IPS/IDS, Web filtering, flow filtering, deep packet inspection, or pattern matching and remediation.


  • Introduction of I2NSF BOF (Chairs, 10 min)
  • Merged Use cases (10 min)
  • problem space (10 min)
  • Gap analysis, especially to answer questions like:
    • Is it within IETF scope & expertise? (why not OpenStack?, security alliance . .)
    • Why need a new WG? (why not done at SACM, I2RS, NETCONF, NETMOD, SFC, ANIMA, PCP, . . .?)
  • Potential solutions
    • Packet-Based Paradigm For Interfaces To NSFs
    • Capability interface Information model
  • Charter Bashing: http://www.ietf.org/mail-archive/web/i2nsf/current/msg00441.html
  • Hard Questions

Status: WG Forming

Responsible AD: Kathleen Moriarty

BoF proponents: Diego Lopez diego.r.lopez@telefonica.com, Christian Jacquenet christian.jacquenet@orange.com, Myo Zarny Myo.Zarny@gs.com, Shaibal Chakrabarty shaibalc@us-ignite.org, Linda Dunbar linda.dunbar@huawei.com

BoF chairs: TBD

Number of people expected to attend: 60

Length of session: 2 hours

Conflicts to avoid: SACM, SAAS, nfvrg, I2RS, IDR, SDNrg, TRILL, LMAP, XRBLOCK, SUPA, SFC, NVO3

Does it require WebEX? No

Does it require Meetecho? Yes

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


IAB Sessions

Previous meeting BOFs

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)