idnits 2.17.1 draft-eggert-successful-bar-bof-05.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 (May 27, 2011) is 4718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) Summary: 0 errors (**), 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 G. Camarillo 5 Expires: November 28, 2011 Ericsson 6 May 27, 2011 8 Considerations for Having a Successful "Bar BOF" Side Meeting 9 draft-eggert-successful-bar-bof-05 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 November 28, 2011. 54 Copyright Notice 56 Copyright (c) 2011 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, ISOC sessions, 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 to determine community consensus. Nevertheless, the phrase "bar BOF" 84 has commonly been used in the community when talking about such 85 informal get-togethers that are held to discuss potential new work. 86 [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. For that reason, 111 the remainder of this document will use the term "side meeting" 112 instead. 114 Before going into more detailed advice on how to hold side meetings, 115 it is important to remember that many participants are extremely busy 116 during an IETF meeting. Although having a side meeting to discuss an 117 idea in an informal face-to-face setting is attractive, the 118 scheduling of such meetings is therefore very difficult and needs to 119 happen weeks if not months prior to the meeting itself. Conference 120 calls, email discussions, wikis and other ways for interacting are 121 also effective at developing ideas, and easier to schedule. 123 2. How to Invite 125 A good rule of thumb is that a side meeting to discuss and develop a 126 proposal for new IETF work should include the necessary participants 127 to achieve that purpose, and no more. Smaller meetings are usually 128 more successful than larger meetings. 130 Hence, it is often useful to limit attendance carefully. Publicly 131 broadcasting an announcement for a side meeting on a particular 132 topic, e.g., on an IETF mailing list, is therefore not usually a good 133 method of inviting the desired set of participants. 135 One reason is that if the announcement happens to attract a large 136 response, the logistics of organizing a side meeting for a larger 137 group quickly becomes very difficult. Small groups fit comfortably 138 around a table at a bar or a restaurant, or can find a quiet corner 139 in an IETF hallway for a discussion. Larger groups require dedicated 140 meeting facilities, which are limited during IETF meetings, and they 141 generally require much more careful planning in order to get work 142 done. 144 When publicly announcing a side meeting, it is often not even 145 possible for the organizers to determine how large the resulting get- 146 together will be, forcing them to over-provision for the "best" case 147 of a substantial attendance, even in cases where this turns out to be 148 not necessary. And even when a large group comes together, it often 149 mostly consists of "tourists" who do not actively participate in the 150 get-together but whose attendance requires finding a larger room and 151 makes the interactions between the active participants more 152 cumbersome, e.g., because microphones need to be used in larger 153 rooms. 155 In the initial stages of developing a proposal for new IETF work, the 156 ability to brainstorm, i.e., to have direct, interactive and high- 157 bandwidth discussions between participants interested and experienced 158 in the topic area, is tremendously important. This is clearly much 159 more easily achieved in a smaller setting, where half-baked ideas can 160 be dissected and developed. This is often not possible in a larger 161 group. Even worse, a badly run large meeting can sometimes "poison 162 the waters" for a proposed idea by convincing the broader community 163 that the proposal is confused, not ready or otherwise uninteresting. 165 It is important to understand that in the IETF, proposals for new 166 work are judged based on their technical merits and on whether there 167 is enough energy and interest in the community to complete the work 168 in a timely manner. This happens in the relevant working group, if 169 one exists, or else during an official BOF session. How many warm 170 bodies fill a room during an unofficial side meeting has no influence 171 on this decision, and is not a good metric for reporting interest in 172 a topic to the community or to employers. Discussions about new work 173 are often controversial, and people will show up just to watch the 174 fireworks, without being interested in the actual proposal itself. 176 Some side meetings are organized to discuss a topic that is also 177 being discussed in an existing working group, either before or after 178 the working group itself meets. Some working groups call these side 179 meetings "ad-hoc sessions". The fact that a side meeting is 180 organized by a chair or key participant of a working group in order 181 to discuss topics related to the working group does not make it any 182 more official than other side meetings. An "ad hoc session" is not 183 an official working group session and no decisions relevant to a 184 working group can be made. Working group consensus can only be 185 established during official sessions or on the mailing list 186 [RFC2418]. 188 3. Where to Meet 190 As the colloquial name "bar BOF" implied, such side meetings are 191 traditionally held in bars or restaurants. Recently, there has been 192 a distinct shift towards holding such get-togethers in regular IETF 193 meeting rooms. One reason for this trend has been discussed in 194 Section 2; namely, that an uncontrolled broadcast announcement 195 requires over-provisioning of facilities. 197 A second reason for this trend is that some participants, e.g., non- 198 native English speakers or participants with hearing difficulties, 199 find it difficult to interact or follow a discussion in noisy 200 environments, such as restaurants and especially bars. The 201 organizers of side meetings are encouraged to take this factor into 202 consideration when finding a meeting place. Quiet restaurants are 203 not hard to find, and many offer private dining rooms at no extra 204 charge for larger parties. 206 A likely third reason why side meetings are increasingly held in IETF 207 rooms is that the booking of such a room currently requires approval 208 by an Area Director. The reason for this practice is simply to make 209 sure that IETF-paid rooms are used for meetings that are in the 210 widest sense IETF-related. However, the approval of a room request 211 for a side meeting has been known to sometimes be reported as Area 212 Director "support" for the topic of the meeting to the community or 213 to employers. No such support is expressed or implied when Area 214 Directors approve room requests! Many routinely say "yes" to every 215 incoming request as long as there are meeting rooms available (and 216 there are typically lots of meeting rooms available). 218 Holding side meetings in IETF meeting rooms does not make them any 219 more official or valid than get-togethers that happen in other 220 places. Participants have recently begun to list the times and 221 locations of some side meetings on a wiki page, but that does not 222 make them part of the official IETF agenda or otherwise changes their 223 unofficial status. 225 IETF meeting rooms clearly do not provide the most supportive 226 environment for side meetings that require brainstorming on a new 227 technical proposal. One reason is that the classroom-style seating 228 often present in IETF meeting rooms tends to spread people out in 229 rows, all facing towards a front presenter: good for presentations, 230 bad for discussion. Because IETF meeting rooms tend to be large, and 231 people have a natural tendency to spread out, holding a meeting in 232 one often requires microphone use, which is cumbersome, slows a 233 discussion down, and leads to "question-answer" dialogs between two 234 people, which is much more ineffective than a group discussion around 235 a restaurant table. 237 Another reason is more pragmatic. Because the organizers of 238 unofficial get-togethers can only use IETF meeting rooms during times 239 when they are not otherwise in use, such side meetings often happen 240 during breakfast, lunch, dinner or later in the evening. This 241 prolongs the time during which IETF participants are stuck in the 242 same rooms they're stuck in for the rest of the day, and it prevents 243 them from having a regular and at least somewhat relaxed meal. 244 Anecdotal evidence exists that at least one Area Director has not 245 been able to set foot outside the IETF hotel for a stretch of several 246 days during IETF-77. (IETF-77 was held in Anaheim, CA, and the food 247 options in and near the hotel were, let's say, of severely limited 248 quality.) It is unlikely that participants in the consequential 249 mental and bodily state will make productive contributions to a side 250 meeting or, in the case of Area Directors, will be extremely 251 receptive towards new work proposals. 253 Food, drink and a relaxed atmosphere in which to have a discussion 254 are an essential part of a successful side meeting, because they 255 often need to happen during meal times. IETF meeting rooms offer 256 neither. 258 4. How to Meet 260 Several of the recent side meetings that were held in IETF meeting 261 rooms emulated official IETF meetings to a degree that made them 262 indistinguishable from a regular working group meeting for the 263 average IETF attendee. This included detailed agendas, lengthy 264 presentations, organizers who refer to themselves as "bar BOF 265 chairs", emulating blue sheets (see Section 4.5 of [RFC4677]), and 266 even hums and other consensus calls (see Section 5.2 of [RFC4677]). 268 It is not clear as to why this has been happening. One attempt at an 269 explanation may be that holding a get-together in an IETF room and 270 having the organizers behave like chairs behave during regular IETF 271 sessions is causing a Pavlovian stimulus in the attendees. Another 272 explanation attempt is that an IETF meeting room simply doesn't allow 273 many other forms of discussion. Finally, some organizers may find 274 the process to apply for an official BOF to complex, and so decide to 275 simply mimic one. 277 Whatever the reason for this development is, it is reasonably obvious 278 that running a side meeting with a focus on making quick progress on 279 a technical proposal in a way that emulates running a working group 280 session is not very productive. Working group sessions follow a 281 certain procedures due to larger audiences, the need to establish 282 formal consensus, etc. that a side meeting can do without. 284 Because the reasons for organizing such a get-together are diverse, 285 this section is not making more specific suggestions, other than to 286 note that meeting outside of an IETF meeting room is likely going to 287 shift the dynamics sufficiently so that better interactions and 288 results become possible. 290 5. When to Meet 292 Side meetings are often scheduled following IETF evening plenaries, 293 which frequently end before the time indicated on the meeting agenda, 294 but can also end later. It is therefore useful to avoid scheduling 295 side meetings that follow IETF plenaries at a fixed time. Instead, 296 it is recommended to schedule them relative to the end of the 297 plenary, i.e., "X minutes after the end of the plenary." That way, 298 attendees do not need to wait around if a plenary finishes early, and 299 do not need to leave a plenary should it run late. 301 6. Applicability of IPR Rules 303 The IETF's rules regarding intellectual property are set out in BCP78 304 [RFC5378] and BCP79[RFC3979]. Among other things, these rules 305 provide that any "Contribution" to the "IETF Standards Process" (each 306 as defined in the rules themselves) is licensed to the IETF Trust for 307 the IETF's use in developing standards, and also requires disclosure 308 of related patents and patent applications. 310 A "Contribution" is "any submission to the IETF intended by the 311 Contributor for publication as all or part of an Internet-Draft or 312 RFC and any statement made within the context of an IETF activity". 314 Thus, the fact that a Contribution is made at one of the bar BOFs or 315 other "unofficial" or "semi-official" events described in this 316 document does not change or limit the applicability of the IETF's IPR 317 rules. If you have a question regarding the applicability of the 318 IETF IPR rules in any specific context or to any specific activity, 319 you should consult your attorney or make an inquiry to the IESG. 321 Informally, the above makes it appropriate, in order to provide a 322 pointer to the relevant policies, to announce the "Note Well" text 323 [NOTEWELL] in all such meetings. 325 7. Conclusions 327 Side meeting organizers are encouraged to rekindle the original 328 spirit behind them and organize them outside IETF meeting rooms, at 329 venues with food and drink, for smaller groups and in a way that does 330 not needlessly mimic the way official IETF sessions are conducted. 332 It can often be useful to discuss proposals for new IETF work face- 333 to-face in an informal setting, but conference calls, email 334 discussions, wikis and other means for interactions are also 335 effective at developing ideas, especially given the scheduling 336 difficulties when busy individuals are involved during an IETF 337 meeting. 339 Finally, it is important to remember that all side meetings during an 340 IETF week are purely informal and have no official status whatsoever. 342 8. IANA Considerations 344 This document raises no IANA considerations. 346 [Note to the RFC Editor: Please remove this section upon 347 publication.] 349 9. Security Considerations 351 This document has no known security implications. 353 [Note to the RFC Editor: Please remove this section upon 354 publication.] 356 10. Acknowledgments 358 The name and title of this document have been chosen to resemble 359 those used by Thomas Narten for his guidelines document on holding a 360 successful BOF [RFC5434], as a sign of appreciation for a document 361 that has proven to be invaluable many times over. 363 Several folks provided feedback and input on this document, including 364 Fred Baker, Scott Bradner, Jorge Contreras, Spencer Dawkins, Frank 365 Ellermann, Adrian Farrel, David Harrington, Russ Housley, Cullen 366 Jennings, John Klensin and Dan Wing. 368 Lars Eggert is partly funded by [TRILOGY], a research project 369 supported by the European Commission under its Seventh Framework 370 Program. 372 11. Informative References 374 [NOTEWELL] 375 "Note Well", http://www.ietf.org/about/note-well.html. 377 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 378 Procedures", BCP 25, RFC 2418, September 1998. 380 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 381 Technology", BCP 79, RFC 3979, March 2005. 383 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 384 Guide to the Internet Engineering Task Force", RFC 4677, 385 September 2006. 387 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 388 to the IETF Trust", BCP 78, RFC 5378, November 2008. 390 [RFC5434] Narten, T., "Considerations for Having a Successful Birds- 391 of-a-Feather (BOF) Session", RFC 5434, February 2009. 393 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 395 Authors' Addresses 397 Lars Eggert 398 Nokia Research Center 399 P.O. Box 407 400 Nokia Group 00045 401 Finland 403 Phone: +358 50 48 24461 404 Email: lars.eggert@nokia.com 405 URI: http://research.nokia.com/people/lars_eggert 407 Gonzalo Camarillo 408 Ericsson 409 Hirsalantie 11 410 Jorvas 02420 411 Finland 413 Email: Gonzalo.Camarillo@ericsson.com