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

Timeframe IETF 104 (Prague)

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

Approved for IETF 104

Applications and Real-Time

Name: Brand Indicators for Message Identification (BIMI)

Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand-specific Indicators next to properly authenticated messages.

There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the indicator. MUAs and mail-receiving organizations are free to define their own policies for indicator display that make use or not of BIMI assertions as they see fit.

While the impetus for BIMI is phishing protection and standardizing an opaque and closed process, these specifications don’t supply new authentication protocols or protections but rather create an incentive to drive adoption of email authentication protocols such as SPF, DKIM, and DMARC. This BoF would address this directly, as well as discuss other concerns around the proposal that should happen in public.

Status: Non WG Forming
Responsible AD: Alexey Melnikov, Barry Leiba
BoF proponents: Seth Blank <seth@valimail.coml>, Wei Chuang <weihaw@google.com>, Alex Brotman <Alexander_Brotman@comcast.com>
BoF chairs: Murray Kucherawy
Number of people expected to attend: 50
Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
Conflicts to avoid (whole Areas and/or WGs): DMARC, LAMPS, Dispatch, Ledger, JMAP, EXTRA, Security Area BOfs
Special Time Request: Tuesday, Wednesday, or Thursday


No approved BOFs for IETF 104


Name: Predictable and Available Wireless (PAW)

Description: This is a follow-up to a successful bar-BoF in Bangkok at IETF 103, and activity on the PAW ML since. We will explore a WG-forming BoF in Montreal . The group would extend the work done at DetNet to improve routing and forwarding over the radio medium, and implement the concepts that are described at a high level in the 6tisch architecture; the group would also follow and complement for the IETF part the activity at IEEE Std. 802 on wireless TSN .

Status: Non WG Forming
Responsible AD: Suresh Krishnan (Int Area}
BoF proponents: Pascal Thubert, Corinna Schmitt
BoF chairs: TBD
Number of people expected to attend: 80
Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
Conflicts to avoid (whole Areas and/or WGs): 6tisch LPWAN 6lo roll rift detnet

Operations and Management

KSK Futures

Name: KSK Futures

Description: The key signing key (KSK) for the DNS root was changed for the first time on 11 October 2018. During the lead-up to the change, members of the DNS operations and security communities started discussing how the KSK should change in the future. Some of the topics of this discussion have included how often to change the KSK, requirements before making the next change, adding additional standby KSKs to the root zone, changing the signing algorithm, and so on.

There were two informal meetings about these topics at IETF 103 in Bangkok. The discussions among the participants of those meetings showed clear interest from many members of the IETF community to have more discussions.

There will be discussions of possible KSK futures at various meetings during the first half of 2019 with the intention of proposing consensus plans by the end of 2019. This BoF (should it happen) would be one of those meetings. There is also a mailing list (see below) for the discussion.
Status: not WG Forming
Responsible AD: Warren Kumari
BoF proponents: Paul Hoffman <paul.hoffman@icann.org>
BoF chairs: Paul Hoffman, possibly plus others
Number of people expected to attend: 150
Length of Session: 1.5 hours
Conflicts to avoid (whole Areas and/or WGs): DNSOP, DPRIVE, LAMPS, SAAG, WUGH, GIT
Intro and overview of the DNS root KSK (10 minutes)
Tentative groupings of proposed topics (5 minutes)
Open mic (remainder of the time)
Closing (2 minutes)
Mailing list: https://mm.icann.org/mailman/listinfo/ksk-rollover

Name: Technology Deep Dive - Modern Router Architecture (WGTLGO)

Description: This is being organized with the Edu Team. This will focus on how a modern router is architected, and how it differs from the mental model / traditional view of how a router works. Over time, as interface speeds have increased, and networking has become more complex, router architecture has had to evolve to keep up - a modern "core" router is no longer just a big fast computer -- this has important implications for protocol design, including things like load balancing, fragmentation, extension headers, exception processing, etc.
This will be somewhat similar to the MODERN ROUTER ARCHITECTURE FOR PROTOCOL DESIGNERS IEPG session.
This BoF is an experiment - depending on how the idea of Technology Deep Dives goes, we may do more on other topics.

