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