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

Timeframe IETF 96 (Berlin)

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

Applications and Real-Time


  • Name: SIP Best-practice Recommendations Against Network Dangers to privacY (SIPBRANDY) [Placeholder for working group in formation)
  • Description : The SIPBRANDY working group will define best practices for establishing two-party, SIP-signaled SRTP sessions with end-to-end security associations, including a single, preferred SRTP key exchange mechanism. These practices are expected to be deployable across typical SIP networks, without the sharing of SRTP keying material with intermediaries or third parties. These practices should protect against man-in-the-middle attacks.
  • Status: Placeholder for WG in formation.
  • The responsible Area Director (AD): Ben Campbell
  • BoF Chairs (or the ADs as placeholders): Gonzalo Camarillo
  • Number of people expected to attend: 50 (subject to change)
  • Length of session: 1 hr
  • Conflicts to avoid: Security Area, dispatch, sipcore, avtcore, avtext, payload,clue, ice, mmusic, modern, stir, netvc, perc, rtcweb,
  • Draft Charter: https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/


  • Name: Ledger (ledger)
  • Description:

Moving digital assets (making payments) between accounts operating on different payment networks or ledgers is not possible in an open, inter-operable way. Interledger is a protocol stack for doing this (tranfering digital assets) over the Internet.

The project was started within a W3C community group in October 2015 and has produced a number of technical specifications which are candidate Internet Drafts.

It defines a set of formats for representing digital asset transactions and protocols for executing those transactions in a secure and verifiable manner.

The purpose of this BoF is to introduce Interledger and the underlying protocols to attendees and discuss how this work might progress at the IETF including possible adoption of the Crypto-conditions specification by an existing IETF WG.

GGIE - NOT APPROVED (will be in Dispatch)

  • Name: Glass to Glass Internet Ecosystem (GGIE)
  • Description: Video is without rival the top use of Internet bandwidth, and its ever growing demand for more bandwidth easily out paces the new capacity being added both globally and regionally with no let up in sight.

The Glass to Glass Internet Ecosystem (GGIE) approach posits that streamed content delivery can be viewed like a composed flow combining many parts with playback composed of one or more component streams from one or more addresses to one or more devices over one or more networks. We have identified 3 high level gaps that are relevant at the IETF:

  • How applications identify, search for & refer to content
  • How devices locate and address video sources
  • How application level identifiers & network level identifiers are mapped to one another

The purpose of this BoF is to raise awareness of the video issue and progress made on possible paths forward for IETF work.

  • Agenda
    • Administrivia
      • Scribe / note taker
      • Agenda bash
    • BRIEF overview of GGIE [Glenn Deen]
    • Demonstration of video streaming using GGIE principles [Gaurav Naik]
    • Outline of open questions / setting the stage for discussion [Leslie Daigle]
    • Discussion [all]
      • Looking to identify possible specific chunks of IETF work going forward.



  • Long name and abbreviation: Meeting Venue (MTGVENUE)
  • Description, including whether the BoF is intended to form a WG or not: this is a planned WG by Berlin
  • The responsible Area Director (AD): Jari Arkko
  • BoF Chairs (or the ADs as placeholders): TBD
  • Number of people expected to attend: 200
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5h
  • Conflicts to avoid (whole Areas and/or WGs): other area meetings, other Gen meetings
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.: https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-01[[BR]]


  • Name: International Meeting Arrangements (imtg)
  • Description: Informational session with outside experts to discuss human rights, visas, and other aspects of international meeting arrangements.
  • Agenda: Highly TBD. Hoping for:
    • Outside speaker(s) presentation about human rights in an international context, plus Q&A
  • Status: Informational session, not any kind of BoF
  • Responsible AD: Alissa Cooper
  • Number of people expected to attend: 100
  • Length of session: 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): mtgvenue, hrpc, art area WGs



  • Name: Low-Power Wide Area Networks (LPWAN) (formerly: IPv6 over Low-Power Wide Area Networks (6LPWA))
  • Description:

