<pre>Internet Engineering Task Force (IETF)                         L. Eggert
Request for Comments: 6771                                        NetApp
Category: Informational                                     G. Camarillo
ISSN: 2070-1721                                                 Ericsson
                                                            October 2012


     <span class="h1">Considerations for Having a Successful "Bar BOF" Side Meeting</span>

Abstract

   New work is typically brought to the IETF by a group of interested
   individuals.  IETF meetings are a convenient place for such groups to
   hold informal get-togethers to discuss and develop their ideas.  Such
   side meetings, which are not reflected in the IETF meeting agenda and
   have no official status, are often half-jokingly referred to as "bar
   BOF" sessions to acknowledge that some of them may eventually lead to
   a proposal for an official IETF BOF ("birds of a feather" session) on
   a given topic.

   During recent IETF meetings, many such "bar BOF" get-togethers have
   been organized and moderated in ways that made them increasingly
   indistinguishable from official IETF BOFs or sometimes even IETF
   working group meetings.

   This document argues that this recent trend is not helpful in
   reaching the ultimate goal of many of these get-togethers, i.e., to
   efficiently discuss and develop ideas for new IETF work.  It
   encourages the organizers to consider the benefits of holding them in
   much less formal settings and to also consider alternative means to
   develop their ideas.  This document also recommends that the
   community abandon the term "bar BOF" and instead use other terms such
   as "side meeting", in order to stress the unofficial nature of these
   get-togethers.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.





<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6771">http://www.rfc-editor.org/info/rfc6771</a>.

Copyright Notice

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

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to 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 are provided without warranty as
   described in the Simplified BSD License.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   A typical IETF meeting is full of sessions of different kinds.  In
   addition to official IETF and IRTF sessions listed in the meeting
   agenda (such as working and research group meetings, area meetings,
   or plenaries), many other unofficial meetings take place.  These
   include meetings between IETF participants from one organization or
   company, design team meetings, Internet-Draft editing sessions,
   interoperability testing, directorate lunches, and many others.

   Some of these unofficial get-togethers are organized by individual
   participants with a common interest in initiating new IETF work of
   some kind.  New IETF work often fits into an existing working group
   and does not require an official "birds of a feather" (BOF) session
   [<a href="./rfc5434" title="&quot;Considerations for Having a Successful Birds- of-a-Feather (BOF) Session&quot;">RFC5434</a>] to determine community consensus.  Nevertheless, the phrase
   "bar BOF" has commonly been used in the community when talking about
   such informal get-togethers that are held to discuss potential new
   work.  [<a href="./rfc4677" title="&quot;The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force&quot;">RFC4677</a>] (which has been obsoleted by [<a href="./rfc6722" title="&quot;Publishing the &quot;">RFC6722</a>])
   characterizes a "bar BOF" as

      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.

   During recent IETF meetings, "bar BOFs" have become increasingly
   indistinguishable from official IETF BOFs or sometimes even IETF
   working group meetings.  The symptoms of this trend are unofficial
   "bar BOFs" that are held in regular IETF meeting rooms with



<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


   classroom-style seating, agendas with lengthy slide presentations,
   use of microphone lines, and even formal consensus calls.  And,
   perhaps most importantly, such meetings have a distinct lack of
   drinks.

   This document argues that this trend is not helpful in reaching the
   ultimate goal of many of these get-togethers, i.e., to brainstorm
   about a technical topic that may eventually lead to new IETF work.
   It encourages the organizers of these unofficial get-togethers to
   consider the benefits of holding them in much less formal settings.

   This document also recommends that the community abandon the term
   "bar BOF".  The distinction between a BOF, i.e., an official IETF
   activity, and a "bar BOF", i.e., an unofficial get-together, is lost
   on many IETF participants, especially newcomers.  The similarity in
   terms has even caused confusion to the point where some participants
   believe that a "bar BOF" is a required step in the IETF process in
   order to apply for an official BOF, which is obviously false.  For
   these reasons, the remainder of this document will use the term "side
   meeting" instead and recommends that the community do the same, in
   order to stress the unofficial nature of these get-togethers.

   Before going into more detailed advice on how to hold side meetings,
   it is important to remember that many participants are extremely busy
   during an IETF meeting.  Although having a side meeting to discuss an
   idea in an informal face-to-face setting is attractive, the
   scheduling of such meetings is very difficult and needs to happen
   weeks, if not months, prior to the meeting itself.  Conference calls,
   email discussions, wikis, jabber group chats, and other ways for
   interacting are also effective at developing ideas and easier to
   schedule.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  How to Invite</span>

   A good rule of thumb is that a side meeting to discuss and develop a
   proposal for new IETF work should include the necessary participants
   to achieve that purpose and no more.  Smaller meetings are usually
   more successful than larger meetings.

   Hence, it is often useful to limit attendance carefully.  Publicly
   broadcasting an announcement for a side meeting on a particular
   topic, e.g., on an IETF mailing list, is therefore not usually a good
   method of inviting the desired set of participants.

   One reason is that if the announcement happens to attract a large
   response, the logistics of organizing a side meeting for a larger
   group quickly becomes very difficult.  Small groups fit comfortably
   around a table at a bar or a restaurant or can find a quiet corner in



