[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 rfc5434                                        
INTERNET-DRAFT                                             Thomas Narten
                                                                     IBM
<draft-narten-successful-bof-00.txt>                    October 17, 2005

                Considerations for Having a Successful BOF

                   <draft-narten-successful-bof-00.txt>


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]