Special time request: Wednesday.

Status: Non WG Forming
Responsible AD: Warren "Ace" Kumari (Ops Area}
BoF proponents: Edu Team, Ace Kumari, Spencer Dawkins
BoF chairs: Spencer, Edu Team
Number of people expected to attend: 150 ?
Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
Conflicts to avoid (whole Areas and/or WGs): Ops Area, TSV Area / TSVWG, PANRG, ICCRG, IRTF, <everything!>


  • Name: BCAUSE (BNG Control-plane And User-plane SEparation)
  • Description:

Current Broadband Network Gateways (BNGs) that terminate residential broadband subscribers at the edge of service provider networks run as an integrated system where both the subscriber management control plane and traffic forwarding user plane are combined in a single system. In a large network, where the subscriber density is high, it is better to distribute and locate BNG systems closer to the subscribers, especially when the content caches are distributed to reduce backhaul costs and latency. In this scenario, as the BNG footprint grows, the subscriber management control points also proliferate, increasing operational complexity. This trend motivates the broadband network access industry to adopt new architectures that take advantage of the increasing ability to disaggregate and virtualize appropriate network access functions. Additional benefits can be realized by separating subscriber management control plane (CP) and traffic forwarding user plane (UP) for BNGs (referred to as Control and User Plane Separation (CUPS)). That simplifies operations, provides independent location, and scaling for CP and UP functions. A single CP function, running as a centralized VNF, can control and manage multiple UP instances, which may be distributed and separated from the CP via a multi-hop L2 or L3 network. CUPS requires protocols for communication between CP and UP instances: from the CP to the UP to create and manage subscriber state instances and from the UP to the CP to handle relevant solicited or unsolicited events.

  • Status: WG Forming
  • Responsible AD: Martin Vigoureux
  • BoF proponents: name <email>, name <email> (1-3 people - who are requesting and coordinating discussion for proposal)
  • BoF chairs: TBD
  • Number of people expected to attend: 50
  • Length of session : 1 hour
  • Conflicts to avoid (whole Areas and/or WGs): rtgwg
  • Agenda
    • This is a place holder in case face to face discussions a required to resolve pending issues



Name: Collaborative Automated Course of Action Operations (CACAO) for Cyber Security

Description: The goal of CACAO is to enable collaborative courses of actions / playbooks to be authored, enhanced, shared, and processed in machine relevant time so that a SOC can decrease the amount of time needed to prevent, mitigate, or remediate an attack.

Courses of action or playbooks are commonly used today throughout the industry and are typically written as formal documents that spell out step by step what an organization (typically a SOC) must or should do in the event of a certain type of cyber attack. Meaning, an attack against one of the following types of resources; network, server, endpoint, device, scada system, data, information, user, etc. While some playbooks may include tasks for physical security, physical security is out-of-scope for this work.

Over the past 18 months various industry groups and vendors, as identified in draft-jordan-cacao-introduction-00 [1], have been working on solutions to automated the collaborative exchange of COAs. As a starting point, several individuals supporting this effort published an individual introduction draft [1] back on 2018-09-12.

On October 24, 2018 we hosted a WebEx? CACAO overview session [2][3] where we had 30 individuals attend. Then at IETF 103 in Bangkok we hosted a successful side meeting [4] where 16 individuals attended, where more than half were new to the work. Everyone in the room at the side meeting expressed interest in seeing this work move forward.

This solution will contain at a minimum; a standard JSON based data model, a defined set of functional capabilities and associated interfaces, and a mandatory to implement protocol.

This work will not be creating a new transport protocol, but rather will specify and standardize a configuration for using existing transport protocols to distribute courses of action in both direct delivery and publish-subscribe methods. The FreeTAXII [5] open source project that is designed to share STIX content will also support the sharing of CACAO data over the transport protocols that are defined by this working group.

