* 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 92 (Dallas)

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

Applications

LUCID (Approved as BOF for IETF 92)

  • Name: Locale-free UniCode? Identifiers (LUCID)
  • Description: IAB has recently issued a statement about issues found by the use of some class of code points in the IDNA protocol and also applies to any identifier. The IAB expects that the IETF investigate ways to address this problem. Work could be done in existing wg such as precis or elsewhere. The purpose of the BOF is to define a plan.
  • Agenda: something like: 1) Problem statement and scope 2) possible ways to address the problem 3) next steps in IETF.
  • Status: TBD (most likely not WG forming)
  • Responsible AD: Barry Leiba
  • BoF proponents: Marc Blanchet <marc.blanchet@viagenie.ca>
  • BoF chairs: TBD
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hour
  • Conflicts to avoid (whole Areas and/or WGs): precis, apparea; schedule sometime after WG chair lunch on Wednesday
  • Does it require Meetecho? Yes
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.
  • Mailing List: none currently. discussions about the subject were held on ​idna-update@alvestrand.no
  • Draft charter: ​None yet.
  • Relevant documents:

General

Internet

Operations and Management

SUPA (Approved as BOF for IETF 92)

RAI

MODERN (Approved as BOF for IETF 92)

  • Name: Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (MODERN)
  • Description:

The MODERN working group will define a set of Internet-based mechanisms for the purposes of managing and resolving telephone numbers (TNs) in an IP environment. Existing mechanisms for these purposes face obsolescence as the voice communications infrastructure evolves to IP technology and new applications for TNs become possible. The traditional model of a TN having an association to a single service provider and a single application is breaking down. Its use as a network locator is going away, but its use as an identifier for an individual or an organization will remain for some time. Devices, applications, and network tools increasingly need to manage TNs, including requesting and acquiring TN delegations from authorities.

The TeRQ proposal (effectively an ENUM replacement) was previously submitted to the DISPATCH process in the RAI Area and given a favorable reception. This charter continues that work but considers a broader set of problems than TeRQ, including systems for acquiring telephone numbers and looking up metadata associated with telephone numbers. It will also draw on the work that has been done in STIR since TeRQ was proposed to add a strong security dimension to number management on the Internet.

  • Agenda: TBD

NETVC (Approved as BOF for IETF 92)

  • Name: Internet Video Codec
  • Description:

The Internet needs a royalty-free (RF) video codec that can become the backbone for universal deployment of video related technologies. Royalty-bearing codecs put constraints on implementors that are unacceptable, but current RF codecs are not yet competitive with royalty-bearing offerings. This dilemma stalls innovation in the space and means large sets of consumers don't have access to the best video technology.

There are efforts underway by several groups to produce a next-generation, royalty-free (RF) video codec, including VP10 by Google and Daala by Mozilla/Xiph.Org. While far from complete, these efforts aim to surpass the royalty-bearing competition. Efforts within other standards organizations like MPEG to create RF video standards have been unsuccessful so far, but have showed that many consumer device manufacturers would support an RF codec.

The success of Opus from the CODEC WG has also shown that collaboration, based on the IETF's principals of open participation, can produce better results than competition between patented technologies. The IPR rules in BCP 78 and 79 are also critical for success. They impose a duty to disclose, and require exact patent or patent application numbers, in addition to basic licensing terms. This allows participants to evaluate the risk of infringement and, if appropriate, design work arounds, in any technology adopted, and assess the cost of adopting such technology. Because it does not force participants to agree to license their patents under RF terms, it helps to encourage participation even by those opposed to such terms (instead of guaranteeing they stay away). In addition to an environment which encourages third-party disclosures, this provides much better chances of success than SDOs which have a "patent-blind" process or which require blanket RF grants.

  • Agenda:
  1. Note Well, logistics, agenda bashing (5 minutes, Chairs)
  2. Introduction and scoping of BoF (AD, 10 min)
  3. Goals (Chairs, 10m)
  4. Progress to date (10 minutes, Chairs)
  5. Codec Considerations (15m)
  6. Daala coding tools and progress (15m)
  7. Charter discussion (35 minutes, moderated by Chairs)
  8. Questions to be answered (20 minutes, moderated by Chairs)

