RFC 5434

Considerations for Having a Successful Birds-of-a-Feather (BOF) Session

📅 published February 2009, from ietf

Title Block: The Tea ☕

Okay bestie, this is RFC 5434, and it's called Considerations for Having a Successful Birds-of-a-Feather (BOF) Session ✨. It was written by T. Narten from IBM 💼 and it's Informational, which means it's sharing info with the Internet community and isn't a standard 🎀. The date is February 2009 📅. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🙈.

Status of This Memo 📜

This memo gives information to the Internet community. It is NOT a specification of any Internet standard, and it can be distributed without limits 🦋.

Copyright (c) 2009 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 they were in effect on the day it was published. Please read these carefully, because they explain your rights and restrictions for this document 📖🫶.

Abstract 🌸

So this doc is all about tactics and strategy for running a successful IETF Birds-of-a-Feather (BOF) session, especially one aimed at forming an IETF Working Group 🔥. It's based on the experiences of people who have been to tons of BOFs, the ones that worked out and the ones that totally flopped 💀.

Table of Contents 🗂️

   1. Introduction ....................................................2
   2. Recommended Steps ...............................................2
   3. The Importance of Understanding the Real Problem ................7
   4. The BOF Itself ..................................................8
   5. Post-BOF Follow-Up ..............................................9
   6. Pitfalls .......................................................10
   7. Miscellaneous ..................................................12
      7.1. Chairing ..................................................12
      7.2. On the Need for a BOF .....................................13
   8. Security Considerations ........................................13
   9. Acknowledgments ................................................13
   10. Informative Reference .........................................13

1. Introduction ✨

Okay so this doc gives you suggestions on how to host a successful BOF at an IETF meeting 🧚. The hope is that by writing down the methods that have actually worked, plus some pitfalls to dodge, BOF organizers can boost their odds of ending up with a positive outcome 💅.

There are lots of reasons to host a BOF, and not all of them are about making a Working Group (WG) 👀. Some BOFs are just a one-shot presentation on a particular issue, to inform the IETF Community 🍓. Another option is an open meeting to talk through open issues with a document that isn't tied to an active WG, but where you need to meet face-to-face to sort things out 🫶. Honestly though, a lot of the time the whole point is to form a WG 🔥. In those cases, the BOF's job is to show that the community agrees on the following:

  • there is a problem that needs solving, and the IETF is the right group to attempt solving it 🌈.
  • there is a critical mass of participants willing to work on the problem (e.g., write drafts, review drafts, etc.) 💖.
  • the scope of the problem is well defined and understood, that is, people generally understand what the WG will work on (and what it won't) and what its actual deliverables will be 🎀.
  • there is agreement that the specific deliverables (i.e., proposed documents) are the right set 👑.
  • it is believed that the WG has a reasonable probability of having success (i.e., in completing the deliverables in its charter in a timely fashion) ⭐.

If you want more details on WGs and BOFs, check out [RFC2418] 🦋.

okay bestie, this is the "ideal" sequence for hosting a BOF whose goal is forming a working group 💅 The big vibe: most of these steps are about planning for and jumping into significant public discussion 🗣️ and giving everyone enough time to iterate and get involved. So most of the BOF's actual work can happen on a public mailing list before the BOF, not during it 🫶

Timing is everything ⏰ The deadline for scheduling BOFs is approximately six weeks before an IETF meeting. If you work backwards from that date (you need time to write drafts, have public discussion, and let the ADs evaluate the proposed BOF, etc.), the right time to start preparing is almost certainly the meeting before the one where you want the BOF. Starting only 2 months before an IETF meeting is, in most cases, waiting too long 😬 and will likely get the BOF pushed to the following IETF meeting. Not me sweating for you 💀

The recommended steps for a BOF are as follows 🧚

  1. A small group of individuals gets together privately, discusses a possible problem statement, and identifies the work to be done 🎀 This group acts as a sort of "design team" to formulate a problem statement, identify possible work items, and propose an agenda for a BOF.

Possible sub-steps:

  • a) Consider whether the work might already fall within the scope of an existing Working Group, in which case a BOF might not even be necessary. Individual Working Group charters can be found at http://www.ietf.org/html.charters/wg-dir.html and indicate what a group is scoped to work on 📚
  • b) Select the area or areas in which the work most naturally fits by identifying WGs that most closely relate to the proposed work. It's not uncommon to find that a work item could easily fit into two (or more) different areas and that no one area is the obvious home 🤷‍♀️
  • c) Consult with specific WGs to see whether there is interest or whether the work is in scope. You can do this by posting messages directly to WG mailing lists, contacting the WG chairs, or contacting individuals known to participate in a particular WG (e.g., from their postings or from documents they have authored) 💌
  • d) Consult with an area-specific mailing list about possible interest. (Most areas have their own area-specific mailing lists. Follow the links under each area at http://www.ietf.org/html.charters/wg-dir.html to find details.) 🔗
  • e) Produce one or more Internet Drafts describing the problem and/or related work. It cannot be emphasized enough that, for the BOF, drafts relating to understanding the problem space are much more valuable than drafts proposing specific solutions 🧠✨

