idnits 2.17.1 draft-narten-successful-bof-04.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 690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 661. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 674. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (December 3, 2008) is 5622 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 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 December 3, 2008 6 Considerations for Having a Successful Birds-of-a-Feather (BOF) Session 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 June 3, 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. Recommended Steps........................................ 3 50 3. The Importance of Understanding the Real Problem......... 7 52 4. The BOF Itself........................................... 8 54 5. Post-BOF Followup........................................ 10 56 6. Pitfalls................................................. 11 58 7. Miscellaneous............................................ 13 59 7.1. Chairing............................................ 13 60 7.2. On The Need For A BOF............................... 13 62 8. Security Considerations.................................. 14 64 9. IANA Considerations...................................... 14 66 10. Acknowledgments......................................... 14 68 11. Normative References.................................... 14 70 12. Informative References.................................. 14 72 13. Author's Address........................................ 14 74 1. Introduction 76 This document provides suggestions on how to host a successful BOF at 77 an IETF meeting. It is hoped that by documenting the methodologies 78 that have proven successful, as well as listing some pitfalls, BOF 79 organizers will improve their chances of hosting a BOF with a 80 positive outcome. 82 There are many reasons for hosting a BOF. Some BOFs are not intended 83 to result in the formation of a Working Group (WG). For example, a 84 BOF might be a one-shot presentation on a particular issue, in order 85 to provide information to the IETF Community. Another example might 86 be to host an open meeting to discuss specific open issues with a 87 document that is not associated with an active WG, but for which 88 face-to-face interaction is needed to resolve issues. In many cases, 89 however, the intent is to form a WG. In those cases, the goal of the 90 BOF is to demonstrate that the community has agreement that: 92 - there is a problem that needs solving, and the IETF is the right 93 group to attempt solving it. 95 - there is a critical mass of participants willing to work on the 96 problem (e.g., write drafts, review drafts, etc.) 98 - the scope of the problem is well defined and understood, that is, 99 people generally understand what the WG will work on (and what 100 not) and what its actual deliverables will be 102 - there is agreement that the specific deliverables (i.e., proposed 103 documents) are the right set 105 - it is believed that the WG has a reasonable probability of having 106 success (i.e., in completing the deliverables in its charter in a 107 timely fashion) 109 Additional details on WGs and BOFs can be found in [RFC2418]. 111 2. Recommended Steps 113 The following steps present a sort of "ideal" sequence for hosting a 114 BOF where the goal is formation of a working group. The important 115 observation to make here is that most of these involve planning for 116 and engaging in significant public discussion, and allowing for 117 sufficient time for iteration and broad participation, so that much 118 of the work of the BOF can be done on a public mailing list in 119 advance of -- rather than during --- the BOF itself. 121 It is also important to recognize the timing constraints. As 122 described in detail below, the deadline for scheduling BOFs is 123 approximately six weeks prior to an IETF meeting. Working backwards 124 from that date, taking into consideration the time required to write 125 drafts, have public discussion, allow the ADs to evaluate the 126 proposed BOF, etc., the right time to start preparing for a BOF is 127 almost certainly the meeting prior to the one in which the BOF is 128 desired. By implication, starting the work aimed at leading to a BOF 129 only 2 months prior to an IETF meeting is in most cases waiting too 130 late, and will likely result in the BOF being delayed until the 131 following IETF meeting. 133 The recommended steps for a BOF are as follows: 135 1) A small group of individuals gets together privately, discusses a 136 possible problem statement, and identifies the work to be done. 137 The group acts as a sort of "design team" to formulate a problem 138 statement, identify possible work items, and propose an agenda for 139 a BOF. 141 Possible substeps: 143 a) Consider whether the work might already fall within scope of an 144 existing Working Group, in which case a BOF might not even be 145 necessary. Individual Working Group charters can be found at 146 http://www.ietf.org/html.charters/wg-dir.html and indicate what 147 a group is scoped to work on. 149 b) Select an area or areas where the work most naturally fits in 150 by identifying WGs that most closely relate to the proposed 151 work. Note that it is not uncommon to find that a work item 152 could easily fit into two (or more) different areas and that no 153 one area is the obvious home. 155 c) Consult with specific WGs to see whether there is interest or 156 whether the work is in scope. This can be done by posting 157 messages directly to WG mailing lists, contacting the WG 158 chairs, or contacting individuals known to participate in a 159 particular WG (e.g., from their postings or from documents they 160 have authored). 162 d) Consult with an area-specific mailing list about possible 163 interest. (Most areas have their own area-specific mailing 164 lists. Follow the links under each area at 165 http://www.ietf.org/html.charters/wg-dir.html to find details.) 167 e) Produce one or more Internet Drafts, describing the problem 168 and/or related work. It cannot be emphasized enough that for 169 the BOF, drafts relating to understanding the problem space are 170 much more valuable than drafts proposing specific solutions. 172 Timeline: This step can easily take 1-2 months; hence, begin 3-4 173 months before an IETF meeting. 175 2) The group may (or may not) approach an Area Director (or other 176 recognized or experienced leader) to informally float the BOF and 177 get feedback on the proposed work, scope of the charter, specific 178 steps that need to be taken before submitting a formal BOF 179 request, etc. By "leader", we mean persons with significant IETF 180 experience who can provide helpful advice; individuals who have 181 successfully hosted BOFs before, current or former WG chairs, IESG 182 or IAB members, would be good candidates. 184 The dividing line between step 1) and 2) is not exact. At some 185 point, one will need to approach one or more Area Directors (ADs) 186 with a specific proposal that can be commented on. Step 1) helps 187 shape an idea into something concrete enough that an AD can 188 understand the purpose and provide concrete feedback. On the other 189 hand, one shouldn't spend too much time on step 1) if the answer 190 at step 2) would turn out to be "oh, we had a BOF on that once 191 before, have you reviewed the archives?". Thus, there may be some 192 iteration involving going back and forth between steps 1) and 2). 193 Also, a quick conversation with an AD might lead them to suggest 194 some specific individuals or WGs you should consult with. 196 It may turn out that it is unclear which area proposed work best 197 fits in. In such cases, when approaching multiple ADs, it is best 198 to approach the ADs approximately simultaneously, state that you 199 are unsure of which area the work fits in, and ask for advice 200 (e.g., by stating "I'm not sure which area this work best fits 201 under, but it looks like it might be Internet or Security or 202 both"). When contacting multiple ADs, it is strongly advised that 203 you inform them of which other ADs you are conversing with. In 204 particular, it is usually counterproductive and not advisable to 205 go "AD shopping", where if one AD gives you an answer you don't 206 like, you go to another, without telling him/her what the first AD 207 said, in the hopes of getting a more favorable answer. 209 To summarize, steps 1) and 2) involve a lot of "socializing an 210 idea," that is, having discussions with a number of different 211 people to try and get agreement on the problem and the need for 212 and appropriateness of having a BOF. How much such discussion is 213 needed is very subjective, but it is critical in terms of getting 214 agreement that a BOF is appropriate. One way to tell if you are 215 close to getting it right: if when talking to someone about your 216 idea for the first time, they quickly agree that a BOF seems in 217 order and don't have any major concerns. 219 Timeline: Steps 1-2) can easily take 1-2 months; hence, begin 3-4 220 months before an IETF meeting. 222 3) Create a public mailing list and post a "call for participation" 223 for the proposed BOF topic on various mailing lists (e.g., the 224 ietf list). The call for participation advertises that a 225 "community of interest" is being formed to gauge whether there is 226 sufficient interest to host a BOF. The goal is to draw in other 227 interested potential participants, to allow them to help shape the 228 BOF (e.g., by giving them time to write a draft, ask for agenda 229 time, help scope the work of the proposed work, argue that a BOF 230 is (or is not) needed, etc.) 232 Timeline: This step can easily take 1 month or longer; it also 233 needs to be started well before the Internet-Drafts cutoff (to 234 allow participants to submit drafts); hence begin 2.5-3.5 months 235 before the IETF meeting. 237 4) Have substantive mailing list discussion. It is not enough for a 238 handful of people to assert that they want a BOF; there needs to 239 be broader community interest. A public mailing list allows ADs 240 (and others) to gauge how much interest there really is on a topic 241 area, as well as gauge how well the problem statement has been 242 scoped, etc. At this phase of the BOF preparation, the emphasis 243 should be on getting agreement on the problem statement; 244 discussions about specific solutions tends to be distracting and 245 unhelpful. 247 Timeline: this step can easily take 1 month or longer; hence begin 248 2.5 months before the IETF meeting. 250 5) Submit a formal request to have a BOF. Instructions for submitting 251 a formal request can be found at 252 http://www.ietf.org/instructions/MTG-SLOTS.html and 253 http://www.ietf.org/ietf/1bof-procedures.txt. Note that as part 254 of making a formal request, the organizers must identify the Area 255 the BOF will be held in (the Area Directors of that Area will be 256 required to approve the BOF), include a proposed BOF agenda, 257 estimate the attendance, list conflicts with other sessions that 258 should be avoided, etc. 260 If the previous steps have been followed, the Area Directors (ADs) 261 should be in a good position to gauge whether there is sufficient 262 interest to justify approval of a BOF. 264 Note: it almost goes without saying that without one or more 265 Internet Drafts at this point, it is generally pointless to ask an 266 AD to approve a BOF. 268 Timeline: The Secretariat publishes an "important meeting dates" 269 calendar along with meeting information. There is a firm deadline 270 (about six weeks prior to the meeting) for submitting a formal BOF 271 scheduling request. Note: that at the time of the deadline, an AD 272 will need to have sufficient information about the BOF to approve 273 or reject the request, so all of the previous steps will need to 274 have completed. 276 6) During the 2-4 weeks before an IETF (assuming a BOF has been 277 approved and scheduled), the focus (on the mailing list) should be 278 on identifying areas of agreement and areas of disagreement. Since 279 disagreements or "lack of consensus" tends to be the main reason 280 for not forming a WG, focusing on those specific areas where "lack 281 of consensus" exists is critically important. In general, only 282 after those disagreements have been resolved will a WG be formed, 283 thus, the main goal should be to find consensus and work through 284 the areas of disagreement. Alternatively, a specific case should 285 be made about why the charter as it is written is the best one, in 286 spite of the stated opposition. 288 7) Prior to the BOF, it is critical to produce a proposed charter and 289 iterate on it on the mailing list to attempt to get a consensus 290 charter. Ultimately, the most important question to ask during a 291 BOF is: "should a WG with the following charter be formed?". It 292 goes without saying that a charter with shortcomings (no matter 293 how seemingly trivial to fix) will not achieve consensus if folk 294 still have issues with the specific wording. 296 8) Decide what questions will be asked during the BOF itself. Since 297 the exact wording of the questions is critical (and hard to do on 298 the fly), it is strongly recommended that those questions be 299 floated on the mailing list and with the ADs prior to the BOF, so 300 people understand what they will be asked to give approval to, and 301 to allow the questions to be modified (prior to the BOF) to remove 302 ambiguities, etc. Likewise, discussing those questions in advance 303 may lead to refinement of the charter so that the questions can be 304 answered affirmatively. 306 9) At the meeting, but before the BOF takes place, plan a meeting 307 with all of the presenters to have them meet each other, review 308 the agenda and make sure everyone understands what is expected of 309 them (e.g., what time constraints they will be under when 310 presenting). Use this time to also work through any disagreements 311 that still remain. Do the same "in the hallway" with other 312 interested parties! 314 10) Consult the tutorial schedule and consider attending relevant 315 tutorial sessions ("Working Group Chair Training", "Working Group 316 Leadership Training", etc.). This is especially the case if you 317 are considering being the chair of a proposed WG. Since the role 318 of the WG chair and BOF chair have a number of parallels, a number 319 of the topics covered in the tutorial apply to hosting a BOF and 320 developing a charter. 322 3. The Importance of Understanding the Real Problem 324 Throughout the process of chartering new work in the IETF, a key 325 issue is understanding (and finding consensus) on what the real, 326 underlying problem is that the customer, operator or deployer of a 327 technology has and that the WG needs to address. When a WG finishes 328 an effort, the WG's output will only be useful if it actually solves 329 a real compelling problem faced by the actual user of the technology 330 (i.e., the customer or operator). Unfortunately, there have been more 331 than a few IETF WGs whose output was not adopted, and in some of 332 those cases the cause was a lack of understanding of the real problem 333 the operator had. In the end, the WG's output simply didn't address 334 the right problem. 336 Another issue that can happen is for discussions about specific (or 337 competing) solution approaches to effectively stalemate with the WG 338 (or BOF) unable to make progress. In some of those cases, the 339 arguments about the appropriateness of specific technologies are 340 actually proxies for the question of whether a proposed approach 341 adequately addresses the problem. If there is a lack of clarity about 342 the actual underlying problem to be solved, there may well be 343 unresolvable arguments about the suitability of a particular 344 technical approach, depending on one's view of the actual problem and 345 the constraints associated with it. Hence, it is critical for all 346 work to be guided by a clear and shared understanding of the 347 underlying problem. 349 The best description and understanding of an actual problem usually 350 comes from the customer, operator or deployer of a technology. They 351 are the ones that most clearly understand the difficulties they are 352 having (that need addressing) and they are the ones who will have to 353 deploy any proposed solution. Thus, it is critical to hear their 354 voice when formulating the details of the problem statement. 355 Moreover, when evaluating the relative merits of differing solution 356 approaches, it is often helpful to go back to the underlying problem 357 statement to provide guidance in selecting the more appropriate 358 approach. 360 4. The BOF Itself 362 For the BOF itself, it is critically important to focus on the bottom 363 line: 365 What is it that one is attempting to achieve during the BOF? 367 Or, stated differently, after the BOF is over, by what criteria will 368 you decide whether the BOF was successful or not? 370 A good BOF organizer keeps a firm focus on the purpose of the BOF and 371 crafts an agenda in support of that goal. Just as important, 372 presentations that do not directly support the goal should be 373 excluded, as they often become distractions, sow confusion, and 374 otherwise take focus away from the purpose of the BOF. If the goal 375 is to form a WG, everything should lead to an (obvious) answer to the 376 following question: 378 Does the room agree that the IETF should form a WG with the 379 following (specific) charter? 381 One of the best ways to ensure a "yes" answer to the above, is by 382 performing adequate preparation before the BOF to ensure that the 383 community as a whole already agrees that the answer is "yes". How 384 does one do that? One good way seems to be: 386 1) Have a public discussion with sufficient time to allow iteration 387 and discussion. (hence, start a minimum of 3 months prior to the 388 IETF meeting). 390 2) Work with the community to iterate on the charter, and be sure to 391 address the significant concerns that are being raised. (One can 392 address the concerns in advance -- and get advance agreement, or 393 one can have those concerns be raised (again) during the BOF -- in 394 which case it is likely that the proposed charter will not be good 395 enough to get agreement on during the actual BOF). 397 3) During the BOF, keep the agenda tightly focused on supporting the 398 need for the WG and otherwise making the case that the group has 399 identified a clearly-scoped charter, and has agreement on what the 400 set of deliverables should be. 402 Another important reason for holding a BOF is to establish an 403 understanding of how the attendees (and the larger community) feel 404 about the proposed work. Do they understand and agree on the problem 405 that needs solving? Do they agree the problem is solvable, or that 406 new protocol work is needed? To better understand the degree of 407 agreement, it is useful to ask the audience questions. 409 Whenever asking questions, it is important to ask the right ones -- 410 questions that show where there is agreement and questions that probe 411 the details around where agreement is lacking. Good questions 412 typically focus on aspects of the problem in a piecewise fashion, 413 establishing areas of consensus and identifying areas where 414 additional work is needed. Poor questions do not serve to focus 415 future discussion where it is needed. The following are examples of 416 questions that are often useful to ask. 418 1) Is there support to form a WG with the following charter? (that 419 is, the charter itself is ready, as shown by community support.) 421 2) Does the community think that that the problem statement is clear, 422 well-scoped, solvable, and useful to solve? 424 3) Can I see a show of hands for folk willing to review documents? 425 (or comment on the mailing list?) 427 4) Who would be willing to serve as an editor for the following 428 document(s)? (BOF chairs should take note of individuals who raise 429 their hands, but it is also a useful gauge to see there is a 430 critical mass of editors to work on all the documents that are to 431 be produced.) 433 5) Does the community think that given the charter revisions 434 discussed during the BOF (subject to review and finalization on 435 the mailing list), a WG should be formed? 437 6) How many people feel that a WG should not be formed? (If the 438 number of no responses is significant, it would help to ask those 439 saying no why they are opposed.) 441 7) Before asking a particular question, it is sometimes very 442 appropriate to ask: Do people feel like they have sufficient 443 information to answer the following question or is it premature to 444 even ask the question? 446 Unfortunately, it is also easy to ask the wrong questions. Some 447 examples are given in a later section. 449 5. Post-BOF Followup 451 After the BOF has taken place, it is advisable to take assessment of 452 how well things went and what the next steps are. The ADs should be 453 included in this assessment. Some things to consider: 455 1) Did the BOF go well enough that the logical next step is to focus 456 on refining the charter and become a WG before the next IETF 457 meeting? If so, there will almost certainly be additional 458 discussion on the mailing list to refine the charter and work out 459 a few remaining items. 461 Note that it can be difficult to determine in some cases whether a 462 WG is a feasible next step. Much will depend on details of how the 463 BOF went and/or whether the contentious items can either be 464 resolved on the mailing list, or can simply be excluded from the 465 charter and dealt with later (if at all). Much will depend on the 466 relevant AD's assessment of whether the proposed work is ready to 467 move forward. Sometimes, even a seemingly contentious BOF can 468 result in a WG being formed quickly -- provided the charter is 469 scoped appropriately. 471 If the next step is to attempt to form a WG, the charter needs to 472 be finalized on the BOF-specific mailing list. Once done, the IESG 473 can be asked to formally consider the charter. The IESG then 474 (usually) posts the proposed charter to the IETF list for 475 community feedback and makes a decision based in part on the 476 feedback it receives. 478 2) It may be the case that enough additional work still needs to take 479 place that aiming for a second (and final) BOF makes more sense. 480 In that case, many of the steps outlined earlier in this document 481 would be repeated, thought at a faster pace. 483 The expectations for a second BOF are generally higher than those 484 for an initial BOF. In addition to the work done up through the 485 first BOF, the first BOF will have highlighted the key areas where 486 additional work is needed. The time leading up to the second BOF 487 will need to be spent working through those outstanding issues. 488 Second BOFs should not be a repeat of the first BOF, with the same 489 issues being raised and the same (unsatisfactory) responses 490 provided. The second BOF needs to show that all previously- 491 identified issues have been resolved and that formation of a WG is 492 now in order. 494 6. Pitfalls 496 Over the years, a number of pitfalls have been (repeatedly) observed: 498 1) Waiting too long before getting started. It is very difficult to 499 prepare for a BOF on short notice. Moreover, ADs are placed in a 500 no-win situation when asked to approve a BOF for which the 501 community has not had a chance to participate. Steps 1-4 in 502 Section 2 above are designed to show the ADs that there is 503 community support for a particular effort. Short-circuiting those 504 steps force an AD to make a judgment call with (usually) too 505 little information. Moreover, because the community has not been 506 involved, it is much more likely that significant (and valid) 507 objections will be raised. Often, those objections could have been 508 dealt with in advance -- had there been sufficient time to work 509 through them in advance. 511 2) Too much discussion/focus on solutions, rather than showing that 512 support exists for the problem statement itself, and that the 513 problem is well-understood and scoped. The purpose of the BOF is 514 almost never to show that there are already proposed solutions, 515 but to demonstrate that there is a real problem that needs 516 solving, a solution would be beneficial to the community, it is 517 believed that a solution is achievable and that there is a 518 critical mass of community support to actually put in the real 519 work of developing a solution. 521 3) Asking the wrong question during the BOF. Often, BOF organizers 522 feel like they need for a "show of hands" on specific questions. 523 But, unless a question is clear, well scoped, focused enough to 524 establish where there is agreement (and where not), etc., asking 525 such a question serves little purpose. Even worse, asking poor 526 questions can frustrate the BOF participants and lead to 527 additional questions at the microphone, derailing the focus of the 528 BOF. 530 Examples of an unreasonable question to ask: 532 1) Asking folk to approve or review a charter that is put on 533 screen but has not been posted to the mailing list sufficiently 534 in advance. (You cannot ask folk to approve something they have 535 not seen.) 537 2) Asking multi-part questions in which it is not clear (in 538 advance) what all of the exact questions will be and which 539 choices a participant needs to choose from. 541 4) Poorly advertised in advance, thus, the BOF itself does not 542 include the "right" participants. This can happen for a number of 543 reasons, including: 545 - BOF is given a "cute" but unintuitive name (or acronym), 546 causing people to not realize that it would be of interest to 547 them 549 - failing to advertise the BOF in advance to the community of 550 people that might be interested. At a minimum, the existence of 551 a proposed BOF should be advertised on the IETF list as well as 552 specific WG lists that are somewhat related. 554 5) Providing agenda time for the "wrong" presentations. There is an 555 (unfortunate) tendency to given anyone who requests agenda time 556 an opportunity to speak. This is often a mistake. Presentations 557 should be limited to those that address the purpose of the BOF. 558 More important, presentations should not distract from the BOFs 559 purpose, or open up ratholes that are a distraction to the more 560 basic purpose of the BOF. Examples of problematic presentations: 562 - presentations on specific solutions, when the purpose of the 563 BOF is to get agreement on the problem statement and the need 564 for a WG. Solutions at this point are too-often "half-baked" 565 and allow discussion to rathole on aspects of the solutions, 566 when instead the focus should be on getting agreement on 567 whether to form a WG. 569 6) Poor time management, leading to insufficient time for discussion 570 of the key issues (this is often closely related to 5). When 571 presentations run over their allotted time, the end result is 572 either squeezing someone else's presentation, or having 573 insufficient discussion time. Neither is acceptable nor helpful. 574 BOF chairs need to give presenters just enough time to make key 575 points -- and no more. It may well be helpful to go over a 576 presenter's slides in advance, to ensure they are on-topic and 577 that they will fit within the time slot. 579 7. Miscellaneous 581 7.1. Chairing 583 BOF organizers often assume that they will be chairing a BOF (and the 584 eventual WG). Neither assumption is always true. ADs need to ensure 585 that a BOF runs smoothly and is productive. For some topics, it is a 586 given that the BOF will be contentious. In such cases, ADs may want 587 to have a more experienced person chairing or co-chairing the BOF. 588 Also, those interested in organizing the BOF often are the most 589 interested in driving a particular technology (and may have strongly 590 held views about what direction an effort should take). Working 591 groups are often more effective when passionately-involved parties 592 are allowed to focus on the technical work, rather than on managing 593 the WG itself. Thus do not be surprised (or offended!) if the AD 594 want to pick one or more co-chairs for either the BOF or a follow-on 595 WG. 597 7.2. On The Need For A BOF 599 This document highlights the need for allowing for and actively 600 engaging in a broad public discussion on the merits of forming a WG. 601 It might surprise some, but there is no actual process requirement to 602 have a BOF prior to forming a WG. The actual process requirement is 603 simply that the IESG (together with the AD(s) sponsoring the work) 604 approve a formal charter as described in [RFC2418]. In practice, BOFs 605 are used to engage the broader community on proposed work and to help 606 produce an acceptable charter. 608 There are two observations that can be made here. First, BOFs are 609 often held not because they are (strictly speaking) required, but 610 because it is assumed they are needed or because ADs feel that a BOF 611 would be beneficial in terms of getting additional public 612 participation. Hence, those interested in forming a WG should give 613 serious consideration to using the steps outlined above not just for 614 the purposes of leading to a BOF, but to convince the IESG and 615 broader community that a BOF is not even needed, as there is already 616 demonstrated strong consensus that a WG should be formed. Second, the 617 IESG should not forget that BOFs are simply a tool, and may not even 618 be the best tool in every situation. 620 8. Security Considerations 622 This document has no known security implications. 624 9. IANA Considerations 626 This document makes no requests to IANA. 628 10. Acknowledgments 630 This document has benefited from specific feedback from Brian 631 Carpenter, Spencer Dawkins, John Klensin, Mark Townsley and Bert 632 Wijnen. 634 11. Normative References 636 12. Informative References 638 [RFC2418] "IETF Working Group Guidelines and Procedures," S. Bradner, 639 September 1998. 641 13. Author's Address 643 Thomas Narten 644 IBM Corporation 645 3039 Cornwallis Ave. 646 PO Box 12195 - BRQA/502 647 Research Triangle Park, NC 27709-2195 649 Phone: 919-254-7798 650 EMail: narten@us.ibm.com 652 Intellectual Property Statement 654 The IETF takes no position regarding the validity or scope of any 655 Intellectual Property Rights or other rights that might be claimed to 656 pertain to the implementation or use of the technology described in 657 this document or the extent to which any license under such rights 658 might or might not be available; nor does it represent that it has 659 made any independent effort to identify any such rights. Information 660 on the procedures with respect to rights in RFC documents can be 661 found in BCP 78 and BCP 79. 663 Copies of IPR disclosures made to the IETF Secretariat and any 664 assurances of licenses to be made available, or the result of an 665 attempt made to obtain a general license or permission for the use of 666 such proprietary rights by implementers or users of this 667 specification can be obtained from the IETF on-line IPR repository at 668 http://www.ietf.org/ipr. 670 The IETF invites any interested party to bring to its attention any 671 copyrights, patents or patent applications, or other proprietary 672 rights that may cover technology that may be required to implement 673 this standard. Please address the information to the IETF at 674 ietf-ipr@ietf.org. 676 Copyright Statement 678 Copyright (C) The IETF Trust (2008). 680 This document is subject to the rights, licenses and restrictions 681 contained in BCP 78, and except as set forth therein, the authors 682 retain all their rights. 684 This document and the information contained herein are provided on an 685 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 686 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 687 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 688 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 689 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 690 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.