idnits 2.17.1 draft-eggert-successful-bar-bof-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (August 31, 2012) is 4256 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Eggert 3 Internet-Draft NetApp 4 Intended status: Informational G. Camarillo 5 Expires: March 4, 2013 Ericsson 6 August 31, 2012 8 Considerations for Having a Successful "Bar BOF" Side Meeting 9 draft-eggert-successful-bar-bof-09 11 Abstract 13 New work is typically brought to the IETF by a group of interested 14 individuals. IETF meetings are a convenient place for such groups to 15 hold informal get-togethers to discuss and develop their ideas. Such 16 side meetings, which are not reflected in the IETF meeting agenda and 17 have no official status, are often half-jokingly referred to as "bar 18 BOF" sessions, to acknowledge that some of them may eventually lead 19 to a proposal for an official IETF BOF ("birds of a feather" session) 20 on a given topic. 22 During recent IETF meetings, many such "bar BOF" get-togethers have 23 been organized and moderated in ways that made them increasingly 24 indistinguishable from official IETF BOFs or sometimes even IETF 25 working group meetings. 27 This document argues that this recent trend is not helpful in 28 reaching the ultimate goal of many of these get-togethers, i.e., to 29 efficiently discuss and develop ideas for new IETF work. It 30 encourages the organizers to consider the benefits of holding them in 31 much less formal settings, and to also consider alternative means to 32 develop their ideas. This document also recommends that the 33 community abandon the term "bar BOF" and instead use other terms such 34 "side meeting", in order to stress the unofficial nature of these 35 get-togethers. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 4, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 1. Introduction 71 A typical IETF meeting is full of sessions of different kinds. In 72 addition to official IETF and IRTF sessions listed in the meeting 73 agenda, such as working and research group meetings, area meetings or 74 plenaries, many other unofficial meetings take place. These include 75 meetings between IETF participants from one organization or company, 76 design team meetings, Internet-Draft editing sessions, 77 interoperability testing, directorate lunches and many others. 79 Some of these unofficial get-togethers are organized by individual 80 participants with a common interest in initiating new IETF work of 81 some kind. New IETF work often fits into an existing working group 82 and does not require an official "birds of a feather" (BOF) session 83 [RFC5434] to determine community consensus. Nevertheless, the phrase 84 "bar BOF" has commonly been used in the community when talking about 85 such informal get-togethers that are held to discuss potential new 86 work. [RFC4677] characterizes a "bar BOF" as 88 "(...) an unofficial get-together, usually in the late evening, 89 during which a lot of work gets done over drinks. Bar BOFs spring 90 up in many different places around an IETF meeting, such as 91 restaurants, coffee shops, and (if we are so lucky) pools." 93 During recent IETF meetings, "bar BOFs" have become increasingly 94 indistinguishable from official IETF BOFs or sometimes even IETF 95 working group meetings. The symptoms of this trend are unofficial 96 "bar BOFs" that are held in regular IETF meeting rooms with 97 classroom-style seating, agendas with lengthy slide presentations, 98 use of microphone lines, and even formal consensus calls. And, 99 perhaps most importantly, a distinct lack of drinks.) 101 This document argues that this trend is not helpful in reaching the 102 ultimate goal of many of these get-togethers, i.e., to brainstorm 103 about a technical topic that may eventually lead to new IETF work. 104 It encourages the organizers of these unofficial get-togethers to 105 consider the benefits of holding them in much less formal settings. 107 This document also recommends that the community abandon the term 108 "bar BOF". The distinction between a BOF, i.e., an official IETF 109 activity, and a "bar BOF", i.e., an unofficial get-together, is lost 110 on many IETF participants, especially newcomers. The similarity in 111 terms has even caused confusion to the point where some participants 112 believe that a "bar BOF" is a required step in the IETF process in 113 order to apply for an official BOF, which is obviously false. For 114 these reasons, the remainder of this document will use the term "side 115 meeting" instead, and it recommends that the community do the same, 116 in order to stress the unofficial nature of these get-togethers. 118 Before going into more detailed advice on how to hold side meetings, 119 it is important to remember that many participants are extremely busy 120 during an IETF meeting. Although having a side meeting to discuss an 121 idea in an informal face-to-face setting is attractive, the 122 scheduling of such meetings is very difficult and needs to happen 123 weeks if not months prior to the meeting itself. Conference calls, 124 email discussions, wikis, jabber group chats and other ways for 125 interacting are also effective at developing ideas, and easier to 126 schedule. 128 2. How to Invite 130 A good rule of thumb is that a side meeting to discuss and develop a 131 proposal for new IETF work should include the necessary participants 132 to achieve that purpose, and no more. Smaller meetings are usually 133 more successful than larger meetings. 135 Hence, it is often useful to limit attendance carefully. Publicly 136 broadcasting an announcement for a side meeting on a particular 137 topic, e.g., on an IETF mailing list, is therefore not usually a good 138 method of inviting the desired set of participants. 140 One reason is that if the announcement happens to attract a large 141 response, the logistics of organizing a side meeting for a larger 142 group quickly becomes very difficult. Small groups fit comfortably 143 around a table at a bar or a restaurant, or can find a quiet corner 144 in an IETF hallway for a discussion. Larger groups require dedicated 145 meeting facilities, which are limited during IETF meetings, and they 146 generally require much more careful planning in order to get work 147 done. 149 When publicly announcing a side meeting, it is often not even 150 possible for the organizers to determine how large the resulting get- 151 together will be, forcing them to over-provision for the "best case" 152 of a substantial attendance, even in cases where this turns out to be 153 not necessary. And even when a large group comes together, it often 154 mostly consists of "tourists". Tourists usually do not actively 155 participate in the get-together at all, or they participate with an 156 intent to learn about a topic, which can derail a planned discussion 157 of specific issues and turn it into a tutorial. The attendance of 158 tourists requires finding a larger room and makes the interactions 159 between the active participants more cumbersome, e.g., because 160 microphones need to be used in larger rooms. There are times to 161 expose new ideas to a broader community, but think carefully before 162 publicly announcing a side meeting. 164 So while publicly announcing a side meeting can be useful in order to 165 gather interested people for a discussion, it often makes sense to 166 still limit attendance. For example, an announcement could say "we 167 have a table reserved at restaurant X for Y people, if you are 168 interested in attending, please briefly explain how you will 169 contribute to the discussion we are planning on having." And if more 170 than Y people respond, the organizers make a selection. 172 Selecting or specifically inviting IESG or IAB members is not 173 necessary and may not even be advisable in many cases. Some ideas 174 need time to form before they result in anything cohesive, and a side 175 meeting is a good time to develop new ideas. It is usually most 176 useful to approach ADs and IAB members for comments after a ideas has 177 solidified enough so that an elevator pitch can be given. Also, it 178 should be clear that if an AD or IAB member attends a side meeting, 179 it is not necessarily a show of support. They may simply be 180 interested, or often may be concerned or troubled with some aspect of 181 the potential work and relation to existing work. On the other hand, 182 when an AD or IAB member declines to attend a side meeting, that is 183 usually not a sign of disinterest or disapproval - these people have 184 busy schedules, especially during an IETF week. 186 In the initial stages of developing a proposal for new IETF work, the 187 ability for interested and experienced participants to brainstorm is 188 tremendously important. Brainstorming is facilitated by direct, 189 interactive, and high-bandwidth discussions. This is clearly much 190 more easily achieved in a smaller setting, where half-baked ideas can 191 be dissected and developed. This is often not possible in a larger 192 group. Even worse, a badly run large meeting can sometimes "poison 193 the waters" for a proposed idea by convincing the broader community 194 that the proposal is confused, not ready or otherwise uninteresting. 196 Another reason to discuss new work proposals in smaller groups is 197 scope creep, i.e., the tendency of an initially rather tightly scoped 198 area of new work to expand, because people will argue that whatever 199 the initial topic was, it should be expanded to include their 200 particular item of interest. This is harder to control in larger 201 groups. Keeping the scope of new work items narrow is important, 202 because eventual chartering decisions are often much mode difficult 203 for larger items of new work than for smaller ones. 205 It is important to understand that in the IETF, proposals for new 206 work are judged based on their technical merits and on whether there 207 is enough energy and interest in the community to complete the work 208 in a timely manner. This happens in the relevant working group, if 209 one exists, or else during an official BOF session. How many warm 210 bodies fill a room during an unofficial side meeting has no influence 211 on this decision, and is not a good metric for reporting interest in 212 a topic to the community or to employers. Discussions about new work 213 are often controversial, and people will show up just to watch the 214 fireworks, or learn about a new topic, or make sure the new work does 215 not interfere with work they are already pursuing, without being 216 interested contributing in some way to the the actual proposal 217 itself. 219 Some side meetings are organized to discuss a topic that is also 220 being discussed in an existing working group, either before or after 221 the working group itself meets. Some working groups call these side 222 meetings "ad-hoc sessions". The fact that a side meeting is 223 organized by a chair or key participant of a working group in order 224 to discuss topics related to the working group does not make it any 225 more official than other side meetings. An "ad hoc session" is not 226 an official working group session and no decisions relevant to a 227 working group can be made. Working group consensus can only be 228 established during official sessions or on the mailing list 229 [RFC2418]. 231 3. Where to Meet 233 As the colloquial name "bar BOF" implied, such side meetings are 234 traditionally held in bars or restaurants. Recently, there has been 235 a distinct shift towards holding such get-togethers in regular IETF 236 meeting rooms. One reason for this trend has been discussed in 237 Section 2; namely, that an uncontrolled broadcast announcement 238 requires over-provisioning of facilities. 240 A second reason for this trend is that some participants, e.g., non- 241 native English speakers or participants with hearing difficulties, 242 find it difficult to interact or follow a discussion in noisy 243 environments, such as restaurants and especially bars. The 244 organizers of side meetings are encouraged to take this factor into 245 consideration when finding a meeting place. Quiet restaurants are 246 not hard to find, and many offer private dining rooms at no extra 247 charge for larger parties. 249 A likely third reason why side meetings are increasingly held in IETF 250 rooms is that the booking of such a room currently requires approval 251 by an Area Director. The reason for this practice is simply to make 252 sure that IETF-paid rooms are used for meetings that are in the 253 widest sense IETF-related. However, the approval of a room request 254 for a side meeting has been known to sometimes be reported as Area 255 Director "support" for the topic of the meeting to the community or 256 to employers. No such support is expressed or implied when Area 257 Directors approve room requests! Many routinely say "yes" to every 258 incoming request as long as there are meeting rooms available (and 259 there are typically lots of meeting rooms available outside of normal 260 working group meeting slots). 262 Holding side meetings in IETF meeting rooms does not make them any 263 more official or valid than get-togethers that happen in other 264 places. Participants have recently begun to list the times and 265 locations of some side meetings on a wiki page, but that does not 266 make them part of the official IETF agenda or otherwise changes their 267 unofficial status. 269 IETF meeting rooms clearly do not provide the most supportive 270 environment for side meetings that require brainstorming on a new 271 technical proposal. One reason is that the classroom-style seating 272 often present in IETF meeting rooms tends to spread people out in 273 rows, all facing towards a front presenter: good for presentations, 274 bad for discussion. Because IETF meeting rooms tend to be large, and 275 people have a natural tendency to spread out, holding a meeting in 276 one often requires microphone use, which is cumbersome, slows a 277 discussion down, and leads to "question-answer" dialogs between two 278 people, which is much less effective than a group discussion around a 279 restaurant table. 281 Another reason is more pragmatic. Because the organizers of 282 unofficial get-togethers can only use IETF meeting rooms during times 283 when they are not otherwise in use, such side meetings often happen 284 during breakfast, lunch, dinner or later in the evening. This 285 prolongs the time during which IETF participants are stuck in the 286 same rooms they're stuck in for the rest of the day, and it prevents 287 them from having a regular and at least somewhat relaxed meal. 288 Anecdotal evidence exists that at least one Area Director has not 289 been able to set foot outside the IETF hotel for a stretch of several 290 days during IETF-77. (IETF-77 was held in Anaheim, CA, and the food 291 options in and near the hotel were, let's say, of severely limited 292 quality.) It is unlikely that participants in the consequential 293 mental and bodily state will make productive contributions to a side 294 meeting or, in the case of Area Directors, will be extremely 295 receptive towards new work proposals. 297 Food, drink and a relaxed atmosphere in which to have a discussion 298 are an essential part of a successful side meeting, because they 299 often need to happen during meal times. IETF meeting rooms offer 300 neither. 302 4. How to Meet 304 Several of the recent side meetings that were held in IETF meeting 305 rooms emulated official IETF meetings to a degree that made them 306 indistinguishable from a regular working group meeting for the 307 average IETF attendee. This included detailed agendas, lengthy 308 presentations, organizers who refer to themselves as "bar BOF 309 chairs", emulating blue sheets (see Section 4.5 of [RFC4677]), and 310 even hums and other consensus calls (see Section 5.2 of [RFC4677]). 312 It is not clear as to why this has been happening. One attempt at an 313 explanation may be that holding a get-together in an IETF room and 314 having the organizers behave like chairs behave during regular IETF 315 sessions is causing a Pavlovian stimulus in the attendees. Another 316 explanation attempt is that an IETF meeting room simply does not 317 allow many other forms of discussion. Finally, some organizers may 318 find the process to apply for an official BOF too complex or 319 troublesome (and probably rightfully so), and so decide to simply 320 mimic one, or they had applied for an official BOF, got turned down, 321 and then decided to hold the same meeting as a side meeting. 323 Whatever the reason for this development is, it is reasonably obvious 324 that running a side meeting with a focus on making quick progress on 325 a technical proposal in a way that emulates running a working group 326 session is not very productive. Working group sessions follow 327 certain procedures due to larger audiences, the need to establish 328 formal consensus, etc. that a side meeting can do without. 330 Having side meetings mimic working group meetings is also confusing 331 to attendees. There is at least one case where some side meeting 332 participants believed that they were attending an actual working 333 group meeting, and incorrect press announcements were generated as a 334 consequence. The IESG is usually not amused when mistakes like this 335 happen. When side meetings take place at restaurants or elsewhere 336 away from IETF meeting rooms, the chance for confusion is much lower. 338 Because the reasons for organizing such a get-together are diverse, 339 this section is not making more specific suggestions, other than to 340 note that meeting outside of an IETF meeting room is likely going to 341 shift the dynamics sufficiently so that better interactions and 342 results become possible. 344 5. When to Meet 346 Side meetings are often scheduled following IETF evening plenaries, 347 which sometimes end before the time indicated on the meeting agenda, 348 but have in the past also ended much later. It is therefore useful 349 to avoid scheduling side meetings that follow IETF plenaries at a 350 fixed time. Instead, it is recommended to schedule them relative to 351 the end of the plenary, i.e., "X minutes after the end of the 352 plenary." That way, attendees do not need to wait around if a 353 plenary finishes early, and do not need to leave a plenary should it 354 run late. 356 Section 3 of [RFC5434] raises the issue that it is essential to 357 understand all angles of a given problem for which IETF work is 358 proposed. This means that input from the community that can be found 359 at IETF meetings is not the only one that should be considered. It 360 can be argued that input from other communities - operator, research, 361 regulatory, etc. - is at least as important. Hence, organizers 362 should consider the value of also holding side meetings at venues 363 where such input can be more easily gathered, such as operator fora 364 (RIPE, NANOG, etc.), research conferences or other events. 366 6. Conclusions 368 Side meeting organizers are encouraged to rekindle the original 369 spirit behind them and organize them outside IETF meeting rooms, at 370 venues with food and drink, for smaller groups and in a way that does 371 not needlessly mimic the way official IETF sessions are conducted. 373 It can often be useful to discuss proposals for new IETF work face- 374 to-face in an informal setting, but conference calls, email 375 discussions, wikis and other means for interactions are also 376 effective at developing ideas, especially given the scheduling 377 difficulties when busy individuals are involved during an IETF 378 meeting. 380 Finally, it is important to remember that all side meetings during an 381 IETF week are purely informal and have no official status whatsoever. 383 7. IANA Considerations 385 This document raises no IANA considerations. 387 [Note to the RFC Editor: Please remove this section upon 388 publication.] 390 8. Security Considerations 392 A security AD pointed out that people have been known to forget their 393 laptops after side meetings held in real bars. The organizers of 394 side meetings should therefore remind any attending security ADs (and 395 possibly others) to take their belongings with them after the side 396 meeting ends or the bar closes, whichever happens first. 398 9. Acknowledgments 400 The name and title of this document have been chosen to resemble 401 those used by Thomas Narten for his guidelines document on holding a 402 successful BOF [RFC5434], as a sign of appreciation for a document 403 that has proven to be invaluable many times over. 405 Several folks provided feedback and input on this document, including 406 Jari Arkko, Fred Baker, Scott Bradner, Ben Campbell, Jorge Contreras, 407 Spencer Dawkins, Ralph Droms, Wesley Eddy, Frank Ellermann, Adrian 408 Farrel, Stephen Farrell, David Harrington, Russ Housley, Cullen 409 Jennings, John Klensin, Al Morton, Robert Sparks and Dan Wing. 411 Lars Eggert was partly funded by [TRILOGY], a research project 412 supported by the European Commission under its Seventh Framework 413 Program. 415 10. Informative References 417 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 418 Procedures", BCP 25, RFC 2418, September 1998. 420 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 421 Guide to the Internet Engineering Task Force", RFC 4677, 422 September 2006. 424 [RFC5434] Narten, T., "Considerations for Having a Successful Birds- 425 of-a-Feather (BOF) Session", RFC 5434, February 2009. 427 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 429 Authors' Addresses 431 Lars Eggert 432 NetApp 433 Sonnenallee 1 434 Kirchheim 85551 435 Germany 437 Phone: +49 151 12055791 438 Email: lars@netapp.com 439 URI: http://eggert.org/ 441 Gonzalo Camarillo 442 Ericsson 443 Hirsalantie 11 444 Jorvas 02420 445 Finland 447 Email: Gonzalo.Camarillo@ericsson.com