Timeline: This step can easily take 1-2 months, so begin 3-4 months before an IETF meeting ⏳

  1. The group may (or may not) approach an Area Director (or other recognized or experienced leader) to informally float the BOF and get feedback on the proposed work, the scope of the charter, specific steps that need to be taken before submitting a formal BOF request, etc. 🫧 By "leader," we mean persons with significant IETF experience who can give helpful advice. Individuals who have successfully hosted BOFs before, current or former WG chairs, and IESG or IAB members would be good candidates 👑

The dividing line between steps 1) and 2) is not exact 🌀 At some point, you'll need to approach one or more Area Directors (ADs) with a specific proposal that can be commented on. Step 1) helps shape an idea into something concrete enough that an AD can understand the purpose and give concrete feedback. On the other hand, don't spend too much time on step 1) if the answer at step 2) turns out to be "oh, we had a BOF on that once before; have you reviewed the archives?" 💀 So there may be some iteration, going back and forth between steps 1) and 2). Also, a quick conversation with an AD might lead them to suggest some specific individuals or WGs you should consult with 🫶

It may turn out that it's unclear which area the proposed work best fits. In that case, when approaching multiple ADs, it's best to approach the ADs approximately simultaneously, say that you're unsure which area the work fits, and ask for advice (e.g., by stating "I'm not sure which area this work best fits under, but it looks like it might be Internet or Security or both"). When contacting multiple ADs, it is strongly advised that you tell them which other ADs you are talking to 🙏 It's usually counterproductive and not advisable to go "AD shopping," where, if one AD gives you an answer you don't like, you go to another one without telling them what the first AD said, in the hopes of getting a more favorable answer. Not the move 🙅‍♀️

To sum up, steps 1) and 2) are a lot of "socializing an idea," which means having discussions with a bunch of different people to try to gain agreement on the problem and on the need for, and appropriateness of, a BOF 🦋 How much discussion is needed is very subjective, but it's critical for getting agreement that a BOF is appropriate. One way to tell if you're close to getting it right: when you talk to someone about your idea for the first time, they quickly agree that a BOF seems in order and don't have any major concerns 🥹

Timeline: Steps 1-2) can easily take 1-2 months, so begin 3-4 months before an IETF meeting 🗓️

  1. Create a public mailing list and post a "call for participation" for the proposed BOF topic on various mailing lists (e.g., the IETF list) 📣 The call for participation advertises that a "community of interest" is being formed to gauge whether there's sufficient interest to host a BOF. The goal is to draw in other interested potential participants so they can help shape the BOF (e.g., by giving them time to write a draft, ask for agenda time, help scope the proposed work, or argue that a BOF is (or is not) needed, etc.) 🌈

