INTERNET-DRAFT Thomas Narten IBM October 17, 2005 Considerations for Having a Successful BOF Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft expires on April 11, 2006.b Abstract This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) Session. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 draft-narten-successful-bof-00.txt [Page 1] INTERNET-DRAFT October 17, 2005 2. Ideal Steps.............................................. 3 3. The BOF Itself........................................... 5 4. Pitfalls................................................. 5 5. Security Considerations.................................. 7 6. IANA Considerations...................................... 7 7. Acknowledgments.......................................... 7 8. Normative References..................................... 7 9. Informative References................................... 7 10. Author's Address...................................... 8 1. Introduction This document provides suggestions on how to host a successful BOF at an IETF meeting. It is hoped that by documenting the methodologies that have proven successful, as well as listing some pitfalls, BOF organizers will improve their chances of hosting a BOF with a positive outcome. There are many reasons for hosting a BOF. Some BOFs are intended to be a one-shot presentation on a particular issue, in order to provide information to the IETF Community. Such BOFs are not intended to result in the formation of a Working Group (WG). In many cases, however, the intent is to form a WG. In those cases, the goal of the BOF is to demonstrate that the community has agreement that: - there is a problem that needs solving, and the IETF is the right group to attempt solving it. - there is a critical mass of participants willing to work on the problem (e.g., write drafts, review drafts, etc.) - the scope of the problem is well defined and understood, that is, people generally understand what the WG will work on (and what not) and what its actual deliverables will be - there is agreement that the specific deliverables (i.e., proposed documents) are the right set - it is believed that the WG has a reasonable probability of having draft-narten-successful-bof-00.txt [Page 2] INTERNET-DRAFT October 17, 2005 success (i.e., in completing the deliverables in its charter in a timely fashion) 2. Ideal Steps The following steps present a sort of "ideal" sequence for hosting a BOF. The important observation to make here is that most of these involve having public discussion, with sufficient advance time, so that much of the work of the BOF can be done on a public mailing list -- in advance -- rather than during the BOF itself. 1) A small group of individuals gets together privately, discusses a possible problem statement, and identifies the work to be done. The group acts as a sort of "design team" to formulate a problem statement, identify possible work items, and propose an agenda for a BOF. Timeline: well before the BOF scheduling deadline (e.g., months before IETF meeting) 2) The group may (or may not) approach an Area Director (or other recognized leader) to informally float the BOF and get feedback on the proposed work, scope of the charter, specific steps the need to be taken before sumbitting a formal BOF request, etc.. (Note, this step can be skipped in some cases.) Timeline: well before the BOF scheduling deadline (e.g., at least 2 months before IETF meeting) 3) A public mailing list is created, and a proposed BOF agenda is posted on various mailing lists (e.g, the ietf list) to advertise that a "community of interest" is being formed to gauge whether there is sufficient interest in hosting a BOF. The goal is to draw in other interested potential participants, to allow them to help shape the BOF (e.g., by giving them time to write a draft, ask for agenda time, help scope the work of the proposed work, argue that a BOF is (or is not) needed, etc.) Timeline: well before BOF scheduling deadline (e.g., 1-2 months before BOF scheduling deadline) 4) Have real mailing list discussion. It is not enough for a handful of people to assert that they want a BOF; there needs to be broader community interest. A public mailing list allows Area Directors (and others) to gauge how much interest there really is on a topic area, as well as gauge how well the problem statement has been scoped, etc. At this phase of the BOF preparation, the draft-narten-successful-bof-00.txt [Page 3] INTERNET-DRAFT October 17, 2005 emphasis should be on getting agreement on the problem statement; discussions about specific solutions tends to be distracting and unhelpful. 5) Once there has been discussion on the mailing list, make a formal request for a BOF. [XXX: need to cite the specific steps.] Note that as part of making a formal request, the organizers identify the Area Directors (i.e, proposed Area) appropriate for the BOF topic. If the previous steps have been followed, the Area Directors (ADs) should be in a good position to gauge whether there is sufficient interest to justify approval of a BOF. Timeline: minimum of 2 weeks before BOF scheduling deadline. 6) During the 2-4 weeks before an IETF (assuming a BOF has been scheduled), the focus (on the mailing list) should be on identifying areas of agreement and areas of disagreement. Since disagreements or "lack of consensus" tends to be the main reason for not forming a WG, focusing on those specific areas where "lack of consensus" exists is critically important. In general, only after those disagreements have been resolved will a WG be formed, thus, the main goal should be to find consensus and work through the areas of disagreement. Alternatively, a specific case should be made about why the charter as it is written is the best one, in spite of the stated opposition. 7) Prior to the BOF, it is critical to produce a proposed charter and iterate on it on the mailing list to attempt to get a consensus charter. Ultimately, the most important question to ask during a BOF is: "should a WG with the following charter be formed?". It goes without saying that a charter with shortcomings (no matter how seemingly trivial to fix) will not achieve consensus if folk still have issues with the specific wording. 8) Decide what questions will be asked of the room. Since the exact wording of the questions is critical (and hard to do on the fly), it is strongly recommended that those questions be floated on the mailing list and with the ADs prior to the BOF, so people understand what they will be asked to give approval to, and to allow the questions to be modified (prior to the BOF) to remove ambiguities, etc. Likewise, discussing those questions in advance may lead to refinement of the charter so that the questions can be affirmatively answered draft-narten-successful-bof-00.txt [Page 4] INTERNET-DRAFT October 17, 2005 3. The BOF Itself For the BOF itself, it is critically important to focus on the bottom line: What is it that one is attempting to achieve during the BOF? A good BOF organizer keeps a firm focus on the purpose of the BOF and crafts an agenda in support of that goal. Just as important, presentations that do not directly support the goal should be excluded, as they often become ratholes, sow confusion, and otherwise take focus away from the purpose of the BOF. If the goal is to form a WG, everything should lead to an (obvious) answer to the following question: Does the room agree that the IETF should form a WG with the following (specific) charter? One of the best ways to ensure a "yes" answer to the above, is by performing adequate preparation before the BOF to ensure that that the community as a whole agrees that the answer is "yes". How does one do that? One good way seems to be: 1) Have a public discussion with sufficient time to allow iteration and discussion. (hence, start a minimum of 2 months before the BOF scheduling deadline). 2) Work with the community to iterate on the charter, and be sure to address the significant concerns that are being raised. (One can address the concerns in advance -- and get advance agreement, or one can have those concerns be raised (again) during the BOF -- in which case it is likely that the proposed charter will not be good enough to get agreement on during the actual BOF). 3) During the BOF, have the agenda tightly focused on supporting the need for the WG and otherwise making the case that the group has identified a clearly-scoped charter, and has agreement on what the set of deliverables should be. 4. Pitfalls Over the years, a number of pitfalls have been (repeatedly) observed: 1) Waiting too long before getting started. It is very difficult to prepare for a BOF on short notice. Moreover, ADs are placed in a no-win situation when asked to approve a BOF for which the draft-narten-successful-bof-00.txt [Page 5] INTERNET-DRAFT October 17, 2005 community has not had a chance to participate. Steps 1-4 in Section 2 above are designed to show the ADs that there is community support for a particular effort. Short-circuiting those steps force an AD to make a judgment call with (usually) too little information. Moreover, because the community has not been involved, it is much more likely that significant (and valid) objections will be raised. Often, those objections could have been dealt with in advance -- had there been sufficient time to work through them in advance. 2) Too much discussion/focus on solutions, rather than showing that support exists for the problem statement itself, and that the problem is well-understood and scoped. The purpose of the BOF is almost never to show that there are already proposed solutions, but to demonstrate that there is a real problem that needs solving, a solution would be beneficial to the community, and that there is a critical mass of community support to actually put in the real work of developing a solution. 3) Asking the wrong question during the BOF. Often, BOF organizers feel like there is a need to ask the question "shall we form a WG?". But, unless the question is clear, properly scoped, etc., asking such a question serves no purpose. Even worse, such questions can demonstrate that there is no consensus for the work. The right questions to ask are generally along the lines of: 1) Is there support to form a WG with the following charter? (that is, the charter itself is ready, as shown by community support.) 2) Does the community think that that the problem statement is clear, well-scoped, solvable, and useful to solve? 3) Can I see a show of hands for folk willing to review documents? (or "be document editors", etc.) Examples of unreasonable questions to ask: 1) Asking folk to approve or review a charter that is put on screen but has not been posted to the mailing list sufficiently in advance. (You cannot ask folk to approve something they have not seen.) 4) Poorly advertised in advance, thus, the BOF itself does not include the "right" participants. This can happen for a number of reasons, including: - BOF is given a "cute" but unintuitive name (or acronym), draft-narten-successful-bof-00.txt [Page 6] INTERNET-DRAFT October 17, 2005 causing people to not realize that it would be of interest to them - failing to advertise the BOF in advance to the community of people that might be interested. At a minimum, the existence of a proposed BOF should be advertised on the IETF list as well as specific WG lists that are somewhat related. 5) Providing agenda time for the "wrong" presentations. There is an (unfortunate) tendency to given anyone who requests agenda time an opportunity to speak. This is often a mistake. Presentations should be limited to those that address the purpose of the BOF. More important, presentations should not distract from the BOFs purpose, or open up ratholes that are a distraction to the more basic purpose of the BOF. Examples of problematic presentations: - presentations on specific solutions, when the purpose of the BOF is to get agreement on the problem statement and the need for a WG. Solutions at this point are too-often "half-baked" and allow discussion to rathole on aspects of the solutions, when instead the focus should be on getting agreement on whether to form a WG. 5. Security Considerations This document has no known security implications. 6. IANA Considerations This document makes no requests to IANA. 7. Acknowledgments 8. Normative References 9. Informative References draft-narten-successful-bof-00.txt [Page 7] INTERNET-DRAFT October 17, 2005 10. Author's Address Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: narten@us.ibm.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. draft-narten-successful-bof-00.txt [Page 8] INTERNET-DRAFT October 17, 2005 Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. draft-narten-successful-bof-00.txt [Page 9]