<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


   an IETF hallway for a discussion.  Larger groups require dedicated
   meeting facilities, which are limited during IETF meetings, and they
   generally require much more careful planning in order to get work
   done.

   When publicly announcing a side meeting, it is often not even
   possible for the organizers to determine how large the resulting get-
   together will be, forcing them to over-provision for the "best case"
   of a substantial attendance, even in cases where this turns out to be
   not necessary.  And even when a large group comes together, it often
   mostly consists of "tourists".  Tourists usually do not actively
   participate in the get-together at all, or they participate with an
   intent to learn about a topic, which can derail a planned discussion
   of specific issues and turn it into a tutorial.  The attendance of
   tourists requires finding a larger room and makes the interactions
   between the active participants more cumbersome, e.g., because
   microphones need to be used in larger rooms.  There are times to
   expose new ideas to a broader community, but think carefully before
   publicly announcing a side meeting.

   So while publicly announcing a side meeting can be useful in order to
   gather interested people for a discussion, it often makes sense to
   still 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 is not
   necessary and may not even be advisable in many cases.  Some ideas
   need time to form before they result in anything cohesive, and a side
   meeting is a good time to develop new ideas.  It is usually most
   useful to approach Area Directors (ADs) and IAB members for comments
   after an idea has solidified enough so that an elevator pitch can be
   given.  Also, it should be clear that if an AD or IAB member attends
   a side meeting, it is not necessarily a show of support.  They may
   simply be interested or often may be concerned or troubled with some
   aspect of the potential work and relation to existing work.  On the
   other hand, when an AD or IAB member declines to attend a side
   meeting, that is usually not a sign of disinterest or disapproval --
   these people have busy schedules, especially during an IETF week.

   In the initial stages of developing a proposal for new IETF work, the
   ability for interested and experienced participants to brainstorm is
   tremendously important.  Brainstorming is facilitated by direct,
   interactive, and high-bandwidth discussions.  This is clearly much
   more easily achieved in a smaller setting, where half-baked ideas can
   be dissected and developed.  This is often not possible in a larger