A new generation of wireless access technologies has emerged under the generic name of Low-Power Wide-Area (LPWA), with a number of common characteristics which make these technologies unique and disruptive for Internet of Things applications. Typical LPWA Networks provide low-rate connectivity to vast numbers of battery-powered devices over distances that may span tens of miles, using license-exempt bands. Existing pilot deployments have shown the huge potential and met industrial interest, but the loose coupling with the Internet makes the device management and network operation complex and implementation specific. As of today, there is little to no use of IETF technologies in LPWANs at large, and there is a need to evaluate their applicability to contribute to the emerging needs of these technologies, in terms of longevity, scalability or better integration to existing systems and processes.

  • Agenda
    • General introduction, 6LPWA architecture - Alexander Pelov, P. Thubert
    • Selected technologies: presentation and characterization [40mn]
      • Technology slot 1: 3GPP LPWA (NB-IoT / EC-GSM-IoT / Cat-M1) - Antti Ratilainen
      • Technology slot 2: IEEE LPWA (Wi-SUN, IEEE 802.15.4g) - Bob Heile, Jonathan Munoz
      • Technology slot 3: LoRa? - Alper Yegin
      • Technology slot 4: SIGFOX - Juan Carlos Zuniga
    • Applicability and gap analysis of Internet protocols [20mn]
    • Charter and work Items Discussions, led by chairs (< 1H)
      • Interaction model with LPWA technologies (just cross participations? ISGs?)
      • Review proposed work items, one by one


Operations and Management



  • Name: Babel (Babel) [Placeholder for working group in formation)
  • Description : The WG will focus on standardizing Babel as a no-configuration IGP.
  • Status: Placeholder for WG in formation.
  • The responsible Area Director (AD): Alia Atlas
  • BoF Chairs (or the ADs as placeholders): Donald Eastlake and Russ White
  • Number of people expected to attend: 50 (subject to change)
  • Length of session: 2
  • Conflicts to avoid: homenet, 6man, dnssd, v6ops, ospf, isis, rtgwg, trill, saag, lpwan, dnsop, i2rs, netmod, netconf
  • Draft Charter: https://datatracker.ietf.org/doc/charter-ietf-babel/



  • Name: Limited Use of Remote Keys (lurk)
  • Status: WG-forming, the chairs will publish/review a draft charter before Berlin
  • Description: HTTPS in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. Currently most trust models assume private keys are associated and owned by the HTTP server, and that the server 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, with some list participants proposing to also support DTLS in anticipation of future secure protocols. There is ongoing discussion of several additional use-cases. The BoF had a meeting in Buenos Aires and a well-attended virtual interim.
  • Responsible Area Director: Stephen Farrell
  • BoF Chairs: Yaron Sheffer, Eric Burger
  • Number of people expected to attend: 100
  • Length of session: 2 hours
  • Conflicts to avoid: rtcweb, SEC, httpbis, STIR, MODERN, MILE, UTA.
  • Mailing list:
  • Drafts (note: the list has not yet had detailed discussion of these):


  • Name: Some PKIX and S/MIME (spasm)
  • Description, possible BoF of placeholder (or may be cancelled)
  • AD: Stephen Farrell
  • BoF Chairs: TBD
  • Number of people expected to attend: 25
  • Length of session: 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): saag, tls, more TBD
  • Links to the mailing list, https://www.ietf.org/mailman/listinfo/spasm
  • I (SF) just pinged the list to see if folks want to meet, and if so, as a BoF or if they think we can have a WG formed.
  • It's reasonably likely this may not meet. I'll update or delete this before the BoF call in any case.



  • Long name and abbreviation: Information Centric Networking Working Group (icn)
  • Description: This BoF is intended to form a WG. Information Centric Networking (ICN) is a technology for forwarding messages using names. The icnrg has developed experimental specifications for message formats and semantics for an ICN protocol. This BoF will be used to gauge the level of interest from the community, define the scope of a potential WG, determine what items from ICNRG we’re going to carry over and in what form, discuss a possible charter and talk about where and how this work fits in the IETF.
  • Agenda:
  1. (5 minutes) Objective and agenda bashing
  2. (10 minutes) Problem statement
  3. (10 minutes) State of current documents and technology
    1. draft-irtf-icnrg-ccnxsemantics-02
    2. draft-irtf-icnrg-ccnxmessages-02
    3. draft-mosko-icnrg-ccnxurischeme-01
    4. draft-tschudin-icnrg-flic-00
    5. draft-wood-icnrg-ccnxoverudp.txt
    6. draft-mosko-icnrg-beginendfragment-00
    7. draft-mosko-icnrg-ccnxchunking-02
  4. (20 minutes) Scoping/Charter review
  5. (30 minutes) General discussion
  6. (10 minutes) Polling
  7. (5 minutes) Wrap up