Routing

BIER (Approved as BOF for IETF 92; currently Proposed WG)

  • Name: Bit-Indexed Explict Replication - BIER
  • Description:
    • Placeholder for either WG or BoF if not chartered in time. If not, this will serve as the second BIER BoF, with the intention of forming a WG.
    • There is a need to simplify network operations for multicast services. Current solutions require a tree-building control plane, which maintains end-to-end tree state per flow, impacting router state capacity and network convergence times. Multi-point tree building protocols are often considered complex to deploy and debug and include mechanics from legacy use-cases and/or assumptions which may no longer apply to the current deployments. When multicast services are transiting a provider network through an overlay, the core network has a choice to either aggregate customer state into a minimum set of core states resulting in flooding traffic to unwanted network end-points, or to map per-customer, per-flow tree state directly into the provider core state amplifying the network-wide state problem.
    • This BOF intends to discuss a new architecture for the forwarding of multicast data packets. The goal is to provide optimal forwarding of multicast packets through a "multicast domain" without requiring an explicit tree-building protocol, nor requiring intermediate nodes to maintain any per-flow state. This work already has wide support from numerous vendors and operators.
  • Agenda
    • TBD
  • Status: WG Forming
    • BIER will require extensions to IGPs and BGP in addition to the architecture and encapsulation descriptions. For this reason BIER may require a dedicated working group which will focus on the overall architecture, solutions and shepherd the work toward consensus in the various other location where work is needed. But at this time the BoF objective is to solicit discussion from the community, and gauge the interest in further developing this work at the IETF. Decision for support, a follow-up BoF, or adoption of work by a new or existing working group will be made later.
  • Responsible AD: Alia Atlas
  • BoF proponents: IJsbrand Wijnands (​ice@cisco.com), Greg Shepherd (​gjshep@gmail.com), Eric Rosen (​erosen@cisco.com), Christian Martin (​martincj@cisco.com), Antoni Przygienda (​antoni.przygienda@ericsson.com), Jeff Tantsura (​jeff.tantsura@ericsson.com), Arkadiy Gulko (​arkadiy.gulko@thomsonreuters.com), Wim Henderickx (​wim.henderickx@alcatel-lucent.com), Andrew Dolganow (​andrew.dolganow@alcatel-lucent.com), Sam Aldrin (​aldrin.ietf@gmail.com), Mach Chen (​mach.chen@huawei.com)
  • BoF Chairs: Greg Shepherd <gjshep@gmail.com>, TBD
  • Number of people expected to attend: 150
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid: MPLS, PIM, MBONED, L3VPN, L2VPN, 6MAN, V6OPS, OPSArea, IntArea?, RTG, BGP, NVO3, TRILL, SPRING
  • Does it require Meetecho? yes - potential remote participants
  • Mailing List: ​https://www.ietf.org/mailman/listinfo/bier
  • Relevant drafts: http://datatracker.ietf.org/wg/bier/documents/

Security

ACME (Approved as BOF for IETF 92)

Name: Automated Certificate Management Environment (ACME)
Description: Discussion of work that is going on with automated certificate management. Let's Encrypt will obviously be a primary discussion point, but we hope to have other CAs and other stakeholders represented.
Status: Non-WG Forming
Responsible AD: Stephen Farrell
BoF proponents: Eric Rescorla <ekr@rtfm.com>
BoF Chairs: Ted Hardie and Rich Salz
Number of people expected to attend: 100
Length of session: 1 hour
Conflicts to avoid: SEC area, httpbis, webrtc
Does it require Meetecho? yes - potential remote participants
Mailing List: https://www.ietf.org/mailman/listinfo/acme
Relevant drafts: https://tools.ietf.org/html/draft-barnes-acme-01

TOKBIND (Approved as BOF for IETF 92; currently Proposed WG)

