idnits 2.17.1 draft-eggert-successful-bar-bof-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (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 3, 2011) is 4793 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 (==), 4 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: September 4, 2011 Ericsson 6 March 3, 2011 8 Considerations for Having a Successful "Bar BOF" Side Meeting 9 draft-eggert-successful-bar-bof-02 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. This document may not be modified, 41 and derivative works of it may not be created, and it may not be 42 published except as an Internet-Draft. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 4, 2011. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 1. Introduction 73 A typical IETF meeting is full of sessions of different kinds. In 74 addition to official IETF and IRTF sessions listed in the meeting 75 agenda, such as working and research group meetings, area meetings or 76 plenaries, many other unofficial meetings take place. These include 77 meetings between IETF participants from one organization or company, 78 design team meetings, ISOC sessions, Internet-Draft editing sessions, 79 interoperability testing, directorate lunches and many others. 81 Some of these unofficial get-togethers are organized by individual 82 participants with a common interest in initiating new IETF work of 83 some kind. New IETF work often fits into an existing working group 84 and does not require an official "birds of a feather" (BOF) session 85 to determine community consensus. Nevertheless, the phrase "bar BOF" 86 has commonly been used in the community when talking about such 87 informal get-togethers that are held to discuss potential new work. 88 [RFC4677] characterizes a "bar BOF" as 90 "(...) an unofficial get-together, usually in the late evening, 91 during which a lot of work gets done over drinks. Bar BOFs spring 92 up in many different places around an IETF meeting, such as 93 restaurants, coffee shops, and (if we are so lucky) pools." 95 During recent IETF meetings, "bar BOFs" have become increasingly 96 indistinguishable from official IETF BOFs or sometimes even IETF 97 working group meetings. The symptoms of this trend are unofficial 98 "bar BOFs" that are held in regular IETF meeting rooms with 99 classroom-style seating, agendas with lengthy slide presentations, 100 use of microphone lines, and even formal consensus calls. And, 101 perhaps most importantly, a distinct lack of drinks. 103 This document argues that this trend is not helpful in reaching the 104 ultimate goal of many of these get-togethers, i.e., to brainstorm 105 about a technical topic that may eventually lead to new IETF work. 106 It encourages the organizers of these unofficial get-togethers to 107 consider the benefits of holding them in much less formal settings. 109 This document also recommends that the community abandon the term 110 "bar BOF". The distinction between a BOF, i.e., an official IETF 111 activity, and a "bar BOF", i.e., an unofficial get-together, is lost 112 on many IETF participants, especially newcomers. For that reason, 113 the remainder of this document will use the term "side meeting" 114 instead. 116 Before going into more detailed advice on how to hold side meetings, 117 it is important to remember that many participants are extremely busy 118 during an IETF meeting. Although having a side meeting to discuss an 119 idea in an informal face-to-face setting is attractive, the 120 scheduling of such meetings is therefore very difficult and needs to 121 happen weeks if not months prior to the meeting itself. Conference 122 calls, email discussions, wikis and other ways for interacting are 123 also effective at developing ideas, and easier to schedule. 125 2. How to Invite 127 A good rule of thumb is that a side meeting to discuss and develop a 128 proposal for new IETF work should include the necessary participants 129 to achieve that purpose, and no more. Smaller meetings are usually 130 more successful than larger meetings. 132 Hence, it is often useful to limit attendance carefully. Publicly 133 broadcasting an announcement for a side meeting on a particular 134 topic, e.g., on an IETF mailing list, is therefore not usually a good 135 method of inviting the desired set of participants. 137 One reason is that if the announcement happens to attract a large 138 response, the logistics of organizing a side meeting for a larger 139 group quickly becomes very difficult. Small groups fit comfortably 140 around a table at a bar or a restaurant, or can find a quiet corner 141 in an IETF hallway for a discussion. Larger groups require dedicated 142 meeting facilities, which are limited during IETF meetings, and they 143 generally require much more careful planning in order to get work 144 done. 146 When publicly announcing a side meeting, it is often not even 147 possible for the organizers to determine how large the resulting get- 148 together will be, forcing them to over-provision for the "best" case 149 of a substantial attendance, even in cases where this turns out to be 150 not necessary. And even when a large group comes together, it often 151 mostly consists of "tourists" who do not actively participate in the 152 get-together but whose attendance requires finding a larger room and 153 makes the interactions between the active participants more 154 cumbersome, e.g., because microphones need to be used in larger 155 rooms. 157 In the initial stages of developing a proposal for new IETF work, the 158 ability to brainstorm, i.e., to have direct, interactive and high- 159 bandwidth discussions between participants interested and experienced 160 in the topic area, is tremendously important. This is clearly much 161 more easily achieved in a smaller setting, where half-baked ideas can 162 be dissected and developed. This is often not possible in a larger 163 group. Even worse, a badly run large meeting can sometimes "poison 164 the waters" for a proposed idea by convincing the broader community 165 that the proposal is confused, not ready or otherwise uninteresting. 167 It is important to understand that in the IETF, proposals for new 168 work are judged based on their technical merits and on whether there 169 is enough energy and interest in the community to complete the work 170 in a timely manner. This happens in the relevant working group, if 171 one exists, or else during an official BOF session. How many warm 172 bodies fill a room during an unofficial side meeting has no influence 173 on this decision, and is not a good metric for reporting interest in 174 a topic to the community or to employers. Discussions about new work 175 are often controversial, and people will show up just to watch the 176 fireworks, without being interested in the actual proposal itself. 178 Some side meetings are organized to discuss a topic that is also 179 being discussed in an existing working group, either before or after 180 the working group itself meets. Some working groups call these side 181 meetings "ad-hoc sessions". The fact that a side meeting is 182 organized by a chair or key participant of a working group in order 183 to discuss topics related to the working group does not make it any 184 more official than other side meetings. An "ad hoc session" is not 185 an official working group session and no decisions relevant to a 186 working group can be made. Working group consensus can only be 187 established during official sessions or on the mailing list 188 [RFC2418]. 190 3. Where to Meet 192 As the colloquial name "bar BOF" implied, such side meetings are 193 traditionally held in bars or restaurants. Recently, there has been 194 a distinct shift towards holding such get-togethers in regular IETF 195 meeting rooms. One reason for this trend has been discussed in 196 Section 2; namely, that an uncontrolled broadcast announcement 197 requires over-provisioning of facilities. 199 A second reason for this trend is that some participants, e.g., non- 200 native English speakers or participants with hearing difficulties, 201 find it difficult to interact or follow a discussion in noisy 202 environments, such as restaurants and especially bars. The 203 organizers of side meetings are encouraged to take this factor into 204 consideration when finding a meeting place. Quiet restaurants are 205 not hard to find, and many offer private dining rooms at no extra 206 charge for larger parties. 208 A likely third reason why side meetings are increasingly held in IETF 209 rooms is that the booking of such a room currently requires approval 210 by an Area Director. The reason for this practice is simply to make 211 sure that IETF-paid rooms are used for meetings that are in the 212 widest sense IETF-related. However, the approval of a room request 213 for a side meeting has been known to sometimes be reported as Area 214 Director "support" for the topic of the meeting to the community or 215 to employers. No such support is expressed or implied when Area 216 Directors approve room requests! Many routinely say "yes" to every 217 incoming request as long as there are meeting rooms available (and 218 there are typically lots of meeting rooms available). 220 Holding side meetings in IETF meeting rooms does not make them any 221 more official or valid than get-togethers that happen in other 222 places. Participants have recently begun to list the times and 223 locations of some side meetings on a wiki page, but that does not 224 make them part of the official IETF agenda or otherwise changes their 225 unofficial status. 227 IETF meeting rooms clearly do not provide the most supportive 228 environment for side meetings that require brainstorming on a new 229 technical proposal. One reason is that the classroom-style seating 230 often present in IETF meeting rooms tends to spread people out in 231 rows, all facing towards a front presenter: good for presentations, 232 bad for discussion. Because IETF meeting rooms tend to be large, and 233 people have a natural tendency to spread out, holding a meeting in 234 one often requires microphone use, which is cumbersome, slows a 235 discussion down, and leads to "question-answer" dialogs between two 236 people, which is much more ineffective than a group discussion around 237 a restaurant table. 239 Another reason is more pragmatic. Because the organizers of 240 unofficial get-togethers can only use IETF meeting rooms during times 241 when they are not otherwise in use, such side meetings often happen 242 during breakfast, lunch, dinner or later in the evening. This 243 prolongs the time during which IETF participants are stuck in the 244 same rooms they're stuck in for the rest of the day, and it prevents 245 them from having a regular and at least somewhat relaxed meal. 246 Anecdotal evidence exists that at least one Area Director has not 247 been able to set foot outside the IETF hotel for a stretch of several 248 days during IETF-77. (IETF-77 was held in Anaheim, CA, and the food 249 options in and near the hotel were, let's say, of severely limited 250 quality.) It is unlikely that participants in the consequential 251 mental and bodily state will make productive contributions to a side 252 meeting or, in the case of Area Directors, will be extremely 253 receptive towards new work proposals. 255 Food, drink and a relaxed atmosphere in which to have a discussion 256 are an essential part of a successful side meeting, because they 257 often need to happen during meal times. IETF meeting rooms offer 258 neither. 260 4. How to Meet 262 Several of the recent side meetings that were held in IETF meeting 263 rooms emulated official IETF meetings to a degree that made them 264 indistinguishable from a regular working group meeting for the 265 average IETF attendee. This included detailed agendas, lengthy 266 presentations, organizers who refer to themselves as "bar BOF 267 chairs", emulating blue sheets, and even hums and other consensus 268 calls. 270 It is not clear as to why this has been happening. One attempt at an 271 explanation may be that holding a get-together in an IETF room and 272 having the organizers behave like chairs behave during regular IETF 273 sessions is causing a Pavlovian stimulus in the attendees. Another 274 explanation attempt is that an IETF meeting room simply doesn't allow 275 many other forms of discussion. 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, Adrian 365 Farrel, David Harrington, Russ Housley, Cullen Jennings, John Klensin 366 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