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

Name: Internationalization Review Procedures (I18NRP) - conditionally approved for IETF 102

Many people seem to think that what has come to be called "internationalization" ("i18n") of the Internet is important, both for serving existing users for whom English may not be a comfortable language (or Latin script a comfortable writing system) and to making the Internet accessible to much larger populations ("the next billion"). Some of the issues are related to identifiers, with examples including IDNA, IRIs, PRECIS, and the recent work on non-ASCII identifiers in certificates. Others are more connected to actual protocol design, such as the SMTPUTF8 work in the EAI WG. Still others are related to content, language selection ins various applications, and so on.

The IETF has recognized those needs with a series of WGs (including those associated with the work above), workshops, etc. There have also been a number of IAB efforts. These efforts have produced protocol work, much of which is in wide use, and recommendations for IETF procedures, most of which have been ignored.

Internationalization-specific work is not the only problem. We've seen efforts develop on other topics for which specific i18n review of advice is needed. We have no systematic mechanism for being sure that happens and that resources can be found and are available; whether the WGs get good advice or reviews has been dependent on the dedication and connections of document authors and WG Chairs.

In recent years, the work has gotten stuck: there has been insufficient expertise and energy in combination to allow a proposal that would convince the IESG to generate a WG, handling and modifying standards track documents on topics in which there is high importance but a shortage of IETF depth (complicated by strong opinions from people with special interests and/or little in-depth knowledge on the topics) by individual submission has not seemed appropriate, and it has consequently been impossible to make progress.