Long name and abbreviation: Token Binding (TOKBIND)
This is a placeholder for an in-formation WG.
The responsible Area Director: Stephen Farrell
BoF Chairs: TBD
Number of people expected to attend: 75
Length of session: 1.5 hours
Conflicts to avoid: SEC Area, httpbis, websec
Does it require WebEX? Maybe
Does it require Meetecho? Maybe
Links:

https://datatracker.ietf.org/doc/charter-ietf-tokbind/

I2NSF (Not Approved as BOF for IETF 92)

  • Name: Interface to Network Security Functions (I2NSF)
  • Description, WG forming:
    • Enterprises, residential, and mobile customers are increasingly consuming network functions, especially network security related functions that are not running on their premises. In addition, the ETSI Network Function Virtualization (NFV) initiative creates new management challenges for security policies to be enforced by distributed, virtual, network security functions (vNSF). These trends require a standard interface to express, monitor, and manage security policies for physical and virtual distributed security functions that may be running on different premises.
    • In order to address the above challenges, vNSF devices may include two functional layers:
      1. Security Service and Policy Layer
      2. Functional Layer
    • The Security Policy Layer is for clients to express and monitor security policies for their specific flows, which is security service oriented. This layer will leverage existing protocols, such as those defined in RESTconf, Netconf, AAA, and SACM, to carry security policies that can be expressed by Discretionary Access Control, Mandatory Access Control, Role Based Access Control, Attribute-Based Access Control, Policy-Based Access Control, or combinations of these.
    • The Functional Layer specifies how client security policies can request the functions of security devices, and then map security policies to a form that security devices can use. This requires the definition of an information model, along with one or more data models, to represent virtual and physical security functions and devices. This layer will leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.
    • The ultimate goal of I2NSF is to establish how to communicate with vNSF and how to get performance data or report out of vNSF.
    • I2NSF enables clients to communicate their specific security policies (request/monitor/report) to a system, and map these security policies to the security functions present in security devices in that system. I2NSF will specify a set of standardized mechanisms for clients and applications to request, negotiate, manage, and validate security functions using a declarative programmatic interface to physical and virtual devices. In order to support this programmatic interface, an Information Model will be defined to serve as a common vocabulary of security policy concepts and security function capability; associated Data Models will be derived from this Information Model to support Operation, Administration, Maintenance and Provisioning (OAMP) functions for security policies and security functions.
    • Since different security vendors support different features & functions on their devices, I2NSF will focus on a few specific security functions. I2NSF will start with Flow Based Security Functions. Flow Based Security Functions provide treatment to packets/flows, such as IPS/IDS, Web filter, and Stateless flow filter. (They are different from Application layer security functions, such as email filter, virus treatment, etc). Exemplar services associated with Flow Based Security functions include deep packet inspection, packet/flow/stream filtering, and redirection (remote and local). Exemplar IDS/IDP functions includes flow/stream pattern matching and remediation, respectively.
    • The purpose of the focused security functions is to make the I2NSF discussion more focused and to validate if the proposed mechanisms to communicate with NSF work properly. Similar to I2RS focusing on the interface to RIB/FIB even though most routers provide far more functions than RIB/FIB, the I2NSF focused functions can be a portion of features supported by vendors’ specific devices.
    • It is a non-goal to create new protocols or data modeling languages for I2NSF interfaces.

https://datatracker.ietf.org/doc/draft-pastor-i2nsf-access-usecases/
https://datatracker.ietf.org/doc/draft-qi-i2nsf-access-network-usecase/
https://datatracker.ietf.org/doc/draft-zarny-i2nsf-data-center-use-cases/
https://datatracker.ietf.org/doc/draft-dunbar-i2nsf-problem-statement/
https://datatracker.ietf.org/doc/draft-xia-i2nsf-capability-interface-im/
https://datatracker.ietf.org/doc/draft-zhang-gap-analysis/
https://datatracker.ietf.org/doc/draft-xia-i2nsf-service-interface-dm/
https://datatracker.ietf.org/doc/draft-strassner-i2nfs-info-model/