Timeline: This step can easily take 1 month or longer. It also needs to start well before the Internet-Drafts cutoff (to allow participants to submit drafts), so begin 2.5-3.5 months before the IETF meeting ⏰

  1. Have substantive mailing list discussion 🗨️ It's not enough for a handful of people to say they want a BOF; there needs to be broader community interest. A public mailing list lets ADs (and others) gauge how much interest there really is in a topic area, as well as how well the problem statement has been scoped, etc. At this phase, the emphasis should be on getting agreement on the problem statement. Discussions about specific solutions tend to be distracting and unhelpful 🙃

Timeline: This step can easily take 1 month or longer, so begin 2.5 months before the IETF meeting 📅

  1. Submit a formal request to have a BOF 📝 Instructions for submitting a formal request can be found at http://www.ietf.org/instructions/MTG-SLOTS.html and http://www.ietf.org/ietf/1bof-procedures.txt. Note that as part of making a formal request, the organizers must identify the area in which the BOF will be held (the Area Directors of that area will be required to approve the BOF), include a proposed BOF agenda, estimate the attendance, list conflicts with other sessions that should be avoided, etc. 🫠

If the previous steps have been followed, the Area Directors (ADs) should be in a good position to gauge whether there's sufficient interest to justify approving a BOF ✨

Note: it almost goes without saying that without one or more Internet Drafts at this point, it is generally pointless to ask an AD to approve a BOF. 🚫📄

Timeline: The Secretariat publishes an "important meeting dates" calendar along with meeting information. There is a firm deadline (about six weeks before the meeting) for submitting a formal BOF scheduling request. Note that at the time of the deadline, an AD will need to have sufficient information about the BOF to approve or reject the request, so all of the previous steps will need to have been completed 🏁

  1. During the 2-4 weeks before an IETF meeting (assuming a BOF has been approved and scheduled), the focus on the mailing list should be on identifying areas of agreement and areas of disagreement 🔍 Since disagreement, or "lack of consensus," tends to be the main reason a WG doesn't get formed, focusing on those specific areas of "lack of consensus" is critically important 🥊 In general, a WG will only be formed after those disagreements have been resolved, so the main goal should be to find consensus and work through the areas of disagreement. Alternatively, you can make a specific case for why the charter, as it's written, is the best one, in spite of the stated opposition 💅
  2. Before the BOF, it is critical to produce a proposed charter and iterate on it on the mailing list to try to reach a consensus charter 📜 Ultimately, the most important question to ask during a BOF is: "should a WG with the following charter be formed?" It goes without saying that a charter with shortcomings (no matter how seemingly trivial they are to fix) won't achieve consensus if folks still have issues with the specific wording 🙈
  3. Decide which questions will be asked during the BOF itself ❓ Since the exact wording of the questions is critical (and hard to do on the fly), it is strongly recommended that those questions be floated on the mailing list and to the ADs before the BOF 💜 This lets people understand what they'll be asked to approve, and lets the questions be modified (before the BOF) to remove ambiguities, etc. Likewise, discussing these questions in advance may lead to refining the charter so that the questions can be answered affirmatively 🌸
  4. At the meeting, but before the BOF takes place, plan a meeting with all of the presenters so they can meet each other, review the agenda, and make sure everyone understands what's expected of them (e.g., what time constraints they'll be under when presenting) 🎤 Use this time to also work through any disagreements that still remain. Do the same "in the hallway" with other interested parties! 🚶‍♀️💨
  5. Check the tutorial schedule and consider attending relevant tutorial sessions ("Working Group Chair Training," "Working Group Leadership Training," etc.) 🎓 This is especially the case if you're considering being the chair of a proposed WG. Since the role of the WG chair and the BOF chair have a number of parallels, a number of the topics covered in the tutorial apply to hosting a BOF and developing a charter 🌟

