idnits 2.17.1 draft-eggert-successful-bar-bof-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 25, 2010) is 5145 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Eggert 3 Internet-Draft Nokia 4 Intended status: Informational March 25, 2010 5 Expires: September 26, 2010 7 Considerations for Having a Successful Bar BOF Session 8 draft-eggert-successful-bar-bof-00 10 Abstract 12 During recent IETF meetings, bar BOF ("birds of a feather") sessions 13 have increasingly become indistinguishable from official IETF BOFs or 14 sometimes even IETF working group meetings. This document argues 15 that this recent trend is not helpful in reaching the ultimate goal 16 of many of these bar BOFs (i.e., to eventually initiate new IETF 17 work). It encourages the organizers of bar BOFs to consider the 18 benefits of holding such get-togethers in much less formal settings. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, and it may not be 25 published except as an Internet-Draft. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 26, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 1. Introduction 62 A typical IETF meeting is full of sessions of different kinds; bar 63 BOF ("birds of a feather") sessions being one such kind. [RFC4677] 64 characterizes a bar BOF as 66 "(...) an unofficial get-together, usually in the late evening, 67 during which a lot of work gets done over drinks. Bar BOFs spring 68 up in many different places around an IETF meeting, such as 69 restaurants, coffee shops, and (if we are so lucky) pools." 71 During recent IETF meetings, bar BOFs have increasingly become 72 indistinguishable from official IETF BOFs or sometimes even IETF 73 working group meetings. This is especially true for bar BOFs that 74 are held to encourage new IETF work on a specific topic. The 75 symptoms of this trend are bar BOFs that are held in regular IETF 76 meeting rooms with classroom-style seating, agendas with lengthy 77 slide presentations, use of microphone lines, and even formal 78 consensus calls. And, perhaps most importantly, a distinct lack of 79 drinks. 81 This document argues that this recent trend is not helpful in 82 reaching the ultimate goal of many of these bar BOFs (i.e., to 83 eventually initiate new IETF work). It encourages the organizers of 84 bar BOFs to consider the benefits of holding such get-togethers in 85 much less formal settings. 87 2. How to Invite 89 A good rule of thumb is that a bar BOF should include the necessary 90 participants to achieve its purpose, and no more. Smaller meetings 91 are usually more successful than larger meetings. 93 Hence, it is often useful to limit attendance carefully. 94 Broadcasting a bar BOF announcement is therefore not usually a good 95 method of inviting the desired set of participants. 97 One reason is that if the announcement happens to attract a large 98 response, the logistics of organizing a get-together for larger 99 groups becomes very difficult. Small groups fit comfortably around a 100 table at a bar or a restaurant, or can find a quite corner in an IETF 101 hallway for a discussion. Larger groups require dedicated meeting 102 facilities, which are limited during IETF meetings, and they 103 generally require much more careful planning. 105 A second reason for limiting attendance is group interactions. 106 Experience shows that discussions among groups of more than, say, a 107 dozen folks tend to start requiring explicit moderation, especially 108 when the participants are unfamiliar with one another. This adds 109 cumbersome overheads that lengthen the duration of the session, 110 making it consume more of the most valuable commodity of many IETF 111 attendees - time. 113 Often, it is not even possible for the organizers to determine how 114 large the resulting get-together will be, forcing them to over- 115 provision for the "best" case of a substantial attendance, even in 116 cases where this turns out to be not necessary. And even when a 117 large group comes together, it oftentimes mostly consists of 118 "tourists" who do not usefully participate in the get-together but do 119 require finding larger rooms and whose attendance can make the 120 interactions for active participants more cumbersome, e.g., because 121 microphones need to be used in larger rooms. 123 Even bar BOFs that intend to drum up interest in new IETF work can 124 benefit from controlling attendance. In their initial stages, these 125 efforts benefit tremendously from direct, high-bandwidth feedback 126 from IETF participants experienced in related areas, which is easier 127 to receive and discuss in a smaller setting. Secondly, a badly run 128 large meeting can sometimes "poison the waters" for a while for the 129 proposed idea by convincing the broader community that it should not 130 progress, where a smaller, more concentrated meeting may have been 131 productive. 133 3. Where to Meet 135 As the name "bar BOF" implies, such get-togethers were traditionally 136 held in bars or restaurants. Recently, there has been a distinct 137 shift towards holding such meetings in regular IETF meeting rooms. 139 One reason for this trend has been discussed in Section 2; namely, 140 that an uncontrolled broadcast announcement requires over- 141 provisioning of facilities. 143 A likely second reason for this trend is that the booking of an IETF 144 room requires Area Director approval. This approval of the room 145 request has been known to sometimes be reported as Area Director 146 "support" for the topic of the meeting to the community or to 147 employers. No such support is expressed or implied when Area 148 Directors approve room requests; many routinely say "yes" to every 149 incoming request as long as there are meeting rooms available. 151 Holding bar BOFs in IETF meeting rooms does not make them any more 152 official or valid than bar BOFs that happen in other places. And 153 IETF meeting rooms often do not provide the most supportive 154 environments for a successful bar BOF. 156 One reason is that the classroom-style seating often present in IETF 157 meeting rooms tends to spread people out in rows, all facing towards 158 a front presenter: good for presentations, bad for discussion. 159 Because IETF meeting rooms tend to be large, and people have a 160 natural tendency to spread out, holding a meeting there often 161 requires microphone use, which is cumbersome and slows a discussion 162 down. 164 Another reason is more pragmatic. Because the organizers of bar BOFs 165 can only use IETF meeting rooms during times when they are not 166 otherwise in use, bar BOFs often happen during lunch slots, dinner 167 time, or later in the evening. This prolongs the time during which 168 IETF participants are stuck in the same rooms they're stuck in for 169 the rest of the day, and it prevents them from having a regular and 170 at least somewhat relaxed meal. Anecdotal evidence exists that at 171 least one Area Director has not been able to set foot outside the 172 IETF hotel for a stretch of several days during IETF-77. It is 173 unlikely that bar BOF participants in the consequential mental and 174 bodily state will make productive contributions to a bar BOF or, in 175 the case of Area Directors, will be extremely receptive towards new 176 work proposals. 178 Food, drink and a relaxed atmosphere in which to have a discussion 179 are an essential part of a successful bar BOF. IETF meeting rooms 180 offer neither. 182 4. How to Meet 184 Several of the recent bar BOFs that were held in IETF meeting rooms 185 emulated official IETF meetings to a degree that made them 186 indistinguishable from a regular working group meeting for the 187 average IETF attendee. This includes detailed agendas, lengthy 188 presentations, organizers who refer to themselves as "bar BOF 189 chairs", emulating blue sheets, and even hums and other consensus 190 calls. 192 It is not clear as to why this has been happening. One attempt at an 193 explanation may be that holding a get-together in an IETF room and 194 having the organizers behave like chairs behave during regular IETF 195 sessions is causing a Pavlovian stimulus in the bar BOF attendees. 196 Another explanation attempt is that an IETF meeting room simply 197 doesn't allow many other forms of discussion. 199 Whatever the reason for this development is, it is reasonably obvious 200 that running a bar BOF in a way that emulates running a working group 201 session is not very productive. Because the reasons for organizing 202 such a get-together are diverse, this section is not making more 203 specific suggestions, other than to note that meeting outside of a 204 IETF meeting room is likely going to shift the dynamics sufficiently 205 so that better interactions and results become possible. 207 5. Conclusions 209 Bar BOF organizers are encouraged to rekindle the original spirit 210 behind bar BOFs and organize them outside IETF meeting rooms, at 211 venues with food and drink, for smaller groups and in a way that does 212 not needlessly mimic the way official IETF sessions are conducted. 214 6. IANA Considerations 216 This document raises no IANA considerations. 218 [Note to the RFC Editor: Please remove this section upon 219 publication.] 221 7. Security Considerations 223 This document has no known security implications. 225 [Note to the RFC Editor: Please remove this section upon 226 publication.] 228 8. Acknowledgments 230 The name and title of this document have been chosen to resemble 231 those used by Thomas Narten for his guidelines document on holding a 232 successful BOF [RFC5434], as a sign of appreciation for a document 233 that has proven to be invaluable many times over. 235 Lars Eggert is partly funded by [TRILOGY], a research project 236 supported by the European Commission under its Seventh Framework 237 Program. 239 9. Informative References 241 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 242 Guide to the Internet Engineering Task Force", RFC 4677, 243 September 2006. 245 [RFC5434] Narten, T., "Considerations for Having a Successful Birds- 246 of-a-Feather (BOF) Session", RFC 5434, February 2009. 248 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 250 Author's Address 252 Lars Eggert 253 Nokia Research Center 254 P.O. Box 407 255 Nokia Group 00045 256 Finland 258 Phone: +358 50 48 24461 259 Email: lars.eggert@nokia.com 260 URI: http://people.nokia.net/~lars/