DOTS (Approved as BOF for IETF 92)

  • Name: DDoS Open Threat Signaling (DOTS)
  • Description:
    There is a need for a standards based approach for on-premise DDoS mitigation devices to communicate threat and telemetry data to service provider based solutions. On-premise DDoS mitigation devices are sophisticated entities which may already identify, profile and mitigate a wide range of attacks. Although flow export, syslog and SNMP are currently used by service providers to identify anomalies, there is no agreed standard allowing for any device to signal to any other device or service provider what the anomaly is and the subsequent threat telemetry data.

DDoS open threat signaling (DOTS) would enable any on-premise DDoS mitigation device to effectively communicate the current threat landscape, load and response data to a mitigation service provider. The upstream solution would then have a clear view of the threat should the on-premise solution be required to offramp attack traffic to a more capable handler. A vendor agnostic approach would allow any combination of vendor, service provider or community driven efforts to interoperate. DOTS would be extensible and may, in future, be expanded as a method of real time information exchange between other security devices and, potentially across organisations.

Verisign and Juniper have supported this work on standardized DOTS, and this work has resulted in an input specification for this proposed non-working group forming BOF.

  • The responsible Area Director (AD): Kathleen Moriarty
  • BoF proponents: Nik Teague nteague@verisign.com
  • BoF Chairs: Russ Housley & Roman Danyliw
  • Number of people expected to attend: 150
  • Length of session: 1.5 hours
  • Conflicts to avoid: IPFIX, MILE, SACM, I2NSF, SAAG, OPSAWG, OPSAREA
  • Does it require WebEX? No, meetecho is enough
  • Does it require Meetecho? Yes for remote attendees
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.:

Mailing list: https://www.ietf.org/mailman/listinfo/dots
http://tools.ietf.org/html/draft-teague-open-threat-signaling-00

Transport

SPUD (Approved as BOF for IETF 92)

  • Name: Session Protocol for User Datagrams (SPUD)
  • Description:
    • The deployment of new transport protocols as well as the extension of existing IETF-defined transport protocols faces the continuing challenge of how to make these protocols robust against packet and flow modification in the Internet at the hands of middleboxes. The increasing deployment of these packet modifications have made expectations about packet handling behaviors implicit. For example, a TCP packet with the SYN and ACK flags set not only synchronizes sequence numbers and set up state on both endpoints for a TCP connection (its explicit meaning), it also confirms network address translation (NAT) mappings along the path as well as signifying to any firewalls along the path that the endpoint has accepted the connection (implicit meanings).
    • One strategy to resolve this tussle, identified and discussed during the recent IAB workshop on Stack Evolution in a Middlebox Internet (SEMI), would be to provide a mechanism for applications at the end as well as boxes along the path to explicitly declare their assumptions and intentions.
    • Following the discussion at SEMI, approaches under consideration involve:
      1. the use of identifiers beyond the five-tuple to link packets together into related sets (which we call sub-transport sessions),
      2. explicit signaling and negotiation of sub-transport session start and end,
      3. an extensible channel allowing midpoints and endpoints to signal appropriate additional information about path conditions and application requirements.
    • This session will examine use cases found in draft-hardie-spud-use-cases-00.txt, an initial protocol concept in draft-hildebrand-spud-prototype-00.txt, and considerations for interactions between such a protocol and (D)TLS in draft-huitema-spud-tls-00.txt. Discussion of use cases will consider incentives for incremental deployment. Background on the concepts under discussion is provided in B. Trammell and J. Hildebrand, "Evolving Transport in the Internet", IEEE Internet Computing, September 2014. http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6886121
  • Agenda
  • Status: Non-WG Forming
  • Responsible AD: Spencer Dawkins
  • BoF proponents: Joe Hildebrand <jhildebr@cisco.com>, Brian Trammell <ietf@trammell.ch>
  • BoF chairs: Mirja Kuehlewind <mirjak@tik.ee.ethz.ch>, Eliot Lear <elear@cisco.com>
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): tsvwg, tsvarea, taps, tcpinc, tcpm, tls, appsarea, webrtc, intarea, tram, httpbis, avtcore; please schedule after the Tech Plenary on Monday
  • Does it require WebEX? No
  • Does it require Meetecho? No
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

IAB Sessions

Previous meeting BOFs

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)