<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


   group.  Even worse, a badly run large meeting can sometimes "poison
   the waters" for a proposed idea by convincing the broader community
   that the proposal is confused, not ready, or otherwise uninteresting.

   Another reason to discuss new work proposals in smaller groups is
   scope creep, i.e., the tendency of an initially rather tightly scoped
   area of new work to expand, because people will argue that whatever
   the initial topic was, it should be expanded to include their
   particular item of interest.  This is harder to control in larger
   groups.  Keeping the scope of new work items narrow is important,
   because eventual chartering decisions are often much more difficult
   for larger items of new work than for smaller ones.

   It is important to understand that in the IETF, proposals for new
   work are judged based on their technical merits and on whether there
   is enough energy and interest in the community to complete the work
   in a timely manner.  This 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 this decision and is not a good metric for reporting interest in a
   topic to the community or to employers.  Discussions about new work
   are often controversial, and people will show up just to watch the
   fireworks, learn about a new topic, or make sure the new work does
   not interfere with work they are already pursuing, without being
   interested contributing in some way to the actual proposal itself.

   Some side meetings are organized to discuss a topic that is 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 side meeting is
   organized by a chair or key participant of a working group in order
   to discuss topics related to the working group does not make it any
   more official than other side meetings.  An "ad hoc session" is not
   an official working group session, and no decisions relevant to a
   working group can be made.  Working group consensus can only be
   established during official sessions or on the mailing list
   [<a href="./rfc2418" title="&quot;IETF Working Group Guidelines and Procedures&quot;">RFC2418</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Where to Meet</span>

   As the colloquial name "bar BOF" implied, such side meetings are
   traditionally held in bars or restaurants.  Recently, there has been
   a distinct shift towards holding such get-togethers in regular IETF
   meeting rooms.  One reason for this trend has been discussed in
   <a href="#section-2">Section 2</a>, namely, that an uncontrolled broadcast announcement
   requires over-provisioning of facilities.





<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


   A second reason for this trend is that some participants, e.g., non-
   native English speakers or participants with hearing difficulties,
   find it difficult to interact or follow a discussion in noisy
   environments, such as restaurants and especially bars.  The
   organizers of side meetings are encouraged to take this factor into
   consideration when finding a meeting place.  Quiet restaurants are
   not hard to find, and many offer private dining rooms at no extra
   charge for larger parties.

   A likely third reason why side meetings are increasingly held in IETF
   rooms is that the booking of such a room currently requires approval
   by an Area Director.  The reason for this practice is simply to make
   sure that IETF-paid rooms are used for meetings that are in the
   widest sense IETF-related.  However, the approval of a room request
   for a side meeting has been known to sometimes be reported as Area
   Director "support" for the topic of the meeting to the community or
   to employers.  No such support is expressed or implied when Area
   Directors approve room requests!  Many routinely say "yes" to every
   incoming request as long as there are meeting rooms available (and
   there are typically lots of meeting rooms available outside of normal
   working group meeting slots).

   Holding side meetings in IETF meeting rooms does not make them any
   more official or valid than get-togethers that happen in other
   places.  Participants have recently begun to list the times and
   locations of some side meetings on a wiki page, but that does not
   make them part of the official IETF agenda or otherwise change their
   unofficial status.

   IETF meeting rooms clearly do not provide the most supportive
   environment for side meetings that require brainstorming on a new
   technical proposal.  One reason is that the classroom-style seating
   often present in IETF meeting rooms tends to spread people out in
   rows, all facing towards a front presenter, which is good for
   presentations but bad for discussion.  Because IETF meeting rooms
   tend to be large and people have a natural tendency to spread out,
   holding a meeting in one often requires microphone use, which is
   cumbersome, slows a discussion down, and leads to "question-answer"
   dialogs between two people, which is much less effective than a group
   discussion around a restaurant table.

   Another reason is more pragmatic.  Because the organizers of
   unofficial get-togethers can only use IETF meeting rooms during times
   when they are not otherwise in use, such side meetings often happen
   during breakfast, lunch, dinner, or later in the evening.  This
   prolongs the time during which IETF participants are stuck in the
   same rooms they're stuck in for the rest of the day, and it prevents
   them from having a regular and at least somewhat relaxed meal.



<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


   Anecdotal evidence exists that at least one Area Director has not
   been able to set foot outside the IETF hotel for a stretch of 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 is unlikely that participants in the consequential
   mental and bodily state will make productive contributions to a side
   meeting or, in the case of Area Directors, will be extremely
   receptive towards new work proposals.

   Food, drink, and a relaxed atmosphere in which to have a discussion
   are an essential part of a successful side meeting, because they
   often need to happen during meal times.  IETF meeting rooms offer
   neither.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  How to Meet</span>

   Several of the recent side meetings that were held in IETF meeting
   rooms emulated official IETF meetings to a degree that made them
   indistinguishable from a regular working group meeting for the
   average IETF attendee.  This included detailed agendas, lengthy
   presentations, organizers who refer to themselves as "bar BOF
   chairs", emulating blue sheets (see <a href="./rfc4677#section-4.5">Section&nbsp;4.5 of [RFC4677]</a>), and
   even hums and other consensus calls (see <a href="./rfc4677#section-5.2">Section&nbsp;5.2 of [RFC4677]</a>).

   It is not clear as to why this has been happening.  One attempt at an
   explanation may be that holding a get-together in an IETF room and
   having the organizers behave like chairs behave during regular IETF
   sessions is causing a Pavlovian stimulus in the attendees.  Another
   explanation attempt is that an IETF meeting room simply does not
   allow many other forms of discussion.  Finally, some organizers may
   find the process to apply for an official BOF too complex or
   troublesome (and probably rightfully so) and so decide to simply
   mimic one, or they had applied for an official BOF, got turned down,
   and then decided to hold the same meeting as a side meeting.

   Whatever the reason for this development, it is reasonably obvious
   that running a side meeting with a focus on making quick progress on
   a technical proposal in a way that emulates running a working group
   session is not very productive.  Working group sessions follow
   certain procedures due to larger audiences, the need to establish
   formal consensus, etc., that a side meeting can do without.

   Having side meetings mimic working group meetings is also confusing
   to attendees.  In at least one case, some side meeting participants
   believed that they were attending an actual working group meeting,
   and incorrect press announcements were generated.  When side meetings
   take place at restaurants or elsewhere away from IETF meeting rooms,
   the chance for confusion is much lower.



<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


   Because the reasons for organizing such a get-together are diverse,
   this section is not making more specific suggestions, other than to
   note that meeting outside of an IETF meeting room is likely going to
   shift the dynamics sufficiently so that better interactions and
   results become possible.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  When to Meet</span>

   Side meetings are often scheduled following IETF evening plenaries,
   which sometimes end before the time indicated on the meeting agenda
   but have in the past also ended much later.  It is therefore useful
   to avoid scheduling side meetings that follow IETF plenaries at a
   fixed time.  Instead, it is recommended to schedule them relative to
   the end of the plenary, i.e., "X minutes after the end of the
   plenary".  That way, attendees do not need to wait around if a
   plenary finishes early and do not need to leave a plenary should it
   run late.

   <a href="./rfc5434#section-3">Section&nbsp;3 of [RFC5434]</a> raises the issue that it is essential to
   understand all angles of a given problem for which IETF work is
   proposed.  This means that input from the community that can be found
   at IETF meetings is not all that should be considered.  It can be
   argued that input from other communities -- operator, research,
   regulatory, etc. -- is at least as important.  Hence, organizers
   should consider the value of holding side meetings at venues where
   such input can be more easily gathered, such as operator fora (RIPE,
   NANOG, etc.), research conferences, or other events.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Conclusions</span>

   Side meeting organizers are encouraged to rekindle the original
   spirit behind them and organize them outside IETF meeting rooms, at
   venues with food and drink, for smaller groups, and in a way that
   does not needlessly mimic the way official IETF sessions are
   conducted.

   It can often be useful to discuss proposals for new IETF work face-
   to-face in an informal setting, but conference calls, email
   discussions, wikis, and other means for interactions are also
   effective at developing ideas, especially given the scheduling
   difficulties when busy individuals are involved during an IETF
   meeting.

   Finally, it is important to remember that all side meetings during an
   IETF week are purely informal and have no official status whatsoever.






<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   A security AD pointed out that people have been known to forget their
   laptops after side meetings held in real bars.  The organizers of
   side meetings should therefore 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.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgments</span>

   The name and title of this document have been chosen to resemble
   those used by Thomas Narten for his guidelines document on holding a
   successful BOF [<a href="./rfc5434" title="&quot;Considerations for Having a Successful Birds- of-a-Feather (BOF) Session&quot;">RFC5434</a>], as a sign of appreciation for a document
   that has proven to be invaluable many times over.

   Several folks provided 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 [<a href="#ref-TRILOGY" title="&quot;Trilogy Project&quot;">TRILOGY</a>], a research project
   supported by the European Commission under its Seventh Framework
   Program.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Informative References</span>

   [<a id="ref-RFC2418">RFC2418</a>]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", <a href="https://www.rfc-editor.org/bcp/bcp25">BCP 25</a>, <a href="./rfc2418">RFC 2418</a>, September 1998.

   [<a id="ref-RFC4677">RFC4677</a>]  Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
              Guide to the Internet Engineering Task Force", <a href="./rfc4677">RFC 4677</a>,
              September 2006.

   [<a id="ref-RFC5434">RFC5434</a>]  Narten, T., "Considerations for Having a Successful Birds-
              of-a-Feather (BOF) Session", <a href="./rfc5434">RFC 5434</a>, February 2009.

   [<a id="ref-RFC6722">RFC6722</a>]  Hoffman, P., "Publishing the "Tao of the IETF" as a Web
              Page", <a href="./rfc6722">RFC 6722</a>, August 2012.

   [<a id="ref-TRILOGY">TRILOGY</a>]  "Trilogy Project", &lt;<a href="http://www.trilogy-project.org/">http://www.trilogy-project.org/</a>&gt;.










<span class="grey">Eggert &amp; Camarillo            Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6771">RFC 6771</a>            Successful Bar BOF Side Meetings        October 2012</span>


Authors' Addresses

   Lars Eggert
   NetApp
   Sonnenallee 1
   Kirchheim  85551
   Germany

   Phone: +49 151 12055791
   EMail: lars@netapp.com
   URI:   <a href="http://eggert.org/">http://eggert.org/</a>


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com































Eggert &amp; Camarillo            Informational                    [Page 10]
</pre>