* 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 =

Timeframe IETF 102 (Montréal)

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

Applications and Real-Time

NONE

General

NONE

Internet

NONE

Operations and Management

Name: DNS Resolver Identification and Use (DRIU)
Responsible AD: Warren Kumari
Proposed Bof Chair: Paul Hoffman
Number of people expected to come: 200
Length of session: 1.5 hours
Conflicts: DNSOP, DPRIVE, DOH, SAAG, SECDISPATCH
Mailing list: https://www.ietf.org/mailman/listinfo/driu
Description: The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties.

This BoF is not intended to form a Working Group. Instead, it is meant to bring together authors of various WG and individual drafts to prevent overlap and to garner interest in particular topics.

Because many people are thinking of writing documents covering various related topics, it would be good to have a mailing list and a BoF to help cross-pollinate the ideas.

Some of the topics that would be on-topic would be:

  • How to identify DNS-over-different-transport in protocols such as DHCP, and in user-accessible configuration
  • Security properties of the various flavors of transport-secured DNS
  • TLS authentication when the identifier is an IP address (which is most common for identifying DNS resolvers)
  • How resolvers can express their capabilities to clients who might care (such as "this resolver does DNSSEC validation" or "this resolver passes client subnet information to authoritative servers")
  • Identifying a resolver in the "dns:" URI scheme in RFC 4501. A related question is whether there should be a "dnss:" URI scheme whose semantics mean "Look up this name, but only use a secure DNS server", where "secure" would need to be defined.

There are likely additional related topics that the BoF and mailing list might delve into.

Routing

NONE

Security

NONE

Transport

NONE

IAB Sessions

NONE

HotRFC Lightning Talks

Title Speaker
*
*
*
*
*
*
*
*
*
*
*
*
*

Previous meeting BOFs

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)