idnits 2.17.1 draft-narten-successful-bof-00.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 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 17, 2005) is 6766 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten 3 IBM 4 October 17, 2005 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 11, 2006.b 35 Abstract 37 This document discusses tactics and strategy for hosting a successful 38 IETF Birds-of-a-Feather (BOF) Session. It is based on the experiences 39 of having participated in numerous BOFs, both successful and 40 unsuccessful. 42 Contents 44 Status of this Memo.......................................... 1 46 1. Introduction............................................. 2 47 2. Ideal Steps.............................................. 3 49 3. The BOF Itself........................................... 5 51 4. Pitfalls................................................. 5 53 5. Security Considerations.................................. 7 55 6. IANA Considerations...................................... 7 57 7. Acknowledgments.......................................... 7 59 8. Normative References..................................... 7 61 9. Informative References................................... 7 63 10. Author's Address...................................... 8 65 1. Introduction 67 This document provides suggestions on how to host a successful BOF at 68 an IETF meeting. It is hoped that by documenting the methodologies 69 that have proven successful, as well as listing some pitfalls, BOF 70 organizers will improve their chances of hosting a BOF with a 71 positive outcome. 73 There are many reasons for hosting a BOF. Some BOFs are intended to 74 be a one-shot presentation on a particular issue, in order to provide 75 information to the IETF Community. Such BOFs are not intended to 76 result in the formation of a Working Group (WG). In many cases, 77 however, the intent is to form a WG. In those cases, the goal of the 78 BOF is to demonstrate that the community has agreement that: 80 - there is a problem that needs solving, and the IETF is the right 81 group to attempt solving it. 83 - there is a critical mass of participants willing to work on the 84 problem (e.g., write drafts, review drafts, etc.) 86 - the scope of the problem is well defined and understood, that is, 87 people generally understand what the WG will work on (and what 88 not) and what its actual deliverables will be 90 - there is agreement that the specific deliverables (i.e., proposed 91 documents) are the right set 93 - it is believed that the WG has a reasonable probability of having 94 success (i.e., in completing the deliverables in its charter in a 95 timely fashion) 97 2. Ideal Steps 99 The following steps present a sort of "ideal" sequence for hosting a 100 BOF. The important observation to make here is that most of these 101 involve having public discussion, with sufficient advance time, so 102 that much of the work of the BOF can be done on a public mailing list 103 -- in advance -- rather than during the BOF itself. 105 1) A small group of individuals gets together privately, discusses a 106 possible problem statement, and identifies the work to be done. 107 The group acts as a sort of "design team" to formulate a problem 108 statement, identify possible work items, and propose an agenda for 109 a BOF. 111 Timeline: well before the BOF scheduling deadline (e.g., months 112 before IETF meeting) 114 2) The group may (or may not) approach an Area Director (or other 115 recognized leader) to informally float the BOF and get feedback on 116 the proposed work, scope of the charter, specific steps the need 117 to be taken before sumbitting a formal BOF request, etc.. (Note, 118 this step can be skipped in some cases.) 120 Timeline: well before the BOF scheduling deadline (e.g., at least 121 2 months before IETF meeting) 123 3) A public mailing list is created, and a proposed BOF agenda is 124 posted on various mailing lists (e.g, the ietf list) to advertise 125 that a "community of interest" is being formed to gauge whether 126 there is sufficient interest in hosting a BOF. The goal is to draw 127 in other interested potential participants, to allow them to help 128 shape the BOF (e.g., by giving them time to write a draft, ask for 129 agenda time, help scope the work of the proposed work, argue that 130 a BOF is (or is not) needed, etc.) 132 Timeline: well before BOF scheduling deadline (e.g., 1-2 months 133 before BOF scheduling deadline) 135 4) Have real mailing list discussion. It is not enough for a handful 136 of people to assert that they want a BOF; there needs to be 137 broader community interest. A public mailing list allows Area 138 Directors (and others) to gauge how much interest there really is 139 on a topic area, as well as gauge how well the problem statement 140 has been scoped, etc. At this phase of the BOF preparation, the 141 emphasis should be on getting agreement on the problem statement; 142 discussions about specific solutions tends to be distracting and 143 unhelpful. 145 5) Once there has been discussion on the mailing list, make a formal 146 request for a BOF. [XXX: need to cite the specific steps.] Note 147 that as part of making a formal request, the organizers identify 148 the Area Directors (i.e, proposed Area) appropriate for the BOF 149 topic. 151 If the previous steps have been followed, the Area Directors (ADs) 152 should be in a good position to gauge whether there is sufficient 153 interest to justify approval of a BOF. 155 Timeline: minimum of 2 weeks before BOF scheduling deadline. 157 6) During the 2-4 weeks before an IETF (assuming a BOF has been 158 scheduled), the focus (on the mailing list) should be on 159 identifying areas of agreement and areas of disagreement. Since 160 disagreements or "lack of consensus" tends to be the main reason 161 for not forming a WG, focusing on those specific areas where "lack 162 of consensus" exists is critically important. In general, only 163 after those disagreements have been resolved will a WG be formed, 164 thus, the main goal should be to find consensus and work through 165 the areas of disagreement. Alternatively, a specific case should 166 be made about why the charter as it is written is the best one, in 167 spite of the stated opposition. 169 7) Prior to the BOF, it is critical to produce a proposed charter and 170 iterate on it on the mailing list to attempt to get a consensus 171 charter. Ultimately, the most important question to ask during a 172 BOF is: "should a WG with the following charter be formed?". It 173 goes without saying that a charter with shortcomings (no matter 174 how seemingly trivial to fix) will not achieve consensus if folk 175 still have issues with the specific wording. 177 8) Decide what questions will be asked of the room. Since the exact 178 wording of the questions is critical (and hard to do on the fly), 179 it is strongly recommended that those questions be floated on the 180 mailing list and with the ADs prior to the BOF, so people 181 understand what they will be asked to give approval to, and to 182 allow the questions to be modified (prior to the BOF) to remove 183 ambiguities, etc. Likewise, discussing those questions in advance 184 may lead to refinement of the charter so that the questions can be 185 affirmatively answered 187 3. The BOF Itself 189 For the BOF itself, it is critically important to focus on the bottom 190 line: 192 What is it that one is attempting to achieve during the BOF? 194 A good BOF organizer keeps a firm focus on the purpose of the BOF and 195 crafts an agenda in support of that goal. Just as important, 196 presentations that do not directly support the goal should be 197 excluded, as they often become ratholes, sow confusion, and otherwise 198 take focus away from the purpose of the BOF. If the goal is to form 199 a WG, everything should lead to an (obvious) answer to the following 200 question: 202 Does the room agree that the IETF should form a WG with the 203 following (specific) charter? 205 One of the best ways to ensure a "yes" answer to the above, is by 206 performing adequate preparation before the BOF to ensure that that 207 the community as a whole agrees that the answer is "yes". How does 208 one do that? One good way seems to be: 210 1) Have a public discussion with sufficient time to allow iteration 211 and discussion. (hence, start a minimum of 2 months before the BOF 212 scheduling deadline). 214 2) Work with the community to iterate on the charter, and be sure to 215 address the significant concerns that are being raised. (One can 216 address the concerns in advance -- and get advance agreement, or 217 one can have those concerns be raised (again) during the BOF -- in 218 which case it is likely that the proposed charter will not be good 219 enough to get agreement on during the actual BOF). 221 3) During the BOF, have the agenda tightly focused on supporting the 222 need for the WG and otherwise making the case that the group has 223 identified a clearly-scoped charter, and has agreement on what the 224 set of deliverables should be. 226 4. Pitfalls 228 Over the years, a number of pitfalls have been (repeatedly) observed: 230 1) Waiting too long before getting started. It is very difficult to 231 prepare for a BOF on short notice. Moreover, ADs are placed in a 232 no-win situation when asked to approve a BOF for which the 233 community has not had a chance to participate. Steps 1-4 in 234 Section 2 above are designed to show the ADs that there is 235 community support for a particular effort. Short-circuiting those 236 steps force an AD to make a judgment call with (usually) too 237 little information. Moreover, because the community has not been 238 involved, it is much more likely that significant (and valid) 239 objections will be raised. Often, those objections could have been 240 dealt with in advance -- had there been sufficient time to work 241 through them in advance. 243 2) Too much discussion/focus on solutions, rather than showing that 244 support exists for the problem statement itself, and that the 245 problem is well-understood and scoped. The purpose of the BOF is 246 almost never to show that there are already proposed solutions, 247 but to demonstrate that there is a real problem that needs 248 solving, a solution would be beneficial to the community, and that 249 there is a critical mass of community support to actually put in 250 the real work of developing a solution. 252 3) Asking the wrong question during the BOF. Often, BOF organizers 253 feel like there is a need to ask the question "shall we form a 254 WG?". But, unless the question is clear, properly scoped, etc., 255 asking such a question serves no purpose. Even worse, such 256 questions can demonstrate that there is no consensus for the work. 257 The right questions to ask are generally along the lines of: 259 1) Is there support to form a WG with the following charter? (that 260 is, the charter itself is ready, as shown by community 261 support.) 263 2) Does the community think that that the problem statement is 264 clear, well-scoped, solvable, and useful to solve? 266 3) Can I see a show of hands for folk willing to review documents? 267 (or "be document editors", etc.) 269 Examples of unreasonable questions to ask: 271 1) Asking folk to approve or review a charter that is put on 272 screen but has not been posted to the mailing list sufficiently 273 in advance. (You cannot ask folk to approve something they have 274 not seen.) 276 4) Poorly advertised in advance, thus, the BOF itself does not 277 include the "right" participants. This can happen for a number of 278 reasons, including: 280 - BOF is given a "cute" but unintuitive name (or acronym), 281 causing people to not realize that it would be of interest to 282 them 284 - failing to advertise the BOF in advance to the community of 285 people that might be interested. At a minimum, the existence of 286 a proposed BOF should be advertised on the IETF list as well as 287 specific WG lists that are somewhat related. 289 5) Providing agenda time for the "wrong" presentations. There is an 290 (unfortunate) tendency to given anyone who requests agenda time 291 an opportunity to speak. This is often a mistake. Presentations 292 should be limited to those that address the purpose of the BOF. 293 More important, presentations should not distract from the BOFs 294 purpose, or open up ratholes that are a distraction to the more 295 basic purpose of the BOF. Examples of problematic presentations: 297 - presentations on specific solutions, when the purpose of the 298 BOF is to get agreement on the problem statement and the need 299 for a WG. Solutions at this point are too-often "half-baked" 300 and allow discussion to rathole on aspects of the solutions, 301 when instead the focus should be on getting agreement on 302 whether to form a WG. 304 5. Security Considerations 306 This document has no known security implications. 308 6. IANA Considerations 310 This document makes no requests to IANA. 312 7. Acknowledgments 314 8. Normative References 316 9. Informative References 317 10. Author's Address 319 Thomas Narten 320 IBM Corporation 321 3039 Cornwallis Ave. 322 PO Box 12195 - BRQA/502 323 Research Triangle Park, NC 27709-2195 325 Phone: 919-254-7798 326 EMail: narten@us.ibm.com 328 Intellectual Property Statement 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed to 332 pertain to the implementation or use of the technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; nor does it represent that it has 335 made any independent effort to identify any such rights. Information 336 on the procedures with respect to rights in RFC documents can be 337 found in BCP 78 and BCP 79. 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at ietf- 350 ipr@ietf.org. 352 Disclaimer of Validity 354 This document and the information contained herein are provided on an 355 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 356 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 357 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 358 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 359 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 360 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 362 Copyright Statement 364 Copyright (C) The Internet Society (2005). 366 This document is subject to the rights, licenses and restrictions 367 contained in BCP 78, and except as set forth therein, the authors 368 retain all their rights. 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 373 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 374 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 375 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.