In some superficially-similar situations, the IETF has decided to just let the topics stagnate until there is more of a perception of need, and hence energy, in the community. That does not seem to be working here. In particular, there are pressing problems and decisions that need to be made if the IETF is going to fulfill its responsibilities about these topics (if it isn't going to abandon them) and, because of concerns about reviews (and probably more), it seems impossible to process work that is necessarily standards track without a WG and impossible to create a WG given the absence of manifestations of broad interest and knowledge and the history, mentioned above, of WGs running out of steam.

The intent of this BOF is to have a discussion on what should be done procedurally. Even if the IETF wants to abandon this area of work to whomever might pick it up, that should probably be an explicit community decision, not something that happens by default. If the IETF does not want to do that --and mailing list coments argue strongly that we should not-- other possibilities appear to require discussion if only to offer advice to the IESG. For example, it has been suggested that a strong Directorate focused in i18n topics would be helpful, but those suggestions have been made before and the IESG has apparently not seen sufficient community support to move forward. Similarly, there has been guidance suggesting a specific "Considerations" sections of I-Ds and RFCs for more than twenty years, but that requirement has never been actively enforced; any change will clearly require community discussion and support. Any more radical change -- e.g., a different way to process these documents, a proposal for collaboration with one or more SDOs -- clearly needs some serious discussion and guidance from the community

The problems may be further complicated because several of the acknowledged experts and critically interested parties have little or no reliable support for attending IETF meetings so, if a group is to be judged by counting the number of people in the room for a discussion, it is easy to conclude that there is less interest than might actually exist. There have been a number of proposals to increase the support levels or provide in-depth training to newer participants, but those suggestions have not been productive either.

It is important that the topic of this BOF is to examine procedural and structural options for moving forward. Specific technical proposals or discussion will be treated as out of order. While this is listed for the ART area, primarily for historical reasons, the appropriate Area should be an IESG decision -- while much of the work on these topics has occurred in what is now ART, there has been recent work in the Security and Internet Areas and the trend for other Areas to be affected is probably increasing.

Status: not WG Forming -- Discussion of procedural alternatives
Responsible AD: IESG should make a decision
BoF proponents: John Klensin <john-ietf@jck.com>, Patrik Fältström <paf@frobbit.se> (others welcome to sign up)
BoF chairs: TBD
Number of people expected to attend: 50
Length of session (1, 1.5, 2, or 2.5 hours): 1 hour
Conflicts to avoid (whole Areas and/or WGs): DISPATCH, any other session with wide-ranging IETF procedural implications.

  • Agenda
    • Status review and problem summary
    • General discussion
    • (topics are likely to get more focused based on WG discussions before IETF 102)
  • Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.
    • Mailing List: ​Because this topic has wide implications for IETF work in several Areas and may require procedural changes, the IETF discussion list should probably be used and discussion has already started there.


Name: The label "RFC" (RFCplusplus) - approved for IETF 102
Status: Non-WG Forming
Responsible AD: Alissa Cooper
BoF proponents: Martin Thomson <martin.thomson@gmail.com>, Melinda Shore <melinda.shore@nomountain.net>
BoF chairs: Gonzalo Camarillo, Sean Turner
Number of people expected to attend: 150
Length of session: 1.5 hours
Conflicts to avoid: IASA2.0, IRTFOPEN

More than 20 years ago, RFC 1796 laid out a problem: mingling IETF standards with other documents labeled RFCs has resulted in the "regrettably well spread misconception" that all RFCs are standards. It laid out two proposals for responding to that confusion: use of alternate identifiers for the standards (STD numbers) and using the web's hypertext facilities to publicize whether a specific RFC was a standard or not.

The BoF proponents believe that these methods did not achieve the stated goals, and that the "well spread misconception" remains, despite significant updates to the RFC model and the formalization of multiple streams that has since occurred. The proponents note that the formalization of the streams has not hindered the relevant groups from maintaining a dialog across the streams. The other streams are cited by the IETF as appropriate, and the IAB, ISE, and IRTF streams cite the IETF stream frequently.

Given that the streams maintain dialog with each other despite their independent management, we wish to propose an experiment to test whether increasing their distinguishability to those outside the community would hinder the ongoing dialog among the technical communities using each stream. This BoF request is to discuss a possible experiment.

During this experiment, each of the ISE, IETF, IRTF, and IAB stream managers would request the creation of a new series stream identifier, different from "RFC", for some or all of their streams. This would allow "RFC" to be reserved for standards-related documents, in effect ratifying the "regrettably well spread misconception." For the IAB, IRTF, and ISE, the new series' stream identifiers would be used for all products of the stream. The IESG would use the BoF to gather community views about whether and how to use new stream identifier(s) for non-standards-related documents in the IETF stream.

At the end of the experiment, the community would discuss whether these stream identifiers were sufficiently useful in technical references and discussions to maintain the technical dialog among the relevant technical communities. If they are not, RFC numbers would be allocated for each document published under the experiment, and the new stream identifiers would each become an overlay to the RFC series, as the BCP and STD identifiers currently are. If they are sufficiently useful, those streams would continue to use the new identifiers as described above.

The proponents believe that this experiment would take approximately 3 years to implement and assess. If the assessment cannot be made at the 3 year mark, an additional span of time to continue dual assignment can be requested.

The purpose of the BOF is to get a frank and open discussion of this proposal, which would clearly change existing RFC publication practice. Does the community believe that the experiment as proposed is worthwhile, or that a different experiment with related goals would be more acceptable?


Name: Secure End to End Privacy Enabled Mapping System (ATICK) - not approved for IETF 102
Status: WG Forming
Responsible AD: Terry Manderson, Suresh Krishnan
BoF proponents: Roland Schott (roland.schott@telekom.de), Michael Menth (menth@uni-tuebingen.de), Sunghoon Seo (sh.seo@kt.com), Tom Herbert (tom@herbertland.com), Dino Farinacci (farinacci@gmail.com) Liugi Iannone (ggx@gigix.net).

BoF chairs: TBA
Number of people expected to attend: 100
Length of session (1, 1.5, 2, or 2.5 hours): 1.5 hours
Conflicts to avoid (whole Areas and/or WGs): Int area WGs
Links to the mailing list: Mailing List: https://www.ietf.org/mailman/listinfo/5gangip

  • Description:

The goal of this group is to develop framework including requirements, solution space analysis for a new kind of mapping system to be used by identifier locator separation systems (Id-Loc) so that Id-Loc systems are end to end privacy enabled and secure.

As well as privacy of identifier and locator access from the mapping system, privacy enhancing protocols/ mechanisms in the data plane when an end node or UE communicates with other nodes are in scope.

Security issues arising from different parts of a mapping system such as caches are in scope. Dealing with distributed denial of service attacks on the caches or similar is in scope.

The activity will leverage a solution space and scalability analysis on the latest mapping systems publish/subscribe technologies, sharding and the like.

The BoF gathers implementers, users and experts from academia, institutes, IT and automotive industry, and public authorities. Strong relationships with SDOs: 3GPP SA2 & SA3, BBF 5G Project Stream, ITU-T 5G Group, IEEE (OmniRAN).

The need for this work stems from:

  • This work is IP layer based and the need is justified below using the selected application area in current 4G and future 5G mobile networks standardized by 3GPP. Familiarity with 5G architecture referenced below in assumed but not required to understand the proposed work.
  • Heavy use of tunneling with fixed anchors: Current 4G and the upcoming converged communication network of 5G core network (5GC) make use of tunneling with anchor points to handle mobility, policy and quality of service. The use of IP addresses induces the topology and enables easy location tracking. Elimination or reduction of anchor points, as well as disassociating topology from IP addresses to facilitate efficient mobility and user privacy using Identifier Locator separation systems like ILA, LISP is needed. Increasing packet overhead due to encapsulation that may cause fragmentation and all related issues typical disadvantages of (especially static end-to-end) tunneling comprise inflexibility to properly react to dynamic changes of end points and potential on-path anchors which is required to support mobility. Added complexity in case of multicast traffic, i.e. tunneling being unicast and increased signaling for tunnel management are further drawbacks.
    • In the proposed 5G operation, GTP is used to tunnel UE packets from the base station, also known as gNB to User Plane Function (UPF) in N3 interface establishes a fixed anchor for UE traffic and UPF further GTP tunnels to another UPF in N9 interface which is connected to an external data network (DN). Access and Session Management control plane functions (AMF, SMF) push such configuration setup to the data plane functions. With such a rigid setup user mobility as well as UE receiving traffic on multiple interfaces can not be handled efficiently. UE to another UE traffic has to go to the fixed anchor since gNBs are not mobility anchors. Also due to the induced delays, delay sensitive applications such as Ultra Reliable Low Latency (URLL) applications can not be supported.
    • Currently defined Id-Loc systems provide a good alternative data plane solution to the GTP based approach. They can be initially used in at least some 5G slices such as URLL slice once a secure end to end privacy enabled mapping system is developed.
  • Addressing scheme in use currently reveal the topology of the internet and thus location privacy of the end nodes can not be established. Move away from this heavy use of locators is needed in favor of identifier locator separation systems.
  • Gaps in mapping solutions developed so far in Id-Loc systems reveal the fact that secure end to end privacy enabled mapping system approach is needed across the board.
  • Agenda
    • Problem Statement
    • GTP tunneling problem explained
    • Gaps
    • Discussion - 45min

  • Proposed Charter Text and Milestones

Identifier Locator Separation systems are maturing and the time is approaching for them to be applicable to be used in larger applications. This however requires some new work on establishing secure and end to end privacy enabled mapping systems to map the identifiers to the most recent locators.

As well as privacy of identifier and locator access in control plane from the mapping system, privacy enhancing protocols/ mechanisms in the data plane when an end node or UE communicates with other nodes are in scope.

Security issues arising from different parts of a mapping system such as caches are in scope. Dealing with distributed denial of service attacks on the caches or similar is in scope.

  • Milestones

Framework document will be developed. 

  • Adopt the framework draft as WG draft (December 2018) 
  • WGLC on the framework document (February 2019) 
  • Framework document sent to IESG (April 2019) 
  • Recharter or close the WG 

  Hackathon activity will be encouraged and led.  An open source mapping system such as Redis db can be used as the basis.  A prototype solution using this system will be developed 

  • Please list any protocols or practices that already exist in this space.

see the Gaps document

  • If any modifications to existing protocols or practices are required, please list them.

Yes, Id-Loc protocol control plane possible modifications

  • If any entirely new protocols or practices are required, please list them.
  • (Optional) Please list any open source projects implementing this work.

We will strive for identifying the best open source project to base our prototyping activity

Operations and Management

Name: DNS Resolver Identification and Use (DRIU) - approved for IETF 102
Responsible AD: Warren Kumari
Proposed Bof Chair: Paul Hoffman
Number of people expected to come: 100
Length of session: 1.5 hours
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.

Name: Autonomous Asynchronous Management Policy and Protocols (AMP) - not approved for IETF 102

Devices that are separated from their upstream management by delayed or disrupted links are notoriously difficult to manage. Some of the problems involved could be overcome by imbuing the end device with more autonomy.

The DTN working group has a number of individual drafts and working group documents describing the complexities of managing devices over links that may be heavily delayed or disrupted, as well as proposed protocols to address these difficulties.

Please note: Although the work is currently beginning in the DTN working group, we believe the subject has applicability beyond Delay Tolerant Networking.

The purpose of this BoF is to attract the interest of others in the IETF, particularly those involved in the Ops Area to discuss:

  • The use-cases being addressed, and the proposed approaches and protocols being developed.
  • How well the current approach fits with the general trends in device management in the IETF.
  • Are there other uses-cases for which the current approach provides a solution?
  • Are there alternative approaches that would be preferable to the current approach.

Status: Not WG Forming
Responsible AD: Warren Kumari?
BoF proponents: Rick Taylor <rick@tropicalstormsoftware.com>, Ed Birrane <Edward.Birrane@jhuapl.edu>
BoF chairs: TBD
Number of people expected to attend: 25 (We hope)
Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
Conflicts to avoid (whole Areas and/or WGs): DTN, MANET, NETCONF, NETMOD, ANIMA




Name: Application Transport LAyer Security (ATLAS) - not approved for IETF 102
Responsible AD: Eric Rescorla
Proposed Bof Chair: Richard Barnes
Number of people expected to come: 100
Length of session: 1.5 hours
Conflicts: Security groups, IoT groups
Mailing list: https://www.ietf.org/mailman/listinfo/atlas
Description: The basic idea is to re-use the TLS/DTLS handshaking protocols at the application layer for establishing keying material to protect application data end-to-end (whereby the end points are typically different than the endpoints of a regular TLS/DTLS protected communication interaction).

A charter proposal is available and has been discussed on the list in context of a side meeting at the London IETF meeting: https://www.ietf.org/mail-archive/web/atlas/current/msg00022.html An updated charter text will be made available shortly.

There are various drafts available, which are outlined in the charter text. For example, https://tools.ietf.org/html/draft-bhattacharyya-dice-less-on-coap-01 and https://tools.ietf.org/html/draft-friel-tls-atls-00



IAB Sessions


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)