* 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 https://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)
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

To allow evaluation of your proposal, please include the following items:

  • Please list any protocols or practices that already exist in this space.
  • If any modifications to existing protocols or practices are required, please list them.
  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

Template for BOF Entry - Please do not edit the BoF Example Page directly.

Timeframe IETF 105 (Montreal)

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

Approved for IETF 105

Applications and Real-Time

Applications Using DNS ADD

  • Description: As deployment of new DNS transports such as DNS over HTTPS (DoH) and DNS over TLS (DoT) progresses and more kinds of applications do their own DNS resolution, there is increasing interest in operational implications and identifying potential further work that would benefit DNS operations and architecture across a variety of network environments. This BOF will seek to identify related work items where further protocol standardization, best practices, or guidance could be usefully documented via the IETF consensus process.
  • Status: Non-WG forming
  • Responsible AD: Barry Leiba
  • BoF Proponents: Alister Winfield <Alister.Winfield@sky.uk> Andy Fidler <andrew.fidler@bt.com> Glenn Deen <Glenn.Deen@nbcuni.com> Jason Livingood <​Jason_Livingood@comcast.com> Jim Reid <jim@rfc1035.com> Nic Leymann <N.Leymann@telekom.de> Vitorrio Bertola <vittorio.bertola@open-xchange.com>
  • BoF Chairs: Lars Eggert, David Lawrence
  • Expected attendees: 150-200
  • Length of session: 1.5 hours
  • Conflicts to avoid: doh, dnsop, dprive, tls, httpbis
  • Agenda:
    1. Agenda bashing (5 mins)
    2. Current factual state, expected trends and concerns related to applications doing DNS resolution, and areas where we all have common interest in figuring stuff out. (20 mins)
    3. Potential areas for future protocol work, best practices, or guidance:
      1. Server discovery (15 mins)
      2. Expression of resolver policy (15 mins)
      3. Supporting split-horizon (15 mins)
    4. Discussion (15 mins)
      • Overlap with existing chartered work in DPRIVE, DOH, and DNSOP
      • Expressions of interest in working on specific work items

General

NETRQMTS