Name: Information Centric Networking Working Group (icn)
Chairs: TBD
Area: Transport/Internet (TBD)
Description of WG:

Networks that use named data items as the main communication abstraction have been labeled as Information Centric Networks. The purpose of the ICN working group (icn) is to develop mechanisms and specify protocols for forwarding packets using names.

ICN replaces host-based networking with data-centric networking. The primary elements of interest when using ICN are named data items. The fundamental service provided by an ICN network is to accept requests for named data items and then return the requested data item. The requests and data items are carried in ICN messages, which are forwarded based on names. This Working Group specifically focuses on using names to forward packets; that is, layer 3.

Forwarding packets using names is the cornerstone of the predominant ICN approaches and has been the focus of most academic and industrial research. The request-response data-oriented model used in ICN protocols provides an adaptable, resilient and secure communication environment that provides some advantages relative to the IP/TCP/HTTP/TLS protocol suite: including object-based security, decoupling of producer and sender, location independent name, improved flow control, native indirection and network caching.

More information about ICN can be found here:

Work items for this Working Group

  • Define ICN architecture
  • Define a set of coherent core protocols that provide communication services by forwarding using names.
  • Define a set of transport protocols built on top of the core protocols that communicate at the level of application data units.
  • Define a set of overlay protocols to transport named objects over UDP, MPLS, Ethernet and IEEE802.11

There are some areas that while very related, are out of scope for this Working Group. These include routing, key distribution, novel security techniques, etc.

Milestones (assuming WG formation Aug 2016) :

  • Feb 2017 - Adoption of core protocol specification as WG work item
  • Feb 2017 - Draft ICN architecture published
  • May 2017 - Adoption of ICN-over-UDP specification as WG work item
  • May 2017 - Adoption of ICN-over-Ethernet specification as WG work item
  • Aug 2017 - Adoption of ICN-over-802.11 specification as WG work item
  • Aug 2017 - Adoption of transport protocol specification as WG work item


  • Name: L4S (Low Latency Low Loss Scalable throughput)
  • Description: L4S is a new service that the Internet could provide to eventually replace best efforts for all traffic: Low queuing Latency, Low congestion Loss, Scalable throughput (L4S). With increases in access bit rate, latency not bandwidth is becoming the critical performance factor for most popular applications, such as interactive video, conversational video, voice, Web, gaming, instant messaging, remote desktop and cloud-based apps. This means that often all of a user's applications at any one time will require low latency. L4S addresses this case, unlike Diffserv, which favours some packets at the expense of others. The need to manage what is favoured has limited Diffserv take-up.

The insight behind L4S is that existing 'Classic' TCP congestion controls (e.g. Reno and Cubic) are the root cause of the problem because, as flow rates have increased, their sawtoothing behaviour has led to larger and larger variations in either queuing delay or under-utilization. 'Scalable' congestion controls that solve this problem exist (e.g. Data Centre TCP).

Until now scalable congestion controls did not coexist well with existing 'Classic' traffic so they were confined to controlled network environments like data centres. L4S has been made possible by a new active queue management (AQM) technology that behaves like a semi-permeable membrane - it isolates Scalable from Classic traffic in terms of latency, but behaves as a single queue in terms of bandwidth. So far two different AQM technologies have been implemented within the same framework. Implementations are zero-config and require no packet inspection deeper than the IP layer.

L4S is designed to be incrementally deployable alongside the existing best efforts service. Then all of a user's applications can shift to it when they update their stack. Access networks are typically designed with one link as the bottleneck for each "site" (which might be a home, small business, enterprise or mobile device). So deployment at one (or both) ends of the bottleneck link to a "site" should give nearly all the benefit. However, L4S requires changes to the network and to the host before it is useful. Therefore the BoF has to judge whether the performance benefits of L4S are so significant that operators could offer new applications that would help justify the cost and risk of deployment.