A BoF is formally requested for IETF 104 with the goal to bring together additional individuals and organizations that are interested in working on CACAO and finalize the charter for this working group.

Status: WG Forming
Responsible AD: Ben Kaduk, Eric Rescorla (Security ADs)
BoF proponents: Bret Jordan <bret_jordan@symantec.com>, Allan Thomson <athomson@lookingglasscyber.com>, Joyti Verma <


BoF chairs: Christopher Inacio, Joseph Salowey
Number of people expected to attend: 50
Length of session (1, 1.5, 2, or 2.5 hours): 1.5 to 2 hours
Conflicts to avoid (whole Areas and/or WGs): Security Area, SMART


Name: Remote Attestation (RATS)
Description: Relying parties require evidence about the trustworthiness of remote system components [RFC4949] they interact with. Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components by creating and processing attestation evidence. A relying party can then decide whether to consider a remote system component trustworthy or not.

Status: placeholder for pending WG chartering
Responsible AD: Benjamin Kaduk
BoF Chairs: Nancy Cam-Winget, [replacement for Roman Danyliw TBD]
Number of people expected to attend: 100
Length of Session: 2 hours
Conflicts to avoid: Security Area
Links: charter draft at https://mailarchive.ietf.org/arch/msg/rats/MQLZIkIK23ZlSBMB5wJjo71bOr0 ; mailing list at https://www.ietf.org/mailman/listinfo/rats ; relevant drafts https://datatracker.ietf.org/doc/draft-mandyam-eat/ and https://datatracker.ietf.org/doc/draft-birkholz-rats-architecture/



IAB Sessions

Name: Stopping Malware and Researching Threats (SMART)

Description: SMART (Stopping Malware and Researching Threats) is a proposed Research Group in the IRTF (Internet Research Task Force) that aims to research methods to efficiently and effectively detect, mitigate, prevent or eliminate threats; to guide protocol development in the IETF; to become the authority on attack detection and prevention in the IRTF/IETF.

Status: RG Forming
IRTF Chair: Allison Mankin
BoF proponents: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Kirsty P <kirsty.p@ncsc.gov.uk>
BoF chairs: Kathleen Moriarty, Kirsty P
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): Security


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

HotRFC Lightning Talks


Not Approved for IETF 104


DOGFOOD (proposal)

Name: Do Online Gatherings Fit Our Organizational Demands?
At present, the IETF meets in person three times every year. There are quite a few problems with this:

  1. It privileges participants from wealthy countries
  2. It creates an imbalance in terms of the influence that large companies have
  3. It reduces diversity
  4. It selects in favor of professional standards writers
  5. It has a truly substantial carbon impact
  6. It appears to be limiting attendance for younger participants, with the result that we are having trouble filling leadership roles and the long-term survival of the organization is at risk.
  7. It sets a bad example: other SDOs and similar organizations see the IETF meeting in person three times a year and assume that if the IETF can't meet effectively online,

The goal of this meeting will be to explore the issues that we would confront if we moved to a more online strategy with fewer in-person meetings, and to begin to come up with a plan for an experiment: an online full meeting of the IETF in one of the upcoming slots for which we do not currently have a venue.

This may seem like a half-baked proposal, but the reality is that we talk about this a lot: the IESG discusses it informally, it comes up in Plenary sessions, and it gets a lot of discussion at breakfast. But we never actually do anything. The reason for proposing a BoF is to get those people who are interested in this problem into a room and actually seriously talk about it.

Status: (not) WG Forming
Responsible AD: Coop
BoF proponents: Ted Lemon <mellon@fugue.com>
BoF chairs: TBD
Number of people expected to attend: 200?
Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
Conflicts to avoid (whole Areas and/or WGs): Homenet, DNSSD, DNSOP, TLS, TBD


  • Explore the financial impact of meeting online for the IETF:
    • Costs of hosting
    • If/how to charge for attendance
  • Enumerate our goals: what does success look like?
  • What technologies do we know of that could be used to make this work?
  • What incremental changes might we make to in-person IETF meetings to live-test this technology?
  • When should we do it?
  • How should we organize it? (E.g., form a WG? Form a committee?)

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

  • At present there is no mailing list or charter. If there is interest in doing this BoF, we should probably start a mailing list. The agenda is somewhat half-baked, and one thing that could and probably should be discussed on the mailing list would be an improved agenda.

