RFC 6771

RFC 6771: Considerations for Having a Successful "Bar BOF" Side Meeting 🎀

Title block tea ☕

• RFC number: 6771 📄
• Authors: L. Eggert (NetApp) and G. Camarillo (Ericsson) 👩‍💻
• Category: Informational (not a standards-track spec, just vibes and advice) 🦋
• ISSN: 2070-1721
• Date: October 2012 🍂
• Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates ✨

---

Abstract 💖

okay so new work usually starts with a small group of people who are super into an idea. IETF meetings are the perfect place for them to hang out and brainstorm in informal get-togethers 🌸 These side meetings aren't on the official meeting agenda and have zero official status, so people half-jokingly call them "bar BOF" sessions. The joke is that some of them could eventually turn into a real proposal for an official IETF BOF ("birds of a feather" session) on a topic 🧚

Lately, a bunch of these "bar BOF" get-togethers have been run in ways that make them basically indistinguishable from official IETF BOFs or even IETF working group meetings 🙈

This doc is basically saying that this trend isn't helping. The whole point of these get-togethers is to efficiently talk through and develop ideas for new IETF work, and the formal vibe gets in the way 💅 It encourages organizers to think about much less formal settings, and to also consider other ways to develop their ideas. It also recommends that the community drop the term "bar BOF" and use something like "side meeting" instead, so it's super clear these things are unofficial 🫶

Status of This Memo 🍓

This document is not an Internet Standards Track specification. It's published for informational purposes 📚

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 🔍

For info on the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6771 ✨

Copyright Notice 🌈

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🧾

1. Introduction ✨

So, a typical IETF meeting is packed with sessions of all kinds 🎪 Besides the official IETF and IRTF sessions on the meeting agenda (like working and research group meetings, area meetings, or plenaries), tons of unofficial meetings happen too. These include meetings between people from the same organization or company, design team meetings, Internet-Draft editing sessions, interoperability testing, directorate lunches, and many more 🥪

Some of these unofficial get-togethers are set up by individual participants who share an interest in starting some kind of new IETF work. New IETF work often fits into an existing working group and doesn't need an official "birds of a feather" (BOF) session [RFC5434] to figure out community consensus. Still, people in the community have commonly used the phrase "bar BOF" when talking about these informal get-togethers held to discuss potential new work 🍸 [RFC4677] (which has been obsoleted by [RFC6722]) describes a "bar BOF" like this:

an unofficial get-together, usually in the late evening, during which a lot of work gets done over drinks. Bar BOFs spring up in many different places around an IETF meeting, such as restaurants, coffee shops, and (if we are so lucky) pools.

Recently, "bar BOFs" have become more and more indistinguishable from official IETF BOFs or even IETF working group meetings 😭 The signs of this trend are unofficial "bar BOFs" held in regular IETF meeting rooms with classroom-style seating, agendas packed with long slide presentations, microphone lines, and even formal consensus calls. And, honestly the most important part, these meetings have a distinct lack of drinks 🥲

This doc argues that this trend isn't helpful for the ultimate goal of many of these get-togethers, which is to brainstorm about a technical topic that might eventually lead to new IETF work 🧠 It encourages the organizers of these unofficial get-togethers to think about the benefits of holding them in much less formal settings 🫧

It also recommends that the community drop the term "bar BOF" 💅 The difference between a BOF, which is an official IETF activity, and a "bar BOF", which is an unofficial get-together, is lost on lots of IETF participants, especially newcomers. The similar names have even caused confusion, with some people believing that a "bar BOF" is a required step in the IETF process before you can apply for an official BOF. That's obviously false 🙃 For these reasons, the rest of this document uses the term "side meeting" instead, and recommends that the community do the same, so the unofficial nature of these get-togethers is clear 🎀

Before getting into more detailed advice on how to hold side meetings, it's important to remember that lots of participants are extremely busy during an IETF meeting 🏃‍♀️ Having a side meeting to discuss an idea in an informal face-to-face setting is appealing, but scheduling these is really hard and has to happen weeks, if not months, before the meeting itself 📅 Conference calls, email discussions, wikis, jabber group chats, and other ways of interacting are also effective at developing ideas, and they're way easier to schedule 🦋

2. How to Invite ✨

