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

Timeframe IETF 98 (Chicago)

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

Applications and Real-Time

JSON Message Access Protocol (JMAP) - Approved for IETF 98

  • Placeholder for a WG in formation
  • Responsible AD: Alexey Melnikov
  • Chairs: Bron Gondwana <brong@fastmail.fm> and TBD
  • Number of people expected to attend: 100
  • Length of session: 1.5 hours
  • Conflicts to avoid:
    First Priority: dispatch httpbis core uta cfrg
    Second Priority: cdni tls
    Third Priority:
  • Links for more info: https://datatracker.ietf.org/wg/jmap/charter/

Glass-to-Glass Internet Ecosystem (GGIE) - Not Approved for IETF 98


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. Users are frustrated by quality, buffering, and stuttering problems. Video providers and access networks are investing heavily to keep up with demand. Significant work has be done at the application layer producing more efficient codecs and innovative adaptive bitrate transports like MPEG-DASH. These access investments and application layer work have helped but they alone have not been enough.

This BoF will introduce the Glass to Glass Internet Ecosystem (GGIE) which focuses on network level innovations to compliment the efforts at the application layer and access networks. The proposed GGIE work includes enabling adaptive bitrate transports like MPEG-DASH to use IPv6 as their video segment addressing scheme which in turn permits use of advanced IPv6 network features such as Segment Routing. A GGIE goal is to enabling video and network routing and management to work more cooperatively and efficiently to transport video, and to do so in a backward compatible ways to permit exiting devices and players to take advantage of the improved network efficiencies.


  • Agenda bash, scribe, minute taker [10min]
  • Context setting [15min]
    • Highlights of the Internet Video Scaling Problem
    • Specific aims of the GGIE work
    • Relationship to other IETF activity
    • Relationship to work in other fora
  • Overview of existing GGIE work — Network level proposals, demo [50min]
    • IPv6 Prefix addressing of MPEG-DASH packaged video
    • Content identifier to content address mapping using MARS
  • GGIE prototype demo
  • Where from here? [45min]
    • Known open questions
    • Potential for IETF work — is there interest to pursue?
    • If applicable: Discussion of draft charter for WG

Status: WG Forming
Responsible AD: Ben Campbell
BoF proponents: Glenn Deen / Leslie Daigle
BoF chairs: TBD
Number of people expected to attend: TBD
Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
Conflicts to avoid (whole Areas and/or WGs): DISPATCH, NETVC, CODEC, CELLAR, RMCAT, and TBD
Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

Glass to Glass Internet Ecosystem (GGIE) -- Draft Charter

Due to its size and sensitivity to network conditions, the transport of video over the Internet has highlighted a significant scalability problem for the Internet. Addressing this scalability problem requires better integration between application transport and networking technologies and leveraging IPv6. The GGIE working group will define a set of fundamental building blocks bridging video application use of the network and core network services of addressing, routing, and naming. Through standardization, of such fundamentals, a common base platform for new interoperable innovation on video transport efficiency and scalability will be enabled.

The scalability problem is driven by both professional and user generated content, fortunately both types of content use the same transport technologies which permits the working group’s output to apply equally to them. Likewise, in addition to the use the network to transport video for viewing, the network is extensively used in video creation workflows of capture and editing, and distribution workflows of encoding, packaging, and distribution to edge caches for playback. The working group will address both viewing and creation/distribution workflows.

To that end, the GGIE working group will define missing pieces of Internet technology standards, as well as provide pointers to use of existing standards.

Specifically, the GGIE working group will:

  • complete an overview document outlining the GGIE problem statement and general solution approach
  • develop a set of use cases representative of GGIE problem scope
  • develop a standardized URI for referring to specific media objects within a domain
  • develop a standardized means for mapping IPv6 addresses to video data
  • develop a media address resolution service protocol (MARS) to map URIs and addresses for video
  • provide a mechanism for discovering media address resolution services
  • document integration methods with lower level fundamental network services (eg. routing)
  • develop media encoding network (MEN) definitions for video packaging such as MPEG-DASH
  • illustrate how these technologies address the use cases already developed for GGIE

Out of scope are: video technologies including codecs, digital rights management, and DRM enforcement technologies.


WGs Using GitHub (wugh) - Approved for IETF 98

  • Description: GitHub is being used by more IETF Working Groups for proposing and tracking changes to WG Internet-Drafts. Using GitHub for normal WG processes requires some training, and edge cases in its usage abound. There are also questions of how to capture information that is created in GitHub into WG mailing lists so that all participants can see it and it is properly archived. This BoF will also be used for creating IETF-wide documentation on how to use GitHub effectively in WG processes.
  • Agenda
    • TBD
  • Status: (not) WG Forming
  • Responsible AD: Jari Arkko / Alissa Cooper
  • BoF proponents: Paul Hoffman
  • BoF chairs: Paul Hoffman
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 1 hours
  • Conflicts to avoid (whole Areas and/or WGs): dnsop, tls, httpbis, core, trans, quic, rtcweb, webpush, mtgvenue, lmap, dispatch, netvc, regext, stir, acme, hrpc, perc, saag, cbor
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

IASA 2.0 (iasa20) - Approved for IETF 98

  • Description: Last year, we talked about the need to review and possibly rework our administrative arrangements at the IETF, dubbed the IASA 2.0 project [1]. We are now arranging a series of virtual workshops related to this effort. At IETF 98, depending on the outcome of those workshops, we are considering arranging a session to talk about feedback already received (hopefully submitted as draft) and give an opportunity for further feedback.
  • Agenda
    • TBD
  • Status: (not) WG Forming
  • Responsible AD: Jari Arkko / Alissa Cooper
  • BoF proponents: Jari Arkko / Alissa Cooper
  • BoF chairs: Jon Peterson
  • Number of people expected to attend: 100
  • Length of session (1, 1.5, 2, or 2.5 hours): 1 hours
  • Conflicts to avoid (whole Areas and/or WGs): all area WGs, wugh, rtcweb, webpush, mtgvenue, lmap, netvc, regext, stir
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.