L4S is not only applicable to the public Internet; it would also extend the applicability of DCTCP to multi-tenant cloud data centres and interconnection between Data Centres.

  • The aim of the L4S BoF is therefore:
    • Host: To initiate experimental track work to make 'Scalable' congestion controls for TCP and other transports safe for the public Internet;
    • Network: To initiate experimental track work on AQMs for L4S;
    • Protocol: To reserve an experimental identifier for L4S at the IP layer to ensure host-network interworking.
    Discussions are ongoing on whether to place each activity in an existing WG, or create a new WG for at least some of the items. That will not be the focus of the BoF.
  • Agenda
    • (5mins) Introduction (Chairs)
    • (15mins incl. clarification Qs) The Problem and Very High Level Solution (Bob Briscoe)
    • (15mins incl. clarification Qs) L4S Testbed Demonstration (Koen De Schepper)
    • Activity/ Interest/ Use Cases/ Plans:
      • (5mins incl. clarification Qs) L4S Applicability to Mobile - without flow inspection (Kevin Smith)
      • (5mins incl. clarification Qs) L4S in a 4G/5G context (Ingemar Johansson)
      • (5mins incl. clarification Qs) DCTCP Evolution (Praveen Balasubramanian)
    • (25mins) Discussion about the Technology (Chairs)
    • (10mins) Work required by the IETF (Marcelo Bagnulo Braun)
    • (25mins) Discussion about the work required by IETF (Chairs)
    • (10mins) Polls (Chairs)


  • Name: QUIC
  • Description: QUIC is a UDP-based transport protocol that provides multiplexed streams over an encrypted transport. This BoF proposes a working group to standardize QUIC’s core transport protocol and the mapping of the transport protocol to the facilities of TLS. An additional work item will be to describe how to map the semantics of applications onto the transport. The first mapping will be a description of HTTP/2 semantics using QUIC. Upon completion of that mapping, additional protocols may be added by updating the charter to include them.
  • Agenda
    • A QUIC overview
      • Jana Iyengar
    • Review the current usage of QUIC (30 min)
      • TBD
    • Review the proposed split to create a general wire format (10 min)
      • Jana Iyengar
    • Describe the mapping between it and TLS 1.3 facilities (10 min)
      • TBD
    • Discussion of the problem space’s fit for the IETF (15 min)
      • BoF attendees
    • Charter review (30 min)
      • Chairs
    • Charter Discussion (45 min)
      • BoF attendees


  • Name: PLUS (Path Layer UDP Substrate)
  • Description: The PLUS working group's goal is to enable the deployment of new, encrypted transport protocols, while providing a transport-independent method to signal flow semantics under transport and application control. The approach from which the working group will start is a shim layer based on the User Datagram Protocol (UDP), which provides compatibility with existing middleboxes in the Internet as well as ubiquitous support in endpoints, and provides for userspace implementation. Note that this effort follows from the SPUD BoF in Dallas and the SPUD prototyping effort, and preparation for the BoF has taken place on the SPUD list.
  • Draft Agenda
    • Introduction: Chairs (10 mins)
    • Specific Problem Areas Presentations (45 min)
      • Enterprise network viewpoint: Joe
      • Mobile network viewpoint: Natasha
      • Architectural viewpoint: Ted
    • Proposal & Relevant Discussion Summary: Brian (30 mins)
    • Charter review: Chairs (15 mins)
    • Charter Discussion: BoF attendees (60 mins)

The PLUS working group's goal is to define a common shim layer atop the User Datagram Protocol (UDP) to provide a transport-independent method to signal flow semantics under transport and application control, necessary to enable the deployment of new, encrypted transport protocols within the existing Internet. UDP provides compatibility with currently deployed middleboxes as well as ubiquitous support in endpoints, and supports userspace implementation of new transport protocols. The working group will not specify any new transport protocols.

The current Internet protocol stack does not provide explicit, in-band, transport-independent signaling to on-path network devices. This has led to the deployment of devices which perform implicit discovery of transport semantics and traffic characteristics via inspection of protocol headers and payload, a practice made possible when these are sent in the clear.