IETF Meeting Network Requirements NETRQMTS

  • Description: The IETF meeting network has a long history of pushing beyond the bounds of normal event networks. This BoF will gather community input on the network requirements for IETF meetings, including prioritization and the resource implications associated those requirements.
  • Status: NOT WG Forming
  • Responsible AD: Alissa Cooper
  • BoF proponents: Jason Livingood <Jason_Livingood@comcast.com>, Russ Housley <housley@vigilsec.com>, Karen O'Donoghue <odonoghue@isoc.org>
  • BoF chairs: Russ Housley <housley@vigilsec.com>, Karen O'Donoghue <odonoghue@isoc.org>
  • Number of people expected to attend: 125
  • Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): lamps suit quic perc saag sidrops sipbrandy mls tls ipwave stir acme secdispatch teep cfrg dprive ntp sacm opsawg dnsop grow mboned opsec v6ops anima 6man spring doh
  • Agenda
    • Talk about the existing requirements used by the NOC to build the IETF meeting network
    • Ask questions to confirm that the network requirements align with the needs of the attendees
    • Are there things we are providing that few people care about?
    • Are there things we are not providing that many people care about?
    • Are there things that would make experiments easier to conduct without impacting the ability of other people to do their work?
  • Background: All IETF participants want a perfect network that is always available with unlimited bandwidth in every possible location, even while others are conducting many experiments with buggy implementations, or even purposely broken implementations. The real requirements seem to include:
    • A highly-reliable network that allows people to get their work done.
    • It needs to be "real Internet", supporting both IPv4 and IPv6, and no filtering.
    • Provide a terminal room and/or lounge where people can colaborate and have excellent connectivity.
    • A network that works well throughout the meeting venue. It is nice to have access to the network in the main hotel and overflow hotels too, especially when the main hotel is not big enough to accomodate most of the IETF participants.
  • Priority:
    • Meeting rooms, common areas, plenary room, Secretariat office, NomCom? office, and so on.
    • Main hotel common areas and guest rooms.
    • Overflow hotel common areas and guest rooms.
  • A network that permits various kinds of experiments:
    • on alternative SSIDs;
    • provide places where some protocols can run and places where they cannot; and
    • measurements of the experiments can be done.
  • It is nice to have insight into attacks that take place on the meeting network, and then share this information with the whole community.
  • The requirements will be in draft-odonoghue-noc-requirements {to be posted before cut-off date}. That document will start with the last version of the requirements that were done (https://www.ietf.org/how/meetings/admin/meeting-network-requirements/).
  • The network requirements need to be balanced against the cost of the network. See "NOC Support" line in the budget at https://www.ietf.org/documents/246/IETF_2019_Budget_Public_2018-12-19.pdf.
  • Key questions about the meeting network that this BoF should explore:
  1. Can we simplify, evolve, or eliminate any network requirements?
  2. Should the network offer private IPv4 addresses?
  3. Are there any network functions that could be delivered virtually rather than physically on-site?
  4. Are there new requirements to support the hackathon or other new technical initiatives?
  5. How much redundency do we need?
  6. Can we prioritize key network requirements/functions into MUST and SHOULD and MAY?
  7. Do any NOC functions change based on the evolution of the network requirements?
  • Key questions about the hotel network that this BoF should explore:
  1. Do we need to manage connectivity for guest rooms?
  2. Does ietf-hotel really work better than the hotel-provided network?
  3. Could we live with NAT in the rooms?
  4. Could we live without IPv6 in the rooms?

Internet

NONE

Operations and Management

MOPS

Media OPerationS MOPS

  • Description:

The purpose of this BoF is to highlight the many existing video activities that are leveraging IETF protocol work, identify gaps in IETF work and/or areas of incompatibility with video technology development efforts being carried out elsewhere, and identify a core group of IETF participants working on video activities across the IETF’s technology areas.

Internet- and Internet-protocol-delivered video/media is popular, leading to significant technology development across industries not traditionally thought of as Internet technology developers or operators, as well as considerable quantities of traffic on local and transit networks. Continued development of Internet-using technologies should be properly coordinated in order to ensure that the existing technologies are well-utilized, and new ones are developed in sympathy with the Internet’s core protocols and design.

Some concrete areas for IETF interest could include:

  • Requirements for maximizing interoperability of video technologies
  • Operational practices for improving quality for any network conditions
  • Operational practices for making the best use of available infrastructure
  • Identifying other challenges in operations: isolating performance, reachability, and interoperation issues

Additionally, networking-related issues driven by media delivery (particularly the scaling issues and the real-time requirements, where those are a factor) need to be examined in detail, especially considering various proposed solutions in the IETF context, with access to and comments from networking experts and network operators.

As a concrete example, the open caching working group within the Streaming Video Alliance relied on CDNI RFCs and extended those RFCs to account for use case extension however, there are areas such as interoperability where the IETF publications do not provide detailed guidance or clarify issues associated with HTTP redirections and how they should be handled by HAS video players.

These “operational” issues would have a better chance of being examined in MOPS and specifications can be developed for operational issues, while any technical standards work would be directed to existing IETF WGs as appropriate.

This BoF and proposed WG have been discussed on the ggie@ietf.org mailing list, where there have been several expressions of support for the discussion and potential work. The archive is available here:

https://mailarchive.ietf.org/arch/browse/ggie/

  • Status: WG Forming
  • Responsible AD: Warren Kumari and Éric Vyncke
  • BoF proponents: Leslie Daigle <ldaigle@thinkingcat.com>, Glenn Deen <glenn.deen@nbcuni.com>
  • BoF chairs: Leslie Daigle and Glenn Deen
  • 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): QUIC, CDNI, MBONED, PIM, RTCWEB, MMUSIC, HTTPBIS, DOH
  • Agenda
    • 0/ Agenda bash
    • 1/ Scope of video on the Internet
      • Jake Holland — I-D forthcoming
    • 2/ Video using IETF technologies
      • Sanjay Mishra — OpenCaching? update (Streaming Video Alliance work)
      • <others pending>
    • 3/ Scoping discussion for possible onward IETF work
      • Discussion of IETF-specific work
      • Identification of concrete work items: E.g., A roadmap document about the various video-related and video-delivery-related standards
      • Solicit volunteers — for work items, onward discussion
      • [Review of draft WG charter; draft at https://yana.techark.org/vig-at-ietf/mops-draft-charter/]
    • 4/ AOB
    • 5/ Questions from RFC 5434 to the participants

Routing

NONE

Security

CACAO

  • Name: Collaborative Automated Course of Action Operations (CACAO) for Cyber Security
  • Description: To defend against threat actors and their tactics, techniques, and procedures, organizations need to manually identify, create, and document prevention, mitigation, and remediation steps. These steps when grouped together into a course of action (COA) / playbook are used to protect systems, networks, data, and users. The problem is, once these steps have been created there is no standardized and structured way to document them, verify they were correctly executed, or easily share them across organizational boundaries and technology stacks. The intent is to charter a working group that will create a standard that implements the playbook model for cybersecurity operations.
  • Status: WG Forming or placeholder for pending WG chartering
  • Responsible AD: Roman Danyliw and Ben Kaduk (Security ADs)
  • BoF proponents: Bret Jordan, Allan Thomson, Joyti Verma
  • BoF chairs: Chris Inacio and Joe Salowey
  • Number of people expected to attend: 100
  • Length of session): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): Security Area

