idnits 2.17.1 draft-narten-successful-bof-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 556. 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 Copyright Line does not match the current year -- 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 (October 12, 2007) is 6039 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten 3 Intended Status: Informational IBM 4 October 12, 2007 6 Considerations for Having a Successful BOF 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft expires on April 12, 2008. 35 Abstract 37 This document discusses tactics and strategy for hosting a successful 38 IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the 39 formation of an IETF Working Group. It is based on the experiences of 40 having participated in numerous BOFs, both successful and 41 unsuccessful. 43 Contents 45 Status of this Memo.......................................... 1 47 1. Introduction............................................. 2 48 2. Ideal Steps.............................................. 3 50 3. The BOF Itself........................................... 7 52 4. Pitfalls................................................. 8 54 5. Miscellaneous............................................ 10 55 5.1. Chairing............................................ 10 56 5.2. On The Need For A BOF............................... 11 58 6. Security Considerations.................................. 11 60 7. IANA Considerations...................................... 11 62 8. Acknowledgments.......................................... 11 64 9. Normative References..................................... 12 66 10. Informative References.................................. 12 68 11. Author's Address........................................ 12 70 1. Introduction 72 Note: This version (-03) of the document has no substantive changes 73 over -02; it was resubmitted after the previous version expired. 75 This document provides suggestions on how to host a successful BOF at 76 an IETF meeting. It is hoped that by documenting the methodologies 77 that have proven successful, as well as listing some pitfalls, BOF 78 organizers will improve their chances of hosting a BOF with a 79 positive outcome. 81 There are many reasons for hosting a BOF. Some BOFs are intended to 82 be a one-shot presentation on a particular issue, in order to provide 83 information to the IETF Community. Such BOFs are not intended to 84 result in the formation of a Working Group (WG). In many cases, 85 however, the intent is to form a WG. In those cases, the goal of the 86 BOF is to demonstrate that the community has agreement that: 88 - there is a problem that needs solving, and the IETF is the right 89 group to attempt solving it. 91 - there is a critical mass of participants willing to work on the 92 problem (e.g., write drafts, review drafts, etc.) 94 - the scope of the problem is well defined and understood, that is, 95 people generally understand what the WG will work on (and what 96 not) and what its actual deliverables will be 98 - there is agreement that the specific deliverables (i.e., proposed 99 documents) are the right set 101 - it is believed that the WG has a reasonable probability of having 102 success (i.e., in completing the deliverables in its charter in a 103 timely fashion) 105 2. Ideal Steps 107 The following steps present a sort of "ideal" sequence for hosting a 108 BOF where the goal is formation of a working group. The important 109 observation to make here is that most of these involve planning for 110 and engaging in significant public discussion, with sufficient time 111 for iteration and broad participation, so that much of the work of 112 the BOF can be done on a public mailing list in advance of -- rather 113 than during --- the BOF itself. 115 It is also important to recognize the timing constraints. As 116 described in detail below, the deadline for scheduling BOFs is 117 approximately one month prior to the IETF meeting. Working backwards 118 from that date, taking into consideration the time required to write 119 drafts, have public discussion, allow the ADs to evaluate the 120 proposed BOF, etc., the right time to start preparing for a BOF is 121 the meeting prior to the one in which the BOF is desired. By 122 implication, starting the work aimed at leading to a BOF only 2 123 months prior to an IETF meeting is in most cases too late, and will 124 likely result in the BOF being delayed until the following IETF 125 meeting. 127 1) A small group of individuals gets together privately, discusses a 128 possible problem statement, and identifies the work to be done. 129 The group acts as a sort of "design team" to formulate a problem 130 statement, identify possible work items, and propose an agenda for 131 a BOF. 133 Possible substeps: 135 a) Consider whether the work might already fall within scope for 136 an existing Working Group, in which case a BOF might not even 137 be necessary. Individual Working Group charters can be found at 138 http://www.ietf.org/html.charters/wg-dir.html and indicate what 139 a group is scoped to work on. 141 b) Select an area or areas where the work most naturally fits in 142 by identifying WGs that most closely relate to the proposed 143 work. Note that it is not uncommon to find that a work item 144 could easily fit into two (or more) different areas and that no 145 one area is the obvious home. 147 c) Consult with specific WGs to see whether there is interest or 148 whether the work is in scope. This can be done by posting 149 messages directly to WG mailing lists, contacting the WG 150 chairs, or contacting individuals known to participate in a 151 particular WG (e.g., from their postings or from documents they 152 have authored). 154 d) Consult with an area-specific mailing list about possible 155 interest. (Most areas have their own area-specific mailing 156 lists. Follow the links under each area at 157 http://www.ietf.org/html.charters/wg-dir.html to find details.) 159 e) Produce one or more Internet Drafts, describing the problem 160 and/or related work. It cannot be emphasized enough that for 161 the BOF, drafts relating to understanding the problem space are 162 much more valuable than drafts proposing specific solutions. 164 Timeline: This step can easily take 1-2 months; hence, begin 3-4 165 months before an IETF meeting. 167 2) The group may (or may not) approach an Area Director (or other 168 recognized or experienced leader) to informally float the BOF and 169 get feedback on the proposed work, scope of the charter, specific 170 steps that need to be taken before submitting a formal BOF 171 request, etc. By "leader", we mean persons with significant IETF 172 experience who can provide helpful advice; individuals who have 173 successfully hosted BOFs before, current or former WG chairs, IESG 174 or IAB members, would be good candidates. 176 The dividing line between step 1) and 2) is not exact. At some 177 point, one will need to approach one or more Area Directors (ADs) 178 with a specific proposal that can be commented on. Step 1) helps 179 shape an idea into something concrete enough that an AD can 180 understand the purpose and provide concrete feedback. On the other 181 hand, one shouldn't spend too much time on step 1) if the answer 182 at step 2) would turn out to be "oh, we had a BOF on that once 183 before, have you reviewed the archives?". Thus, there may be some 184 iteration involving going back and forth between steps 1) and 2). 185 Also, a quick conversation with an AD might lead them to suggest 186 some specific individuals or WGs you should consult with. 188 It may turn out that it is unclear which area proposed work best 189 fits in. In such cases, when approaching multiple ADs, it is best 190 to approach the ADs approximately simultaneously, state that you 191 are unsure of which area the work fits in, and ask for advice 192 (e.g., by stating "I'm not sure which area this work best fits 193 under, but it looks like it might be Internet or Security or 194 both"). When contacting multiple ADs, it is strongly advised that 195 you inform them of which other ADs you are conversing with. In 196 particular, it is usually counterproductive and not advisable to 197 go "AD shopping", where if one AD gives you an answer you don't 198 like, you go to another, without telling him/her what the first AD 199 said, in the hopes of getting a different answer. 201 To summarize, steps 1) and 2) involve a lot of "socializing an 202 idea," that is, having discussions with a number of different 203 people to try and get agreement on the problem and the need for 204 and appropriateness of having a BOF. How much such discussion is 205 needed is very subjective, but it is critical in terms of getting 206 agreement that a BOF is appropriate. One way to tell if you are 207 close to getting it right: if when talking to someone about your 208 idea for the first time, they quickly agree that a BOF seems in 209 order and don't have any major concerns. 211 Timeline: Steps 1-2) can easily take 1-2 months; hence, begin 3-4 212 months before an IETF meeting. 214 3) Create a public mailing list and post a "call for participation" 215 for the proposed BOF agenda on various mailing lists (e.g., the 216 ietf list). The call for participation advertises that a 217 "community of interest" is being formed to gauge whether there is 218 sufficient interest to host a BOF. The goal is to draw in other 219 interested potential participants, to allow them to help shape the 220 BOF (e.g., by giving them time to write a draft, ask for agenda 221 time, help scope the work of the proposed work, argue that a BOF 222 is (or is not) needed, etc.) 224 Timeline: This step can easily take 1 month or longer; it also 225 needs to be started well before the Internet-Drafts cutoff (to 226 allow participants to submit drafts); hence begin 2-3 months 227 before the IETF meeting. 229 4) Have real mailing list discussion. It is not enough for a handful 230 of people to assert that they want a BOF; there needs to be 231 broader community interest. A public mailing list allows ADs (and 232 others) to gauge how much interest there really is on a topic 233 area, as well as gauge how well the problem statement has been 234 scoped, etc. At this phase of the BOF preparation, the emphasis 235 should be on getting agreement on the problem statement; 236 discussions about specific solutions tends to be distracting and 237 unhelpful. 239 Timeline: this step can easily take 1 month or longer; hence begin 240 2 months before the IETF meeting. 242 5) Submit a formal request to have a BOF. Instructions for submitting 243 a formal request can be found at 244 http://www.ietf.org/instructions/MTG-SLOTS.html and 245 http://www.ietf.org/ietf/1bof-procedures.txt. Note that as part 246 of making a formal request, the organizers must identify the Area 247 (the area Area Directors will be required to approve the BOF), 248 include a proposed BOF agenda, estimate the attendance, list 249 conflicts with other sessions that should be avoided, etc. 251 If the previous steps have been followed, the Area Directors (ADs) 252 should be in a good position to gauge whether there is sufficient 253 interest to justify approval of a BOF. 255 Note: it almost goes without saying that without one or more 256 Internet Drafts at this point, it is generally pointless to ask an 257 AD to approve a BOF. 259 Timeline: The Secretariat publishes an "important meeting dates" 260 calendar along with meeting information. There is a firm deadline 261 (about 1 month prior to the meeting) for submitting a formal BOF 262 scheduling request. Note: that at the time of the deadline, an AD 263 will need to have sufficient information about the BOF to approve 264 or reject the request, so all of the previous steps will need to 265 have completed. 267 6) During the 2-4 weeks before an IETF (assuming a BOF has been 268 approved and scheduled), the focus (on the mailing list) should be 269 on identifying areas of agreement and areas of disagreement. Since 270 disagreements or "lack of consensus" tends to be the main reason 271 for not forming a WG, focusing on those specific areas where "lack 272 of consensus" exists is critically important. In general, only 273 after those disagreements have been resolved will a WG be formed, 274 thus, the main goal should be to find consensus and work through 275 the areas of disagreement. Alternatively, a specific case should 276 be made about why the charter as it is written is the best one, in 277 spite of the stated opposition. 279 7) Prior to the BOF, it is critical to produce a proposed charter and 280 iterate on it on the mailing list to attempt to get a consensus 281 charter. Ultimately, the most important question to ask during a 282 BOF is: "should a WG with the following charter be formed?". It 283 goes without saying that a charter with shortcomings (no matter 284 how seemingly trivial to fix) will not achieve consensus if folk 285 still have issues with the specific wording. 287 8) Decide what questions will be asked during the BOF itself. Since 288 the exact wording of the questions is critical (and hard to do on 289 the fly), it is strongly recommended that those questions be 290 floated on the mailing list and with the ADs prior to the BOF, so 291 people understand what they will be asked to give approval to, and 292 to allow the questions to be modified (prior to the BOF) to remove 293 ambiguities, etc. Likewise, discussing those questions in advance 294 may lead to refinement of the charter so that the questions can be 295 affirmatively answered 297 9) At the meeting, but before the BOF takes place, plan a meeting 298 with all of the presenters to have them meet each other, review 299 the agenda and make sure everyone understands what is expected of 300 them (e.g., what time constraints they will be under when 301 presenting). Use this time to also work through any disagreements 302 that still remain. Do the same "in the hallway" with other 303 interested parties! 305 10) Consult the tutorial schedule and consider attending relevant 306 tutorial sessions ("Working Group Chair Training", "Working Group 307 Leadership Training", etc.). This is especially the case if you 308 are considering being the chair of a potential WG. Since the role 309 of the WG chair and BOF chair have a number of parallels, a number 310 of the topics covered in the tutorial apply to hosting a BOF and 311 developing a charter. 313 3. The BOF Itself 315 For the BOF itself, it is critically important to focus on the bottom 316 line: 318 What is it that one is attempting to achieve during the BOF? 320 A good BOF organizer keeps a firm focus on the purpose of the BOF and 321 crafts an agenda in support of that goal. Just as important, 322 presentations that do not directly support the goal should be 323 excluded, as they often become distractions, sow confusion, and 324 otherwise take focus away from the purpose of the BOF. If the goal 325 is to form a WG, everything should lead to an (obvious) answer to the 326 following question: 328 Does the room agree that the IETF should form a WG with the 329 following (specific) charter? 331 One of the best ways to ensure a "yes" answer to the above, is by 332 performing adequate preparation before the BOF to ensure that the 333 community as a whole already agrees that the answer is "yes". How 334 does one do that? One good way seems to be: 336 1) Have a public discussion with sufficient time to allow iteration 337 and discussion. (hence, start a minimum of 3 months prior to the 338 IETF meeting). 340 2) Work with the community to iterate on the charter, and be sure to 341 address the significant concerns that are being raised. (One can 342 address the concerns in advance -- and get advance agreement, or 343 one can have those concerns be raised (again) during the BOF -- in 344 which case it is likely that the proposed charter will not be good 345 enough to get agreement on during the actual BOF). 347 3) During the BOF, keep the agenda tightly focused on supporting the 348 need for the WG and otherwise making the case that the group has 349 identified a clearly-scoped charter, and has agreement on what the 350 set of deliverables should be. 352 4. Pitfalls 354 Over the years, a number of pitfalls have been (repeatedly) observed: 356 1) Waiting too long before getting started. It is very difficult to 357 prepare for a BOF on short notice. Moreover, ADs are placed in a 358 no-win situation when asked to approve a BOF for which the 359 community has not had a chance to participate. Steps 1-4 in 360 Section 2 above are designed to show the ADs that there is 361 community support for a particular effort. Short-circuiting those 362 steps force an AD to make a judgment call with (usually) too 363 little information. Moreover, because the community has not been 364 involved, it is much more likely that significant (and valid) 365 objections will be raised. Often, those objections could have been 366 dealt with in advance -- had there been sufficient time to work 367 through them in advance. 369 2) Too much discussion/focus on solutions, rather than showing that 370 support exists for the problem statement itself, and that the 371 problem is well-understood and scoped. The purpose of the BOF is 372 almost never to show that there are already proposed solutions, 373 but to demonstrate that there is a real problem that needs 374 solving, a solution would be beneficial to the community, it is 375 believed that a solution is achievable and that there is a 376 critical mass of community support to actually put in the real 377 work of developing a solution. 379 3) Asking the wrong question during the BOF. Often, BOF organizers 380 feel like there is a need to ask the question "shall we form a 381 WG?". But, unless the question is clear, properly scoped, etc., 382 asking such a question serves no purpose. Even worse, such 383 questions can demonstrate that there is no consensus (yet) for the 384 work and thus no WG should be formed. The right questions to ask 385 are generally along the lines of: 387 1) Is there support to form a WG with the following charter? (that 388 is, the charter itself is ready, as shown by community 389 support.) 391 2) Does the community think that that the problem statement is 392 clear, well-scoped, solvable, and useful to solve? 394 3) Can I see a show of hands for folk willing to review documents? 395 (or comment on the mailing list?) 397 4) Who would be willing to serve as an editor for the following 398 document(s)? (BOF chairs should take note of individuals who 399 raise their hands, but it is also a useful gauge to see there 400 is a critical mass of editors to work on all the documents that 401 are to be produced.) 403 5) Does the community think that given the charter revisions 404 discussed during the BOF (subject to review and finalization on 405 the mailing list), a WG should be formed? 407 6) How many people feel that a WG should not be formed? (If the 408 number of no responses is significant, it would help to ask 409 those saying no why they are opposed.) 411 7) Before asking a particular question, it is sometimes very 412 appropriate to ask: Do people feel like they have sufficient 413 information to answer the following question or is it premature 414 to ask the following question? 416 Examples of unreasonable questions to ask: 418 1) Asking folk to approve or review a charter that is put on 419 screen but has not been posted to the mailing list sufficiently 420 in advance. (You cannot ask folk to approve something they have 421 not seen.) 423 4) Poorly advertised in advance, thus, the BOF itself does not 424 include the "right" participants. This can happen for a number of 425 reasons, including: 427 - BOF is given a "cute" but unintuitive name (or acronym), 428 causing people to not realize that it would be of interest to 429 them 431 - failing to advertise the BOF in advance to the community of 432 people that might be interested. At a minimum, the existence of 433 a proposed BOF should be advertised on the IETF list as well as 434 specific WG lists that are somewhat related. 436 5) Providing agenda time for the "wrong" presentations. There is an 437 (unfortunate) tendency to given anyone who requests agenda time 438 an opportunity to speak. This is often a mistake. Presentations 439 should be limited to those that address the purpose of the BOF. 440 More important, presentations should not distract from the BOFs 441 purpose, or open up ratholes that are a distraction to the more 442 basic purpose of the BOF. Examples of problematic presentations: 444 - presentations on specific solutions, when the purpose of the 445 BOF is to get agreement on the problem statement and the need 446 for a WG. Solutions at this point are too-often "half-baked" 447 and allow discussion to rathole on aspects of the solutions, 448 when instead the focus should be on getting agreement on 449 whether to form a WG. 451 6) Poor time management, leading to insufficient time for discussion 452 of the key issues (this is often closely related to 5). When 453 presentations run over their alloted time, the end result is 454 either squeezing someone else's presentation, or having 455 insufficient discussion time. Neither is acceptable nor helpful. 456 BOF chairs need to give presenters just enough time to make key 457 points -- and no more. It may well be helpful to go over a 458 presenter's slides in advance, to ensure they are on-topic and 459 that they will fit within the time slot. 461 5. Miscellaneous 463 5.1. Chairing 465 BOF organizers often assume that they will be chairing a BOF (and the 466 eventual WG). Neither assumption is always true. ADs need to ensure 467 that a BOF runs smoothly and is productive. For some topics, it is a 468 given that the BOF will be contentious. In such cases, ADs may want 469 to have a more experienced person chairing or co-chairing the BOF. 470 Also, those interested in organizing the BOF often are the most 471 interested in driving a particular technology (and may have strongly 472 held views about what direction an effort should take). Working 473 groups are often more effective when passionately-involved parties 474 are allowed to focus on the technical work, rather than on the 475 management work. Thus do not be surprised (or offended!) if the AD 476 want to pick one or more co-chairs for either the BOF or a followon 477 WG. 479 5.2. On The Need For A BOF 481 This document highlights the need for allowing for and actively 482 engaging in a broad public discussion on the merits of forming a WG. 483 It might surprise some, but there is no actual process requirement to 484 have a BOF prior to forming a WG. The actual process requirement is 485 simply that the IESG (together with the AD(s) sponsoring the work) 486 approve a formal charter as described in [RFC2418]. In practice, BOFs 487 are used to engage the broader community on proposed work and to help 488 produce an acceptable charter. 490 There are two observations that can be made here. First, BOFs are 491 often held not because they are (strictly speaking) required, but 492 because it is assumed they are needed or because ADs feel that a BOF 493 would be beneficial in terms of getting additional public 494 participation. Hence, those interested in forming a WG should give 495 serious consideration to using the steps outlined above not just for 496 the purposes of leading to a BOF, but to convince the IESG and 497 broader community that a BOF is not even needed, as there is already 498 demonstrated strong consensus that a WG shold be formed. Second, the 499 IESG should not forget that BOFs are simply a tool, and may not even 500 be the best tool in every situation. 502 6. Security Considerations 504 This document has no known security implications. 506 7. IANA Considerations 508 This document makes no requests to IANA. 510 8. Acknowledgments 512 This document has benefited from specific feedback from Brian 513 Carpenter, Spencer Dawkins, John Klensin, Mark Townsley and Bert 514 Wijnen. 516 9. Normative References 518 10. Informative References 520 [RFC2418] "IETF Working Group Guidelines and Procedures," S. Bradner, 521 September 1998. 523 11. Author's Address 525 Thomas Narten 526 IBM Corporation 527 3039 Cornwallis Ave. 528 PO Box 12195 - BRQA/502 529 Research Triangle Park, NC 27709-2195 531 Phone: 919-254-7798 532 EMail: narten@us.ibm.com 534 Intellectual Property Statement 536 The IETF takes no position regarding the validity or scope of any 537 Intellectual Property Rights or other rights that might be claimed to 538 pertain to the implementation or use of the technology described in 539 this document or the extent to which any license under such rights 540 might or might not be available; nor does it represent that it has 541 made any independent effort to identify any such rights. Information 542 on the procedures with respect to rights in RFC documents can be 543 found in BCP 78 and BCP 79. 545 Copies of IPR disclosures made to the IETF Secretariat and any 546 assurances of licenses to be made available, or the result of an 547 attempt made to obtain a general license or permission for the use of 548 such proprietary rights by implementers or users of this 549 specification can be obtained from the IETF on-line IPR repository at 550 http://www.ietf.org/ipr. 552 The IETF invites any interested party to bring to its attention any 553 copyrights, patents or patent applications, or other proprietary 554 rights that may cover technology that may be required to implement 555 this standard. Please address the information to the IETF at ietf- 556 ipr@ietf.org. 558 Copyright Statement 560 Copyright (C) The IETF Trust (2007). 562 This document is subject to the rights, licenses and restrictions 563 contained in BCP 78, and except as set forth therein, the authors 564 retain all their rights. 566 This document and the information contained herein are provided on an 567 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 568 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 569 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 570 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 571 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 572 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.