In order to support more ubiquitous deployment of encryption, and the encryption of transport headers to allow deployment of new transport protocols, explicit in-band signaling must be added to the stack. This signaling must be transport protocol independent, and the types of information signaled must be based on characteristics that can be independently verified by devices on path, or that can be usefully applied without requiring a trust relationship between endpoints and the path. Further, a feedback channel that provides information from on-path devices back to endpoints and applications, e.g. for error handling, is essential for the deployment and success of an explicit cooperation approach.

While IP would seem to be the natural home for this facility, both IPv4 and IPv6 options and extensions have deployment problems on their own, which makes it hard to include any additional information in these protocols.

The PLUS working group will specify a new protocol as a Path Layer UDP Substrate (PLUS), to support experimental deployment of explicit cooperation between endpoints and devices on path, with the following goals:

  • enable ubiquitous deployment of encrypted higher layer protocols by providing exposure of basic TCP-like semantics (e.g. SYN, FIN, RST flags) to devices on path (e.g. NATs and firewalls).
  • allow applications and transport protocols to explicitly provide limited information with integrity protection to devices on path
  • allow devices on path to provide unencrypted feedback and information about the path directly to sending endpoints, under sending endpoint control
  • allow devices on path to provide unencrypted information about the path to receiving endpoints, with encrypted feedback to the sending endpoint, under sending endpoint control

This approach explicitly gives the control of information exposure back the application and/or transport layer protocol on the end host. It is the goal of PLUS to minimize the information exposed, to make information exposure transparent, and to limit the level of detail to that useful for network treatment, while encrypting everything else. Endpoint verification of signaling integrity, careful design of minimal data structures, and restrictive policies for registration of signals can help to meet this goal. This is important to avoid future implicit treatment and resulting ossification, as well as to minimize the privacy risks presented by explicit cooperation.

Given that the primary goal of PLUS is to enable the deployment of transport protocols with encrypted headers, we assume that the higher-layer protocol can provide an encryption context that can be used by PLUS to provide authentication, integrity, and encryption where needed. The primary threat model to defend against will be modification or deletion of exposed information by middleboxes and other devices on path, by allowing a remote endpoint to detect modifications.

The working group will start with an initial set of use cases (see draft- kuehlewind-spud-use-cases) and requirements (see draft-trammell-spud-req), derived from experience with the Substrate Protocol for User Datagrams (SPUD) prototype. These documents are the source of the broad goals of the PLUS effort described in this charter. Detail changes to the requirements are in scope for the working group.

The working group's main output will be an experimental protocol specification, together with an initial registry of types of information that can be exposed using PLUS, clearly aligned to use cases determined by the working group. This specification will consider potential attacks against the protocol, both arising from the encapsulation chosen as well as new attacks made possible by the protocol, and propose mitigations for these attacks. The working group will close if it is not able to come to consensus on a protocol design to meet its goals.

Discussion and reports of implementations and deployments of the PLUS specification, and discussion and reports of implementations and deployments of transport protocols running over PLUS, will be in-scope for the working group, to evaluate the progress of the experiment.

The working group will additionally aim to identify and work with other working groups that could address its goals within existing protocols, e.g. by specifying new protocol extensions, or as input for on- going standardization work. It will aim to work with working groups defining encryption protocols (e.g. DTLS) which could be used for encryption of transport protocols running over PLUS. It will aim to work with working groups defining transport protocols (e.g. QUIC) whose development efforts could act as sources of requirements for PLUS.

Out of scope for the working group are:

  • The design and specification of new transport protocols running over PLUS
  • Mechanisms for signaling among multiple devices on path between two endpoints
  • Mechanisms for key exchange or cryptographic context establishment between endpoints and devices on path

Initial milestones:

  • Chartering + 4 mo: WGLC on use cases and requirements for a PLUS protocol; this milestone may be fulfilled as an Informational document to be published as an RFC, or its content may be incorporated into the protocol specification document described by the following milestone
  • Chartering + 12 mo: Submit an Experimental protocol specification for the PLUS protocol to the IESG
  • Chartering + 18 mo: Submit initial contents of registry of signals to be exposed using PLUS to the IESG

IAB Sessions