3. The Importance of Understanding the Real Problem ✨

okay so first things first, bestie: the WG has to know the real problem 🧠. Throughout chartering new work in the IETF, the biggest thing is figuring out (and getting consensus on) what the real, underlying problem is that the customer, operator, or deployer of a technology has and that the WG needs to address. When a WG wraps up, its output is only useful if it actually solves a real, compelling problem faced by the actual user of the tech (i.e., the customer or operator). Unfortunately, more than a few WGs have had their output not adopted 💀, and sometimes the reason was that nobody understood the real problem the operator had. The output just didn't address the right problem. Rough. 😭

Another thing that happens is that arguing over specific (or competing) solution approaches totally stalls the WG (or BOF) so nothing moves 🙃. Lowkey, the arguments about whether a technology is appropriate are often really proxies for whether a proposed approach adequately addresses the problem. If it's unclear what the underlying problem even is, you can get arguments that never resolve about a technical approach, depending on how you see the problem and its constraints. So it's critical that all work is guided by a clear and shared understanding of the underlying problem. No cap. 💜

The best description of an actual problem usually comes from the customer, operator, or deployer. They're the ones who clearly understand the difficulties that need addressing, and they're the ones who'll have to deploy any proposed solution 🫶. So it's critical to hear their voice when formulating the details of the problem statement. Also, when comparing the merits of different solution approaches, it's often helpful to go back to the underlying problem statement to guide picking the more appropriate approach 🎯.

4. The BOF Itself 🎀

For the BOF itself, it's critically important to focus on the bottom line:

What is it that one is attempting to achieve during the BOF?

Or, put differently: after the BOF is over, by what criteria will you decide whether or not the BOF was successful? 🤔

A good BOF organizer keeps a firm focus on the purpose of the BOF and crafts an agenda that supports that goal. Just as important, presentations that don't directly support the goal should be excluded 🚫, because they become distractions, sow confusion, and take focus away from the purpose of the BOF. If the goal is to form a WG, everything should lead to an (obvious) answer to this question:

Does the room agree that the IETF should form a WG with the following (specific) charter?