LAKE

  • Name: Lightweight Authenticated Key Exchange (LAKE)
  • Description: Constrained environments using OSCORE in network environments such as NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key exchange (LAKE) that enables forward security. 'Lightweight' refers to resource consumption, measured by bytes on the wire, wall-clock time to complete, or power consumption; and the amount of new code required on end systems which already have an OSCORE stack.
  • Status: WG Forming
  • Responsible AD: Roman Danyliw and Ben Kaduk (Security ADs)
  • BoF proponents: Goeran Selander and Richard Barnes
  • BoF chairs: Stephen Farrell and Yoav Nir
  • Number of people expected to attend: 100
  • Length of session): 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): Security Area, 6TISCH, LPWAN, CORE, CBOR, LWIG, ROLL

Transport

LOOPS: Local Optimizations on Path Segments

  • Name: Local Optimizations on Path Segments (LOOPS)
  • Description:

Performance Enhancing Proxies (PEPs) have been used to improve performance over paths with links of varying quality, often peeking (and poking!) into the transport protocol. Encryption is putting an end to this practice. At the same time, more powerful network nodes are becoming available, making it more viable to trade processing power in network nodes against path quality. Transport protocols and their implementations are moving towards playing better with forwarding node functions such as ECN marking and AQM.

LOOPS (Local Optimizations on Path Segments) attempts to capture opportunities opened by these developments. Local optimizations are performed within segments of an end-to-end path, where tunnels are formed between overlay nodes (tunnel endpoints) aggregating many end-to-end flows. LOOPS provides local recovery of lost packets using retransmission and/or forward error correction (FEC), supported by local measurement functions and interacting with deployed and emerging end-to-end congestion control mechanisms without requiring their explicit cooperation.

Please see https://github.com/loops-wg/charter for a charter proposal and more details.

  • Status: Non-WG Forming
  • Responsible AD: Magnus Westerlund
  • BoF proponents: Carsten Bormann, Yizhou Li
  • BoF chairs: TBD (Proponents proposal:) Spencer Dawkins, Michael Welzl
  • 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): SPRING, NVO3, SOFTWIRES, PANRG, INTAREA, TSVWG, IPPM, MPTCP, QUIC, RMCAT, TAPS, TCPM, TRAM, ALTO, DTN, NFSV4

IAB Sessions

NONE

Not Approved for IETF 105

Security

PIDLOC

  • Name: Security and End to End Privacy in Identifier Locator Separation Systems (PIDLOC)
  • Description: Identifier Locator Separation, aka IDLOC systems are currently specified and partly experimentally deployed, as e.g. in terms of LISP, ILA, and ILNP. These systems aim to overcome the overload of IP address semantic in terms of both pointing at identification and location of IP sessions and end points and shall increase efficiency and performance tailoring of IP traffic handling. To correlate identifiers and locators they have to be accessible and may be carried in clear in packet headers or retrieved from a mapping system, depending on the specific technology used and the level of security/privacy enforced. In IDLOC systems, usage of identifiers readily available for public access raises privacy issues. While for public entities, it may be desirable to have their fully qualified domain names or host names available for public lookups by the clients, this, however, is not the case in general for all identifiers, e.g. for individuals roaming in a mobile network. Currently, privacy issues are hampering wide spread use of IDLOC systems.

In all of the above IDLOC systems, the need to preserve an identifier's privacy is essential. Otherwise, private information such as the location and content of the communication can be revealed. Privacy issues are exhibited in both control plane and data plane, so work is needed to develop techniques to enhance privacy in the control as well as the data plane.

  • Status: WG Forming
  • Responsible AD: Ben Kaduk, Roman Danyliw (Security ADs)
  • BoF proponents: Dirk von Hugo, Behcet Sarikaya
  • BoF proposal supporters: Shunsuke Homma, Luigi Iannone (plus another 1-3 people - who are requesting and coordinating discussion for proposal, TBD/TBC)
  • BoF chairs: TBD
  • Number of people expected to attend: 50
  • Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours or 2 hours
  • Conflicts to avoid (whole Areas and/or WGs): TBD (e.g. LISP WG, SEC Area, INT Area)
  • Agenda TBD, provisionally:
    • Intro & Agenda bashing, 5m
    • Use Cases & Problem Statement Draft presentation, 30m, Chairs (see below)
    • Requirements Draft presentation, 30m, Luigi (see below)
    • Solution Space presentation, 25m, TBD
    • Discussion, 30m, Chairs, ADs

Previous meeting BOFs

Timeframe IETF 104 (Prague)

Timeframe IETF 103 (Bangkok)

Timeframe IETF 102 (Montreal)

Timeframe IETF 101 (London)

Timeframe IETF 100 (Singapore)

Timeframe IETF 99 (Prague)

Timeframe IETF 98 (Chicago)

Timeframe IETF 97 (Seoul)

Timeframe IETF 96 (Berlin)

Timeframe IETF 95 (Buenos Aires)

Timeframe IETF 94 (Yokohama)

Timeframe IETF 93 (Prague)

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)