Okay bestie, here's the golden rule 💅: a side meeting where you're cooking up a proposal for new IETF work should only include the people who actually need to be there to make it happen, and no more 🫶. Smaller meetings are usually more successful than big ones, fr fr.

So it's often smart to keep the guest list tight 🎀. Blasting an announcement for a side meeting on a specific topic, like on an IETF mailing list, is usually not a great way to get the right people in the room 🙈.

Here's why. If the announcement happens to pull in a huge response, organizing a side meeting for that many people gets really hard, really fast 😭. Small groups fit comfortably around a table at a bar or a restaurant, or they can find a quiet corner in an IETF hallway and just talk. Bigger groups need dedicated meeting rooms, and those are limited during IETF meetings. They also need way more careful planning if anyone's going to get any work done 📋.

When you publicly announce a side meeting, the organizers often can't even tell how big the get-together will be 💀. So they end up overbooking for the "best case" of a huge turnout, even when that never happens. And even when a big crowd does show up, a lot of them are "tourists" 🧳. Tourists usually don't actively take part at all, or they show up to learn about a topic, which can derail a planned discussion of specific issues and turn it into a tutorial 📚. Tourists also mean finding a bigger room, which makes things more cumbersome for the active folks, like needing microphones in larger spaces 🎤. There are times to share new ideas with a wider community, but think carefully before you publicly announce a side meeting 🦋.

So publicly announcing a side meeting can totally help you gather interested people for a discussion, but it still makes sense to limit attendance 💖. For example, an announcement could say, "We have a table reserved at restaurant X for Y people. If you are interested in attending, please briefly explain how you will contribute to the discussion we are planning to have." If more than Y people respond, the organizers make a selection 👑.

Selecting or specifically inviting IESG or IAB members isn't necessary, and in many cases it may not even be advisable 🙅‍♀️. Some ideas need time to form before they turn into anything cohesive, and side meetings are a great place to develop new ideas 🌱. It's usually most useful to approach Area Directors (ADs) and IAB members for comments once an idea has solidified enough to give an "elevator pitch" 🛗. Also, if an AD or IAB member shows up to a side meeting, that is not necessarily a show of support 🙃. They might just be interested, or they might be concerned or troubled about some aspect of the potential work and how it relates to existing work 🤔. On the flip side, when an AD or IAB member skips a side meeting, that's usually not a sign of disinterest or disapproval. These people have busy schedules, especially during an IETF week 🗓️.

In the early stages of developing a proposal for new IETF work, the ability for interested and experienced participants to brainstorm is tremendously important ✨. Brainstorming runs on direct, interactive, high-bandwidth discussion 🔥. That's way easier to pull off in a smaller setting, where half-baked ideas can be picked apart and developed 🧠. In a larger group, that often just isn't possible. Even worse, a badly run large meeting can sometimes "poison the waters" for a proposed idea 😬. It can convince the broader community that the proposal is confused, not ready, or just uninteresting 💀.

Another reason to talk about new work proposals in smaller groups is scope creep 🌀. That's the tendency for an initially tightly scoped area of new work to balloon, because people argue that whatever the original topic was, it should be expanded to cover their particular item of interest 🎈. This is harder to control in larger groups. Keeping new work items narrow really matters, because eventual chartering decisions are often much harder for big items of new work than for small ones 📐.

It's important to understand that in the IETF, proposals for new work are judged on their technical merits, and on whether there's enough energy and interest in the community to finish the work in a timely manner 🏆. That happens in the relevant working group, if one exists, or else during an official BOF session 🎯. How many warm bodies fill a room during an unofficial side meeting has no influence on that decision 🚫. It's also not a good metric for reporting interest in a topic to the community or to employers 📉. Discussions about new work can be seriously controversial, and people will show up just to watch the fireworks 🎆, learn about a new topic 📖, or make sure the new work doesn't interfere with stuff they're already pursuing, without actually being interested in contributing to the proposal itself 🙄.

Some side meetings are organized to discuss a topic that's also being discussed in an existing working group, either before or after the working group itself meets 🔁. Some working groups call these side meetings "ad hoc sessions" 🧩. The fact that a chair or key participant of a working group organized a side meeting to talk about topics related to that working group doesn't make it any more official than any other side meeting 💅. An "ad hoc session" is not an official working group session, and no decisions relevant to a working group can be made there ❌. Working group consensus can only be established during official sessions or on the mailing list [RFC2418] 📬.

