idnits 2.17.1 draft-eggert-successful-bar-bof-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 109: '...at the community MUST abandon the term...' RFC 2119 keyword, line 131: '... participant MUST purchase a beverag...' RFC 2119 keyword, line 132: '...ribution. It is RECOMMENDED that the ...' RFC 2119 keyword, line 137: '...ess participants SHOULD therefore over...' RFC 2119 keyword, line 141: '... RECOMMENDED as a general strategy....' (1 more instance...) -- The draft header indicates that this document updates RFC2026, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1, 2011) is 4773 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: 1 error (**), 0 flaws (~~), 1 warning (==), 6 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 Updates: 2026 (if approved) G. Camarillo 5 Intended status: Informational Ericsson 6 Expires: October 3, 2011 April 1, 2011 8 Considerations for Having a Successful "Bar BOF" Side Meeting 9 draft-eggert-successful-bar-bof-03 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 requires that the community 33 abandon the term "bar BOF" and instead use other terms such "side 34 meeting", in order to stress the unofficial nature of these get- 35 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 October 3, 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 requires that the community MUST 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. See Section 2 for the related IETF process modifications. 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. IETF Process Modification 127 [RFC2026] specifies the Internet Standards Process. This document 128 updates the process described therein as follows: Whenever an IETF 129 participant is observed to have used the term "bar BOF" in a 130 contribution that is covered by the IETF Note Well [NOTEWELL], said 131 participant MUST purchase a beverage for all participants that were 132 privy to the contribution. It is RECOMMENDED that the beverage be 133 alcoholic. 135 Oral contributions in IETF sessions that involve the term "bar BOF" 136 may result in a rather large fan-in of drink purchase requests. 137 Careless participants SHOULD therefore over-provision their drink 138 purchasing capabilities accordingly. Prioritization of drink 139 purchases for different affected participants is not strictly defined 140 by this document, but prioritization by alcohol content is 141 RECOMMENDED as a general strategy. 143 Contributions to the IETF, whether in oral or written form, are often 144 archived or recorded. Therefore, participants that use the term "bar 145 BOF" in contribution can affect other participants at a much later 146 time, e.g., when they come across the offending contribution while 147 perusing an email or chat room archive, or in an audio recording. 148 Participants MUST therefore be prepared to honor drink purchase 149 requests that arrive much later than the date of the actual 150 contribution, if proof can be produced. 152 Participants that are unable to understand when the Note Well 153 applies, i.e., whether they are under obligations to follow the 154 process outlined above, should be liberal in what they accept, and 155 therefore follow the process just in case. 157 3. How to Invite 159 A good rule of thumb is that a side meeting to discuss and develop a 160 proposal for new IETF work should include the necessary participants 161 to achieve that purpose, and no more. Smaller meetings are usually 162 more successful than larger meetings. 164 Hence, it is often useful to limit attendance carefully. Publicly 165 broadcasting an announcement for a side meeting on a particular 166 topic, e.g., on an IETF mailing list, is therefore not usually a good 167 method of inviting the desired set of participants. 169 One reason is that if the announcement happens to attract a large 170 response, the logistics of organizing a side meeting for a larger 171 group quickly becomes very difficult. Small groups fit comfortably 172 around a table at a bar or a restaurant, or can find a quiet corner 173 in an IETF hallway for a discussion. Larger groups require dedicated 174 meeting facilities, which are limited during IETF meetings, and they 175 generally require much more careful planning in order to get work 176 done. 178 When publicly announcing a side meeting, it is often not even 179 possible for the organizers to determine how large the resulting get- 180 together will be, forcing them to over-provision for the "best" case 181 of a substantial attendance, even in cases where this turns out to be 182 not necessary. And even when a large group comes together, it often 183 mostly consists of "tourists" who do not actively participate in the 184 get-together but whose attendance requires finding a larger room and 185 makes the interactions between the active participants more 186 cumbersome, e.g., because microphones need to be used in larger 187 rooms. 189 In the initial stages of developing a proposal for new IETF work, the 190 ability to brainstorm, i.e., to have direct, interactive and high- 191 bandwidth discussions between participants interested and experienced 192 in the topic area, is tremendously important. This is clearly much 193 more easily achieved in a smaller setting, where half-baked ideas can 194 be dissected and developed. This is often not possible in a larger 195 group. Even worse, a badly run large meeting can sometimes "poison 196 the waters" for a proposed idea by convincing the broader community 197 that the proposal is confused, not ready or otherwise uninteresting. 199 It is important to understand that in the IETF, proposals for new 200 work are judged based on their technical merits and on whether there 201 is enough energy and interest in the community to complete the work 202 in a timely manner. This happens in the relevant working group, if 203 one exists, or else during an official BOF session. How many warm 204 bodies fill a room during an unofficial side meeting has no influence 205 on this decision, and is not a good metric for reporting interest in 206 a topic to the community or to employers. Discussions about new work 207 are often controversial, and people will show up just to watch the 208 fireworks, without being interested in the actual proposal itself. 210 Some side meetings are organized to discuss a topic that is also 211 being discussed in an existing working group, either before or after 212 the working group itself meets. Some working groups call these side 213 meetings "ad-hoc sessions". The fact that a side meeting is 214 organized by a chair or key participant of a working group in order 215 to discuss topics related to the working group does not make it any 216 more official than other side meetings. An "ad hoc session" is not 217 an official working group session and no decisions relevant to a 218 working group can be made. Working group consensus can only be 219 established during official sessions or on the mailing list 220 [RFC2418]. 222 4. Where to Meet 224 As the colloquial name "bar BOF" implied, such side meetings are 225 traditionally held in bars or restaurants. Recently, there has been 226 a distinct shift towards holding such get-togethers in regular IETF 227 meeting rooms. One reason for this trend has been discussed in 228 Section 3; namely, that an uncontrolled broadcast announcement 229 requires over-provisioning of facilities. 231 A second reason for this trend is that some participants, e.g., non- 232 native English speakers or participants with hearing difficulties, 233 find it difficult to interact or follow a discussion in noisy 234 environments, such as restaurants and especially bars. The 235 organizers of side meetings are encouraged to take this factor into 236 consideration when finding a meeting place. Quiet restaurants are 237 not hard to find, and many offer private dining rooms at no extra 238 charge for larger parties. 240 A likely third reason why side meetings are increasingly held in IETF 241 rooms is that the booking of such a room currently requires approval 242 by an Area Director. The reason for this practice is simply to make 243 sure that IETF-paid rooms are used for meetings that are in the 244 widest sense IETF-related. However, the approval of a room request 245 for a side meeting has been known to sometimes be reported as Area 246 Director "support" for the topic of the meeting to the community or 247 to employers. No such support is expressed or implied when Area 248 Directors approve room requests! Many routinely say "yes" to every 249 incoming request as long as there are meeting rooms available (and 250 there are typically lots of meeting rooms available). 252 Holding side meetings in IETF meeting rooms does not make them any 253 more official or valid than get-togethers that happen in other 254 places. Participants have recently begun to list the times and 255 locations of some side meetings on a wiki page, but that does not 256 make them part of the official IETF agenda or otherwise changes their 257 unofficial status. 259 IETF meeting rooms clearly do not provide the most supportive 260 environment for side meetings that require brainstorming on a new 261 technical proposal. One reason is that the classroom-style seating 262 often present in IETF meeting rooms tends to spread people out in 263 rows, all facing towards a front presenter: good for presentations, 264 bad for discussion. Because IETF meeting rooms tend to be large, and 265 people have a natural tendency to spread out, holding a meeting in 266 one often requires microphone use, which is cumbersome, slows a 267 discussion down, and leads to "question-answer" dialogs between two 268 people, which is much more ineffective than a group discussion around 269 a restaurant table. 271 Another reason is more pragmatic. Because the organizers of 272 unofficial get-togethers can only use IETF meeting rooms during times 273 when they are not otherwise in use, such side meetings often happen 274 during breakfast, lunch, dinner or later in the evening. This 275 prolongs the time during which IETF participants are stuck in the 276 same rooms they're stuck in for the rest of the day, and it prevents 277 them from having a regular and at least somewhat relaxed meal. 278 Anecdotal evidence exists that at least one Area Director has not 279 been able to set foot outside the IETF hotel for a stretch of several 280 days during IETF-77. (IETF-77 was held in Anaheim, CA, and the food 281 options in and near the hotel were, let's say, of severely limited 282 quality.) It is unlikely that participants in the consequential 283 mental and bodily state will make productive contributions to a side 284 meeting or, in the case of Area Directors, will be extremely 285 receptive towards new work proposals. 287 Food, drink and a relaxed atmosphere in which to have a discussion 288 are an essential part of a successful side meeting, because they 289 often need to happen during meal times. IETF meeting rooms offer 290 neither. 292 5. How to Meet 294 Several of the recent side meetings that were held in IETF meeting 295 rooms emulated official IETF meetings to a degree that made them 296 indistinguishable from a regular working group meeting for the 297 average IETF attendee. This included detailed agendas, lengthy 298 presentations, organizers who refer to themselves as "bar BOF 299 chairs", emulating blue sheets (see Section 4.5 of [RFC4677]), and 300 even hums and other consensus calls (see Section 5.2 of [RFC4677]). 302 It is not clear as to why this has been happening. One attempt at an 303 explanation may be that holding a get-together in an IETF room and 304 having the organizers behave like chairs behave during regular IETF 305 sessions is causing a Pavlovian stimulus in the attendees. Another 306 explanation attempt is that an IETF meeting room simply doesn't allow 307 many other forms of discussion. Finally, some organizers may find 308 the process to apply for an official BOF to complex, and so decide to 309 simply mimic one. 311 Whatever the reason for this development is, it is reasonably obvious 312 that running a side meeting with a focus on making quick progress on 313 a technical proposal in a way that emulates running a working group 314 session is not very productive. Working group sessions follow a 315 certain procedures due to larger audiences, the need to establish 316 formal consensus, etc. that a side meeting can do without. 318 Because the reasons for organizing such a get-together are diverse, 319 this section is not making more specific suggestions, other than to 320 note that meeting outside of an IETF meeting room is likely going to 321 shift the dynamics sufficiently so that better interactions and 322 results become possible. 324 6. When to Meet 326 Side meetings are often scheduled following IETF evening plenaries, 327 which frequently end before the time indicated on the meeting agenda, 328 but can also end later. It is therefore useful to avoid scheduling 329 side meetings that follow IETF plenaries at a fixed time. Instead, 330 it is recommended to schedule them relative to the end of the 331 plenary, i.e., "X minutes after the end of the plenary." That way, 332 attendees do not need to wait around if a plenary finishes early, and 333 do not need to leave a plenary should it run late. 335 7. Applicability of IPR Rules 337 The IETF's rules regarding intellectual property are set out in BCP78 338 [RFC5378] and BCP79[RFC3979]. Among other things, these rules 339 provide that any "Contribution" to the "IETF Standards Process" (each 340 as defined in the rules themselves) is licensed to the IETF Trust for 341 the IETF's use in developing standards, and also requires disclosure 342 of related patents and patent applications. 344 A "Contribution" is "any submission to the IETF intended by the 345 Contributor for publication as all or part of an Internet-Draft or 346 RFC and any statement made within the context of an IETF activity". 348 Thus, the fact that a Contribution is made at one of the bar BOFs or 349 other "unofficial" or "semi-official" events described in this 350 document does not change or limit the applicability of the IETF's IPR 351 rules. If you have a question regarding the applicability of the 352 IETF IPR rules in any specific context or to any specific activity, 353 you should consult your attorney or make an inquiry to the IESG. 355 Informally, the above makes it appropriate, in order to provide a 356 pointer to the relevant policies, to announce the "Note Well" text 357 [NOTEWELL] in all such meetings. 359 8. Conclusions 361 Side meeting organizers are encouraged to rekindle the original 362 spirit behind them and organize them outside IETF meeting rooms, at 363 venues with food and drink, for smaller groups and in a way that does 364 not needlessly mimic the way official IETF sessions are conducted. 366 It can often be useful to discuss proposals for new IETF work face- 367 to-face in an informal setting, but conference calls, email 368 discussions, wikis and other means for interactions are also 369 effective at developing ideas, especially given the scheduling 370 difficulties when busy individuals are involved during an IETF 371 meeting. 373 Finally, it is important to remember that all side meetings during an 374 IETF week are purely informal and have no official status whatsoever. 376 9. IANA Considerations 378 This document raises no IANA considerations. 380 [Note to the RFC Editor: Please remove this section upon 381 publication.] 383 10. Security Considerations 385 This document has no known security implications. 387 [Note to the RFC Editor: Please remove this section upon 388 publication.] 390 11. Acknowledgments 392 The name and title of this document have been chosen to resemble 393 those used by Thomas Narten for his guidelines document on holding a 394 successful BOF [RFC5434], as a sign of appreciation for a document 395 that has proven to be invaluable many times over. 397 Several folks provided feedback and input on this document, including 398 Fred Baker, Scott Bradner, Jorge Contreras, Spencer Dawkins, Frank 399 Ellermann, Adrian Farrel, David Harrington, Russ Housley, Cullen 400 Jennings, John Klensin and Dan Wing. 402 Lars Eggert is partly funded by [TRILOGY], a research project 403 supported by the European Commission under its Seventh Framework 404 Program. 406 12. Informative References 408 [NOTEWELL] 409 "Note Well", http://www.ietf.org/about/note-well.html. 411 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 412 3", BCP 9, RFC 2026, October 1996. 414 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 415 Procedures", BCP 25, RFC 2418, September 1998. 417 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 418 Technology", BCP 79, RFC 3979, March 2005. 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 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 425 to the IETF Trust", BCP 78, RFC 5378, November 2008. 427 [RFC5434] Narten, T., "Considerations for Having a Successful Birds- 428 of-a-Feather (BOF) Session", RFC 5434, February 2009. 430 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 432 Authors' Addresses 434 Lars Eggert 435 Nokia Research Center 436 P.O. Box 407 437 Nokia Group 00045 438 Finland 440 Phone: +358 50 48 24461 441 Email: lars.eggert@nokia.com 442 URI: http://research.nokia.com/people/lars_eggert 444 Gonzalo Camarillo 445 Ericsson 446 Hirsalantie 11 447 Jorvas 02420 448 Finland 450 Email: Gonzalo.Camarillo@ericsson.com