Operations and Management

Name: Next Steps and Variations on BRSKI (NSVB)

Description: The ANIMA WG "Bootstrapping Remote Secure Key Infrastructure" (BRSKI) protocol, while not yet at the IESG, has gotten a fair bit of traction in a variety of industry and standards groups. Some see BRSKI as magical security dust and would like to say "Just Use BRSKI". (cf: rfc5406). Other groups want to use BRSKI, but substitute what they see as a small change to the protocol. The purpose of this non-WG forming BOF is to gather the various extension proposals together and understand how much interest there is in each. This work may lead to (re-)chartering existing WGs to write extensions for BRSKI, to creation of a set of clear guidelines as to what belongs in the ANIMA WG proper, or towards a process to create a new WG.

Status: Non-WG Forming BoF
Responsible AD: Ignas
BoF proponents: Michael Richardson <mcr+ietf@sandelman.ca>
BoF chairs: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, Eliot Lear <lear@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Number of people expected to attend: 50
Length of Session: 2 hours
Conflicts to avoid (whole Areas and/or WGs): ANIMA, EMU, COAP, SAAG, OPSAREA, BoFs? in SEC area


Name: Canonical JSON

Description: The goal of this group is to define and standardize a scheme for serializing JSON (RFC 8259) data into a canonical format, aka “Hashable” JSON. This has applications for cryptographic solutions like signing and hashing, but could potentially be used for other purposes like comparing JSON data.

In order to not start from zero, the current proposal relies on reusing the serialization of basic JSON types (literals, strings and numbers) as defined by EcmaScript version 6 and forward making the scheme compatible with Internet browsers and Node.js. For verifying cross-platform interoperability, compatible implementations have also been developed for Java, Python, Go and C#. The canonicalization scheme also depends on a key (property name) sorting algorithm which has been successfully implemented in the mentioned platforms.

Unlike XML signatures, which require complex (and thus error-prone) canonicalization, this proposal's reliance on EcmaScript JSON serializing rules for basic types makes it straightforward offering canonicalization functionality for JSON. Also in contrast to XML canonicalization, the proposed JSON counterpart do not require specific JSON parsers or changes to existing JSON parsers since it effectively only deals with serialization. To maintain this level of interoperability the current proposal limits JSON data to the I-JSON (RFC 7493) subset.

The need for this work stems from:

  • The primary target for the canonicalization scheme is enabling JSON objects to be signed or hashed while maintaining their original format “on the wire”. This simplifies the debugging and documentation of information-rich systems like Open Banking [OPENBANKING] which currently use various proprietary approaches to achieve the same goal.
  • It has been shown that the widely used JSON Web Signature (JWS) container can be used together with the devised canonicalization scheme. This combination offers a “clear text” signature alternative to JWS’ base64url-encoded mode while not requiring any extensions to the JWS standard or modifications of associated support software.
  • The close tie with EcmaScript enables implicit support for JavaScript objects, which for example, can be used in Web pages.
  • The scheme MAY also serve as a building block for a possible standard for signed REST requests [SIGREST].

Status: WG Forming
Responsible AD: TBD (Security ADs)
BoF proponents: Samuel Erdtman <samuel@erdtman.se>, Bret Jordan <bret_jordan@symantec.com> and Anders Rundgren <anders.rundgren.net@gmail.com>
BoF chairs: TBD
Number of people expected to attend: 25
Length of session (1, 1.5, 2, or 2.5 hours): 1 hour
Conflicts to avoid (whole Areas and/or WGs): OAuth, ACE, SecEvent, TokenBind, COSE, DISPATCH, SECDISPATCH