3. Where to Meet 📍

As the colloquial name "bar BOF" implies, side meetings like these have traditionally been held in bars or restaurants 🍸. Lately, though, there's been a distinct shift towards holding these get-togethers in regular IETF meeting rooms 🏢. One reason for this trend is the over-provisioning problem we talked about in Section 2, where an uncontrolled broadcast announcement forces organizers to book way more facilities than they need 📦.

A second reason is that some participants, like non-native English speakers or people with hearing difficulties, can find it hard to interact with or follow a discussion in noisy places like restaurants, and especially bars 🔊. Organizers of side meetings are encouraged to take this into account when picking a meeting place 🫧. Quiet restaurants are not hard to find, and lots of them offer private dining rooms at no extra charge for larger parties 🍽️.

A likely third reason side meetings are increasingly held in IETF rooms is that booking one currently requires approval from an Area Director 📝. The reason for this practice is simply to make sure IETF-paid rooms are used for meetings that are, in the widest sense, IETF-related 🧾. But here's the tea ☕: approving a room request for a side meeting has been known to get reported to the community or to employers as Area Director "support" for the topic of the meeting 😤. No such support is expressed or implied when Area Directors approve room requests! Many of them routinely say "yes" to every incoming request as long as there are meeting rooms available 🙌. (And there are typically lots of meeting rooms free outside of normal working group meeting slots 🗝️.)

Holding side meetings in IETF meeting rooms doesn't make them any more official or valid than get-togethers held in other places 🗺️. Participants have recently started listing the times and locations of some side meetings on a wiki page, but that doesn't make them part of the official IETF agenda or change their unofficial status 📌.

IETF meeting rooms clearly aren't the most supportive environment for side meetings that need brainstorming on a new technical proposal 🥲. One reason is that the classroom-style seating often found in IETF meeting rooms tends to spread people out in rows, all facing a front presenter. That's good for presentations but bad for discussion 🪑. Because IETF meeting rooms tend to be large and people naturally spread out, holding a meeting in one often requires microphone use. That's cumbersome, slows the discussion down, and leads to "question-answer" dialogs between two people, which is way less effective than a group discussion around a restaurant table 🍴.

Another reason is more pragmatic 🧐. Because organizers of unofficial get-togethers can only use IETF meeting rooms when they aren't otherwise in use, these side meetings often happen during breakfast, lunch, dinner, or later in the evening 🌙. That stretches out the time participants are stuck in the same rooms they've already been stuck in all day, and it keeps them from having a regular, at least somewhat relaxed meal 🥡.