One of the best ways to get a "yes" to that is doing adequate prep before the BOF so the community as a whole already agrees the answer is "yes" 💅. How does one do that? One good way seems to be:

  1. Have a public discussion with sufficient time to allow iteration and discussion. (So start a minimum of 3 months prior to the IETF meeting.) 🗓️
  2. Work with the community to iterate on the charter and be sure to address the significant concerns that are being raised. (You can address the concerns in advance and get advance agreement, or have them raised (again) during the BOF -- in which case the proposed charter probably won't be good enough to get agreement during the actual BOF.) 🙅‍♀️
  3. During the BOF, keep the agenda tightly focused on supporting the need for the WG and making the case that the group has identified a clearly-scoped charter and has agreement on what the set of deliverables should be. 🔥

Another important reason for holding a BOF is to figure out how the attendees (and the larger community) feel about the proposed work 🧚. Do they understand and agree on the problem that needs solving? Do they agree the problem is solvable, or that new protocol work is needed? To better understand the degree of agreement, it's useful to ask the audience questions.

Whenever you're asking questions, it's important to ask the right ones -- questions that show where there's agreement and questions that probe the details around where agreement is lacking. Good questions typically focus on aspects of the problem in a piecewise fashion, establishing areas of consensus and identifying areas where additional work is needed. Poor questions don't help focus future discussion where it's needed 🙈. Here are examples that are often useful:

  1. Is there support to form a WG with the following charter? (That is, the charter itself is ready, as shown by community support.) ✅
  2. Does the community think that the problem statement is clear, well-scoped, solvable, and useful to solve?
  3. Can I see a show of hands of folk willing to review documents (or comment on the mailing list)? 🙋‍♀️
  4. Who would be willing to serve as an editor for the following document(s)? (BOF chairs should take note of individuals who raise their hands, but it's also a useful gauge to see if there is a critical mass of editors to work on all the documents that are to be produced.) ✍️
  5. Does the community think that given the charter revisions discussed during the BOF (subject to review and finalization on the mailing list), a WG should be formed?
  6. How many people feel that a WG should not be formed? (If the number of no responses is significant, it would help to ask those saying no why they are opposed.) 👀
  7. Before asking a particular question, it is sometimes very appropriate to ask: Do people feel like they have sufficient information to answer the following question, or is it premature to even ask the question?

Unfortunately, it's also easy to ask the wrong questions. Some examples are given in a later section. 💀

5. Post-BOF Follow-Up 🦋

After the BOF has taken place, it's advisable to take an assessment of how well things went and what the next steps are. The ADs should be included in this assessment. Some things to consider:

  1. Did the BOF go well enough that the logical next step is to focus on refining the charter and becoming a WG before the next IETF meeting? If so, there will almost certainly be additional discussion on the mailing list to refine the charter and work out a few remaining items. 🌸

Note that it can be difficult to determine in some cases whether a WG is a feasible next step. Much will depend on details of how the BOF went and/or whether the contentious items can either be resolved on the mailing list or simply be excluded from the charter and dealt with later (if at all). Much will also depend on the relevant AD's assessment of whether the proposed work is ready to move forward. Sometimes even a seemingly contentious BOF can result in a WG being formed quickly -- provided the charter is scoped appropriately. ✨

If the next step is to attempt to form a WG, the charter needs to be finalized on the BOF-specific mailing list. Once done, the IESG can be asked to formally consider the charter. The IESG then (usually) posts the proposed charter to the IETF list for community feedback and makes a decision based in part on the feedback it receives. 📬

  1. It may be the case that enough additional work still needs to take place that aiming for a second (and final) BOF makes more sense. In that case, many of the steps outlined earlier in this document would be repeated, though at a faster pace. 🏃‍♀️

The expectations for a second BOF are generally higher than those for an initial BOF. In addition to the work done up through the first BOF, the first BOF will have highlighted the key areas where additional work is needed. The time leading up to the second BOF will need to be spent working through those outstanding issues. Second BOFs should not be a repeat of the first BOF, with the same issues being raised and the same (unsatisfactory) responses provided. The second BOF needs to show that all previously identified issues have been resolved and that formation of a WG is now in order. main character energy, bestie 🌈👑

6. Pitfalls 💅

okay so over the years the community has spotted a bunch of pitfalls, and they keep happening (repeatedly 😭).

  1. Waiting too long before getting started. Prepping for a BOF on short notice is so hard 💀. ADs are also stuck in a no-win spot when they're asked to approve a BOF that the community hasn't had a chance to join. Steps 1-4 in Section 2 above exist to show the ADs there's real community support for an effort. If you skip those steps, the AD has to make a judgment call with (usually) way too little info. And since the community wasn't involved, way more significant (and valid) objections are likely to pop up. A lot of those could've been handled in advance, if there'd been enough time to work through them first 🫶.
  2. Too much focus on solutions instead of showing support for the problem statement. The BOF is almost never about showing off solutions that already exist 🙅‍♀️. Its job is to prove that there's a real problem that needs solving, that a solution would actually help the community, that a solution is believed to be achievable, and that there's a critical mass of community support to actually put in the real work of building one ✨.
  3. Asking the wrong question during the BOF. BOF organizers often feel like they need a "show of hands" on specific questions 🙋‍♀️. But unless a question is clear, well scoped, and focused enough to show where people agree (and where they don't), asking it doesn't really help anyone. Even worse, bad questions can frustrate BOF participants and lead to more questions at the microphone, which derails the whole focus of the BOF 😤.

Examples of unreasonable questions to ask:

  • Asking folk to approve or review a charter that is put on screen but has not been posted to the mailing list sufficiently in advance. (You cannot ask folk to approve something they have not seen.)
  • Asking multi-part questions where it isn't clear (in advance) what all of the exact questions will be, or which choices a participant needs to pick from.
  1. Poorly advertised in advance, so the BOF doesn't get the "right" participants. This can happen for a bunch of reasons 🥲, including:
    • Giving the BOF a "cute" but unintuitive name (or acronym), so people can't tell it would be relevant to them.
    • Not advertising the BOF in advance to the community of people who might be interested. At a minimum, a proposed BOF should be advertised on the IETF list as well as on specific WG lists that are somewhat related 📣.
  2. Giving agenda time to the "wrong" presentations. There's an (unfortunate) tendency to give anyone who asks for agenda time a chance to speak, and that's often a mistake 🙃. Presentations should be limited to ones that address the purpose of the BOF. Even more importantly, presentations shouldn't distract from the BOF's purpose or open up ratholes that pull attention away from its basic goal. An example of problematic presentations:
    • Presentations on specific solutions, when the purpose of the BOF is to get agreement on the problem statement and the need for a WG. Solutions at this stage are too often "half-baked," and they let discussion rathole on aspects of the solutions. Instead, the focus should be on getting agreement on whether to form a WG 🎯.
  3. Poor time management, leaving too little time for discussion of the key issues. This is often closely related to pitfall 5 ⏰. When presentations run over their allotted time, the result is either squeezing someone else's presentation or not having enough discussion time. Neither is acceptable or helpful. BOF chairs need to give presenters just enough time to make their key points, and no more. It may be really helpful to go over a presenter's slides in advance, to make sure they're on-topic and will fit in the time slot 💖.

7. Miscellaneous ✨

7.1. Chairing

BOF organizers often assume they'll be chairing the BOF (and the eventual WG). But neither assumption is always true 🤷‍♀️. ADs need to make sure a BOF runs smoothly and is productive. For some topics, it's a given that the BOF will be contentious. In those cases, ADs may want a more experienced person chairing or co-chairing the BOF 🧠. Also, the people interested in organizing a BOF are often the most invested in driving a particular technology, and they may have strongly held views about which direction an effort should take 🔥. Working Groups tend to work better when the passionately involved parties can focus on the technical work, instead of managing the WG itself 🌸. So don't be surprised (or offended!) if the AD wants to pick one or more co-chairs for either the BOF or a follow-on WG 💅.

7.2. On the Need for a BOF

This document highlights the need to allow for, and actively engage in, a broad public discussion on the merits of forming a WG 📢. It might surprise some people, but there's no actual process requirement to have a BOF before forming a WG 😮. The real process requirement is simply that the IESG (together with the AD(s) sponsoring the work) approve a formal charter as described in [RFC2418]. In practice, BOFs are used to engage the broader community on proposed work and to help produce an acceptable charter 🦋.

Two observations come out of this. First, BOFs often get held not because they're (strictly speaking) required, but because people assume they're needed, or because ADs feel a BOF would help get more public participation 🎀. So if you're interested in forming a WG, give serious thought to using the steps outlined above not just to create a BOF, but to convince the IESG and the broader community that a BOF isn't even needed, because there's already demonstrated, strong consensus that a WG should be formed ✨. Second, the IESG shouldn't forget that BOFs are simply a tool, and may not even be the best tool in every situation 🧰.

8. Security Considerations 🔒

This document has no known security implications.

9. Acknowledgments 🫶

This document has benefited from specific feedback from Jari Arkko, Brian Carpenter, Dave Crocker, Spencer Dawkins, Lisa Dusseault, Pasi Eronen, John Klensin, Tim Polk, Mark Townsley, and Bert Wijnen. Thank you all, you're the real MVPs 👑💜.

10. Informative Reference 📚

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

Author's Address 🖋️

Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709-2195

Phone: 919-254-7798
EMail: narten@us.ibm.com
📦 where this page comes from