Operations and Management

Coordinated Address Space Management (CASM) - Approved for IETF 98

  • Description: Organizations use IP Address Space Management (IPAM) tools to manage their IP address space, often with proprietary database and interfaces. This work intends to evolve IPAM into standardized interfaces for coordinated management of IP addresses, including SDN/NFV networks and other forms of virtualization. Use cases include dynamic allocation and release of IP addresses and prefixes based on usage (reallocation in case of no more in use) and/or user intent (for specific services). The purpose of the BoF is to gather a common set of requirements from a larger set of operators and, if needed, possible protocol work milestones and scope.



A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP) - Approved for IETF 98

  • Name: A Protocol for Dynamic Trusted Execution Environment Enablement (TEEP)
  • Description:
    The goal of this group is to standardize protocol for dynamic trusted excution environment enablement.

The industry has been working on an application layer security protocol that allows to configure security credentials and software running on a Trusted Execution Environment (TEE) for sometime. Today, TEEs are, for example, found home routers, set-top boxes, smart phones, tablets, wearables, etc. Unfortunately, there have been mostly proprietary protocols used in this environment.

With this BOF we are making an attempt to standardize such a protocol. An strawman proposal of such a protocol has been published with https://tools.ietf.org/html/draft-pei-opentrustprotocol-03.

In the BOF we would like to do the following:

  • Explain TEEs, the problem we are trying to solve, and a bit of history
  • Walk through some use cases
  • Talk about the architecture
  • Point to one possible solution

In the end we would like to find out what the level of interest from the folks in the IETF to work on such a solution.

  • Agenda
    • Introduction of TEEs and the history - 20 min
    • TEEP use cases and problem statement - 20 min
    • TEEP architecture - 20 min
    • Possible solutions - 15 min
    • Tough Questions - 10 minutes
    • Wrap up - 5 minutes

Firmware Update Description (FUD) - Not Approved for IETF 98

  • Responsible AD: Kathleen Moriarty
  • Area: Security
  • Description: In 2016 the IAB organized the "Internet of Things Software Update Workshop (IoTSU)" workshop (see https://www.iab.org/activities/workshops/iotsu/) where various challenges and gaps of firmware update mechanisms for Internet of Things devices were discussed. This mailing list was created for discussions related to the standardization of firmware update mechanisms.
  • BoF Chairs: TBD
  • BoF proponents: Hannes Tschofenig <hannes.tschofenig@arm.com>
  • Number of people expected to attend: 50
  • Length of session: 1.5 hours
  • Conflicts to avoid:
    First Priority: core tls saag
    Second Priority:
    Third Priority:
  • Mailing List: https://www.ietf.org/mailman/listinfo/fud

Internet-level consistency (ILC) - Not Approved for IETF 98

  • Name: Internet-level Consensus (ILC)
  • Description

Several applications depend on Internet-wide consensus to secure an append-only log, provide tamper-resistant timestamps, and atomically commit transactions across mutually distrustful parties with no preexisting relationship. One such application is the Stellar payment network, in use by remittance companies to trade currencies and send payments across the Internet. Another is UCSD's SPAM (Secure PAckage Manager) project, which relies on a secure global log both to enable revocation of previously published vulnerable software packages and to guarantee that a particular software release has been publicly available for audit (somewhat like certificate transparency).

Future applications also stand to benefit from Internet-level consensus. For instance, the IETF trans working group is specifying data structures and operational mechanisms for providing secure logging and auditing of TLS server certificates, but lacks a mechanism for determining consensus among logs (or consensus about whether or not a resource should be logged). These functions are currently served by an experimental gossip protocol that can potentially be strengthened through global consensus. Another example is an ongoing effort at Stellar to enable domain name owners to assign human-readable names to end-user public keys without retaining the ability to lie about those public keys undetected.

All of these current and future applications stand to benefit from a stable specification of an Internet-level consensus mechanism. One approach--currently in use by Stellar and SPAM--is Federated Byzantine agreement (FBA), a consensus model whose structure mimics that of the Internet. Just as the Internet is held together by a series of pairwise peering and transit relationships with a high degree of transitive reachability, FBA protocols build global consensus out of pairwise trust relationships with a high degree of transitive overlap.

This BoF will gather protocol designers, implementers, and experts from academia and industry to explore both mechanisms for and applications of Internet-level consensus.

  • Agenda
    • Federated Byzantine agreement - 30 min David Mazieres
    • Internet payments with Stellar - 10 min Jed McCaleb?
    • Secure PAckage Manager - 20 min Deian Stefan
    • Decentralized naming and identity - 20 min Scott Fleckenstein
    • Discussion - 40 min
  • Status: non-WG Forming
  • Responsible ADs: Stephen Farrell Kathleen Moriarty
  • BoF proponents: Scott Fleckenstein (Stellar) David Mazieres (Stanford) Jed McCaleb? (Stellar) Deian Stefan (UCSD) Melinda Shore (Fastly)
  • BoF chairs: TBD
  • Number of people expected to attend: 50
  • Length of session: 2 hours
  • Conflicts to avoid: tcpinc, tls, trans
  • Links to mailing list, drafts, etc.: Mailing list: https://www.ietf.org/mailman/listinfo/ilc


IAB Sessions