There's anecdotal evidence that at least one Area Director couldn't set foot outside the IETF hotel for several days during IETF 77 🏨. (IETF 77 was held in Anaheim, CA, and the food options in and near the hotel were, let's say, of severely limited quality 🌮💀.) It's unlikely that participants in that kind of consequential mental and bodily state will make productive contributions to a side meeting. And in the case of Area Directors, they're going to be extremely unreceptive to new work proposals 🥴.

Food, drink, and a relaxed atmosphere for having a discussion are an essential part of a successful side meeting, because those meetings often need to happen at meal times 🍕. IETF meeting rooms offer neither 🫠.

4. How to Meet ✨

okay bestie, so side meetings that happen in IETF meeting rooms have been getting SO extra 💅 Like, a bunch of them copy the whole official working group vibe so well that an average attendee literally can't tell the difference 😭 We're talking detailed agendas, long presentations, organizers calling themselves "bar BOF chairs" 💀, faking blue sheets (see Section 4.5 of [RFC4677]), and even doing hums and other consensus calls (see Section 5.2 of [RFC4677]). Not me being shocked but also kinda shocked 🙈

Nobody's totally sure why this keeps happening 🤔 One theory is that holding a get-together in an IETF room and having the organizers act like chairs during regular sessions creates a kind of Pavlovian stimulus for the attendees 🧚 Another theory is that an IETF meeting room just doesn't really allow for many other kinds of discussion. And then there's the BOF situation: applying for an official BOF can feel too complex or troublesome (and honestly, probably rightfully so 😩), so some organizers just decide to mimic one instead. Or they applied, got turned down, and then decided to hold the exact same meeting as a side meeting anyway. Main character energy, but make it chaotic 🌀

Whatever the reason, it's pretty obvious that running a side meeting focused on making quick progress on a technical proposal, but doing it like a working group session, is not very productive 💜 Working group sessions follow certain procedures because they have bigger audiences, need to establish formal consensus, and so on. Side meetings don't need any of that stuff, so it's just extra weight 🫶

Mimicking working group meetings is also confusing for attendees. In at least one case, some side meeting participants thought they were at an actual working group meeting, and incorrect press announcements got generated 😭🎀 When side meetings happen at restaurants or somewhere else away from IETF meeting rooms, the chance for confusion is way lower 🌸

Since the reasons for organizing these get-togethers are super diverse, this section isn't making more specific suggestions. The one thing it does note is that meeting outside an IETF meeting room will probably shift the dynamics enough that better interactions and results become possible 🦋

5. When to Meet 🗓️

Side meetings are often scheduled right after IETF evening plenaries 🌙 Those plenaries sometimes end before the time on the meeting agenda, but they've also run way, way later in the past 💀 So it's useful to avoid scheduling side meetings after plenaries at a fixed time. Instead, it's recommended to schedule them relative to the end of the plenary, i.e., "X minutes after the end of the plenary" ⏰ That way, attendees don't have to sit around if a plenary finishes early, and they don't have to bounce out of a plenary if it runs late 🙌

Section 3 of [RFC5434] points out that it's essential to understand all the angles of a given problem that IETF work is proposed for ✨ So input from the IETF meeting crowd isn't the only thing that matters. Input from other communities (operator, research, regulatory, etc.) can be just as important, if not more 🧠 So organizers should think about holding side meetings at venues where that input is easier to collect, like operator fora (RIPE, NANOG, etc.), research conferences, or other events 🌈

6. Conclusions 🎀

Side meeting organizers are encouraged to bring back the original spirit behind them 💖 That means organizing them outside IETF meeting rooms, at venues with food and drink, for smaller groups, and in a way that doesn't needlessly copy how official IETF sessions are run 🍓

It can often be useful to talk about proposals for new IETF work face-to-face in a chill, informal setting 🫶 But conference calls, email discussions, wikis, and other ways of interacting are also effective at developing ideas, especially since scheduling is so hard when busy people are involved during an IETF meeting week 😩

Finally, remember that all side meetings during an IETF week are purely informal and have no official status whatsoever 🚫 No cap.

7. Security Considerations 🔐

A security AD pointed out that people have been known to forget their laptops after side meetings held in real bars 💀 So the organizers of side meetings should remind any attending security ADs (and possibly others) to take their belongings with them after the side meeting ends or the bar closes, whichever happens first. Do not leave your laptop behind, bestie 😭💻

8. Acknowledgments 🫶

The name and title of this document were picked to resemble those used by Thomas Narten for his guidelines document on holding a successful BOF [RFC5434], as a sign of appreciation for a document that has proven to be invaluable many times over 💜

Several folks gave feedback and input on this document, including Jari Arkko, Fred Baker, Scott Bradner, Ben Campbell, Jorge Contreras, Spencer Dawkins, Ralph Droms, Wesley Eddy, Frank Ellermann, Adrian Farrel, Stephen Farrell, David Harrington, Russ Housley, Cullen Jennings, John Klensin, Al Morton, Robert Sparks, and Dan Wing 🌟

Lars Eggert was partly funded by [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program 🇪🇺✨

9. Informative References 📚

[RFC2418]  Bradner, S., "IETF Working Group Guidelines and
           Procedures", BCP 25, RFC 2418, September 1998.

[RFC4677]  Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
           Guide to the Internet Engineering Task Force", RFC 4677,
           September 2006.

[RFC5434]  Narten, T., "Considerations for Having a Successful Birds-
           of-a-Feather (BOF) Session", RFC 5434, February 2009.

[RFC6722]  Hoffman, P., "Publishing the "Tao of the IETF" as a Web
           Page", RFC 6722, August 2012.

[TRILOGY]  "Trilogy Project", <http://www.trilogy-project.org/>.

Authors' Addresses 💌

Lars Eggert
NetApp
Sonnenallee 1
Kirchheim  85551
Germany

Phone: +49 151 12055791
EMail: lars@netapp.com
URI:   http://eggert.org/


Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com