[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 5434

INTERNET-DRAFT                                             Thomas Narten
Intended Status: Informational                                       IBM
<draft-narten-successful-bof-04.txt>                    December 3, 2008

   Considerations for Having a Successful Birds-of-a-Feather (BOF) Session

                   <draft-narten-successful-bof-04.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 June 3, 2008.


Abstract

   This document discusses tactics and strategy for hosting a successful
   IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the
   formation of an IETF Working Group. 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-04.txt                              [Page 1]

INTERNET-DRAFT                                          December 3, 2008


   2.  Recommended Steps........................................    3

   3.  The Importance of Understanding the Real Problem.........    7

   4.  The BOF Itself...........................................    8

   5.  Post-BOF Followup........................................   10

   6.  Pitfalls.................................................   11

   7.  Miscellaneous............................................   13
      7.1.  Chairing............................................   13
      7.2.  On The Need For A BOF...............................   13

   8.  Security Considerations..................................   14

   9.  IANA Considerations......................................   14

   10.  Acknowledgments.........................................   14

   11.  Normative References....................................   14

   12.  Informative References..................................   14

   13.  Author's Address........................................   14


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 not intended
   to result in the formation of a Working Group (WG). For example, a
   BOF might be a one-shot presentation on a particular issue, in order
   to provide information to the IETF Community.  Another example might
   be to host an open meeting to discuss specific open issues with a
   document that is not associated with an active WG, but for which
   face-to-face interaction is needed to resolve issues. 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.




draft-narten-successful-bof-04.txt                              [Page 2]

INTERNET-DRAFT                                          December 3, 2008


    - 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
      success (i.e., in completing the deliverables in its charter in a
      timely fashion)

   Additional details on WGs and BOFs can be found in [RFC2418].


2.  Recommended Steps

   The following steps present a sort of "ideal" sequence for hosting a
   BOF where the goal is formation of a working group. The important
   observation to make here is that most of these involve planning for
   and engaging in significant public discussion, and allowing for
   sufficient time for iteration and broad participation, so that much
   of the work of the BOF can be done on a public mailing list in
   advance of -- rather than during --- the BOF itself.

   It is also important to recognize the timing constraints. As
   described in detail below, the deadline for scheduling BOFs is
   approximately six weeks prior to an IETF meeting. Working backwards
   from that date, taking into consideration the time required to write
   drafts, have public discussion, allow the ADs to evaluate the
   proposed BOF, etc., the right time to start preparing for a BOF is
   almost certainly the meeting prior to the one in which the BOF is
   desired. By implication, starting the work aimed at leading to a BOF
   only 2 months prior to an IETF meeting is in most cases waiting too
   late, and will likely result in the BOF being delayed until the
   following IETF meeting.

   The recommended steps for a BOF are as follows:

   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.

      Possible substeps:



draft-narten-successful-bof-04.txt                              [Page 3]

INTERNET-DRAFT                                          December 3, 2008


      a) Consider whether the work might already fall within scope of an
         existing Working Group, in which case a BOF might not even be
         necessary. Individual Working Group charters can be found at
         http://www.ietf.org/html.charters/wg-dir.html and indicate what
         a group is scoped to work on.

      b) Select an area or areas where the work most naturally fits in
         by identifying WGs that most closely relate to the proposed
         work. Note that it is not uncommon to find that a work item
         could easily fit into two (or more) different areas and that no
         one area is the obvious home.

      c) Consult with specific WGs to see whether there is interest or
         whether the work is in scope. This can be done by posting
         messages directly to WG mailing lists, contacting the WG
         chairs, or contacting individuals known to participate in a
         particular WG (e.g., from their postings or from documents they
         have authored).

      d) Consult with an area-specific mailing list about possible
         interest. (Most areas have their own area-specific mailing
         lists. Follow the links under each area at
         http://www.ietf.org/html.charters/wg-dir.html to find details.)

      e) Produce one or more Internet Drafts, describing the problem
         and/or related work. It cannot be emphasized enough that for
         the BOF, drafts relating to understanding the problem space are
         much more valuable than drafts proposing specific solutions.


      Timeline: This step can easily take 1-2 months; hence, begin 3-4
      months before an IETF meeting.

   2) The group may (or may not) approach an Area Director (or other
      recognized or experienced leader) to informally float the BOF and
      get feedback on the proposed work, scope of the charter, specific
      steps that need to be taken before submitting a formal BOF
      request, etc. By "leader", we mean persons with significant IETF
      experience who can provide helpful advice; individuals who have
      successfully hosted BOFs before, current or former WG chairs, IESG
      or IAB members, would be good candidates.

      The dividing line between step 1) and 2) is not exact. At some
      point, one will need to approach one or more Area Directors (ADs)
      with a specific proposal that can be commented on. Step 1) helps
      shape an idea into something concrete enough that an AD can
      understand the purpose and provide concrete feedback. On the other
      hand, one shouldn't spend too much time on step 1) if the answer



draft-narten-successful-bof-04.txt                              [Page 4]

INTERNET-DRAFT                                          December 3, 2008


      at step 2) would turn out to be "oh, we had a BOF on that once
      before, have you reviewed the archives?". Thus, there may be some
      iteration involving going back and forth between steps 1) and 2).
      Also, a quick conversation with an AD might lead them to suggest
      some specific individuals or WGs you should consult with.

      It may turn out that it is unclear which area proposed work best
      fits in. In such cases, when approaching multiple ADs, it is best
      to approach the ADs approximately simultaneously, state that you
      are unsure of which area the work fits in, and ask for advice
      (e.g., by stating "I'm not sure which area this work best fits
      under, but it looks like it might be Internet or Security or
      both"). When contacting multiple ADs, it is strongly advised that
      you inform them of which other ADs you are conversing with. In
      particular, it is usually counterproductive and not advisable to
      go "AD shopping", where if one AD gives you an answer you don't
      like, you go to another, without telling him/her what the first AD
      said, in the hopes of getting a more favorable answer.

      To summarize, steps 1) and 2) involve a lot of "socializing an
      idea," that is, having discussions with a number of different
      people to try and get agreement on the problem and the need for
      and appropriateness of having a BOF. How much such discussion is
      needed is very subjective, but it is critical in terms of getting
      agreement that a BOF is appropriate. One way to tell if you are
      close to getting it right: if when talking to someone about your
      idea for the first time, they quickly agree that a BOF seems in
      order and don't have any major concerns.

      Timeline: Steps 1-2) can easily take 1-2 months; hence, begin 3-4
      months before an IETF meeting.

   3) Create a public mailing list and post a "call for participation"
      for the proposed BOF topic on various mailing lists (e.g., the
      ietf list). The call for participation advertises that a
      "community of interest" is being formed to gauge whether there is
      sufficient interest to host 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: This step can easily take 1 month or longer; it also
      needs to be started well before the Internet-Drafts cutoff (to
      allow participants to submit drafts); hence begin 2.5-3.5 months
      before the IETF meeting.

   4) Have substantive mailing list discussion. It is not enough for a



draft-narten-successful-bof-04.txt                              [Page 5]

INTERNET-DRAFT                                          December 3, 2008


      handful of people to assert that they want a BOF; there needs to
      be broader community interest. A public mailing list allows ADs
      (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 emphasis
      should be on getting agreement on the problem statement;
      discussions about specific solutions tends to be distracting and
      unhelpful.

      Timeline: this step can easily take 1 month or longer; hence begin
      2.5 months before the IETF meeting.

   5) Submit a formal request to have a BOF. Instructions for submitting
      a formal request can be found at
      http://www.ietf.org/instructions/MTG-SLOTS.html and
      http://www.ietf.org/ietf/1bof-procedures.txt.  Note that as part
      of making a formal request, the organizers must identify the Area
      the BOF will be held in (the Area Directors of that Area will be
      required to approve the BOF), include a proposed BOF agenda,
      estimate the attendance, list conflicts with other sessions that
      should be avoided, etc.

      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.

      Note: it almost goes without saying that without one or more
      Internet Drafts at this point, it is generally pointless to ask an
      AD to approve a BOF.

      Timeline: The Secretariat publishes an "important meeting dates"
      calendar along with meeting information. There is a firm deadline
      (about six weeks prior to the meeting) for submitting a formal BOF
      scheduling request. Note: that at the time of the deadline, an AD
      will need to have sufficient information about the BOF to approve
      or reject the request, so all of the previous steps will need to
      have completed.

   6) During the 2-4 weeks before an IETF (assuming a BOF has been
      approved and 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



draft-narten-successful-bof-04.txt                              [Page 6]

INTERNET-DRAFT                                          December 3, 2008


      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 during the BOF itself. 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
      answered affirmatively.

   9) At the meeting, but before the BOF takes place, plan a meeting
      with all of the presenters to have them meet each other, review
      the agenda and make sure everyone understands what is expected of
      them (e.g., what time constraints they will be under when
      presenting). Use this time to also work through any disagreements
      that still remain. Do the same "in the hallway" with other
      interested parties!

   10) Consult the tutorial schedule and consider attending relevant
      tutorial sessions ("Working Group Chair Training", "Working Group
      Leadership Training", etc.).  This is especially the case if you
      are considering being the chair of a proposed WG. Since the role
      of the WG chair and BOF chair have a number of parallels, a number
      of the topics covered in the tutorial apply to hosting a BOF and
      developing a charter.


3.  The Importance of Understanding the Real Problem

   Throughout the process of chartering new work in the IETF, a key
   issue is understanding (and finding consensus) on what the real,
   underlying problem is that the customer, operator or deployer of a
   technology has and that the WG needs to address. When a WG finishes
   an effort, the WG's output will only be useful if it actually solves
   a real compelling problem faced by the actual user of the technology
   (i.e., the customer or operator). Unfortunately, there have been more
   than a few IETF WGs whose output was not adopted, and in some of
   those cases the cause was a lack of understanding of the real problem



draft-narten-successful-bof-04.txt                              [Page 7]

INTERNET-DRAFT                                          December 3, 2008


   the operator had.  In the end, the WG's output simply didn't address
   the right problem.

   Another issue that can happen is for discussions about specific (or
   competing) solution approaches to effectively stalemate with the WG
   (or BOF) unable to make progress. In some of those cases, the
   arguments about the appropriateness of specific technologies are
   actually proxies for the question of whether a proposed approach
   adequately addresses the problem. If there is a lack of clarity about
   the actual underlying problem to be solved, there may well be
   unresolvable arguments about the suitability of a particular
   technical approach, depending on one's view of the actual problem and
   the constraints associated with it. Hence, it is critical for all
   work to be guided by a clear and shared understanding of the
   underlying problem.

   The best description and understanding of an actual problem usually
   comes from the customer, operator or deployer of a technology. They
   are the ones that most clearly understand the difficulties they are
   having (that need addressing) and they are the ones who will have to
   deploy any proposed solution. Thus, it is critical to hear their
   voice when formulating the details of the problem statement.
   Moreover, when evaluating the relative merits of differing solution
   approaches, it is often helpful to go back to the underlying problem
   statement to provide guidance in selecting the more appropriate
   approach.


4.  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?

   Or, stated differently, after the BOF is over, by what criteria will
   you decide whether the BOF was successful or not?

   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 distractions, 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?



draft-narten-successful-bof-04.txt                              [Page 8]

INTERNET-DRAFT                                          December 3, 2008


   One of the best ways to ensure a "yes" answer to the above, is by
   performing adequate preparation before the BOF to ensure that the
   community as a whole already 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 3 months prior to the
      IETF meeting).

   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, keep 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.


   Another important reason for holding a BOF is to establish an
   understanding of how the attendees (and the larger community) feel
   about the proposed work.  Do they understand and agree on the problem
   that needs solving? Do they agree the problem is solvable, or that
   new protocol work is needed? To better understand the degree of
   agreement, it is useful to ask the audience questions.

   Whenever asking questions, it is important to ask the right ones --
   questions that show where there is agreement and questions that probe
   the details around where agreement is lacking.  Good questions
   typically focus on aspects of the problem in a piecewise fashion,
   establishing areas of consensus and identifying areas where
   additional work is needed.  Poor questions do not serve to focus
   future discussion where it is needed.  The following are examples of
   questions that are often useful to ask.

   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 comment on the mailing list?)

   4) Who would be willing to serve as an editor for the following



draft-narten-successful-bof-04.txt                              [Page 9]

INTERNET-DRAFT                                          December 3, 2008


      document(s)? (BOF chairs should take note of individuals who raise
      their hands, but it is also a useful gauge to see there is a
      critical mass of editors to work on all the documents that are to
      be produced.)

   5) Does the community think that given the charter revisions
      discussed during the BOF (subject to review and finalization on
      the mailing list), a WG should be formed?

   6) How many people feel that a WG should not be formed? (If the
      number of no responses is significant, it would help to ask those
      saying no why they are opposed.)

   7) Before asking a particular question, it is sometimes very
      appropriate to ask: Do people feel like they have sufficient
      information to answer the following question or is it premature to
      even ask the question?

   Unfortunately, it is also easy to ask the wrong questions. Some
   examples are given in a later section.


5.  Post-BOF Followup

   After the BOF has taken place, it is advisable to take assessment of
   how well things went and what the next steps are. The ADs should be
   included in this assessment. Some things to consider:

   1) Did the BOF go well enough that the logical next step is to focus
      on refining the charter and become a WG before the next IETF
      meeting?  If so, there will almost certainly be additional
      discussion on the mailing list to refine the charter and work out
      a few remaining items.

      Note that it can be difficult to determine in some cases whether a
      WG is a feasible next step. Much will depend on details of how the
      BOF went and/or whether the contentious items can either be
      resolved on the mailing list, or can simply be excluded from the
      charter and dealt with later (if at all). Much will depend on the
      relevant AD's assessment of whether the proposed work is ready to
      move forward. Sometimes, even a seemingly contentious BOF can
      result in a WG being formed quickly -- provided the charter is
      scoped appropriately.

      If the next step is to attempt to form a WG, the charter needs to
      be finalized on the BOF-specific mailing list. Once done, the IESG
      can be asked to formally consider the charter. The IESG then
      (usually) posts the proposed charter to the IETF list for



draft-narten-successful-bof-04.txt                             [Page 10]

INTERNET-DRAFT                                          December 3, 2008


      community feedback and makes a decision based in part on the
      feedback it receives.

   2) It may be the case that enough additional work still needs to take
      place that aiming for a second (and final) BOF makes more sense.
      In that case, many of the steps outlined earlier in this document
      would be repeated, thought at a faster pace.

      The expectations for a second BOF are generally higher than those
      for an initial BOF. In addition to the work done up through the
      first BOF, the first BOF will have highlighted the key areas where
      additional work is needed. The time leading up to the second BOF
      will need to be spent working through those outstanding issues.
      Second BOFs should not be a repeat of the first BOF, with the same
      issues being raised and the same (unsatisfactory) responses
      provided. The second BOF needs to show that all previously-
      identified issues have been resolved and that formation of a WG is
      now in order.





6.  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
      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, it is
      believed that a solution is achievable and that there is a
      critical mass of community support to actually put in the real



draft-narten-successful-bof-04.txt                             [Page 11]

INTERNET-DRAFT                                          December 3, 2008


      work of developing a solution.

   3) Asking the wrong question during the BOF. Often, BOF organizers
      feel like they need for a "show of hands" on specific questions.
      But, unless a question is clear, well scoped, focused enough to
      establish where there is agreement (and where not), etc., asking
      such a question serves little purpose. Even worse, asking poor
      questions can frustrate the BOF participants and lead to
      additional questions at the microphone, derailing the focus of the
      BOF.

      Examples of an unreasonable question 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.)

      2) Asking multi-part questions in which it is not clear (in
         advance) what all of the exact questions will be and which
         choices a participant needs to choose from.

   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),
         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



draft-narten-successful-bof-04.txt                             [Page 12]

INTERNET-DRAFT                                          December 3, 2008


          whether to form a WG.


    6) Poor time management, leading to insufficient time for discussion
       of the key issues (this is often closely related to 5). When
       presentations run over their allotted time, the end result is
       either squeezing someone else's presentation, or having
       insufficient discussion time. Neither is acceptable nor helpful.
       BOF chairs need to give presenters just enough time to make key
       points -- and no more. It may well be helpful to go over a
       presenter's slides in advance, to ensure they are on-topic and
       that they will fit within the time slot.


7.  Miscellaneous


7.1.  Chairing

   BOF organizers often assume that they will be chairing a BOF (and the
   eventual WG). Neither assumption is always true. ADs need to ensure
   that a BOF runs smoothly and is productive. For some topics, it is a
   given that the BOF will be contentious. In such cases, ADs may want
   to have a more experienced person chairing or co-chairing the BOF.
   Also, those interested in organizing the BOF often are the most
   interested in driving a particular technology (and may have strongly
   held views about what direction an effort should take). Working
   groups are often more effective when passionately-involved parties
   are allowed to focus on the technical work, rather than on managing
   the WG itself. Thus do not be surprised (or offended!)  if the AD
   want to pick one or more co-chairs for either the BOF or a follow-on
   WG.


7.2.  On The Need For A BOF

   This document highlights the need for allowing for and actively
   engaging in a broad public discussion on the merits of forming a WG.
   It might surprise some, but there is no actual process requirement to
   have a BOF prior to forming a WG. The actual process requirement is
   simply that the IESG (together with the AD(s) sponsoring the work)
   approve a formal charter as described in [RFC2418]. In practice, BOFs
   are used to engage the broader community on proposed work and to help
   produce an acceptable charter.

   There are two observations that can be made here. First, BOFs are
   often held not because they are (strictly speaking) required, but
   because it is assumed they are needed or because ADs feel that a BOF



draft-narten-successful-bof-04.txt                             [Page 13]

INTERNET-DRAFT                                          December 3, 2008


   would be beneficial in terms of getting additional public
   participation. Hence, those interested in forming a WG should give
   serious consideration to using the steps outlined above not just for
   the purposes of leading to a BOF, but to convince the IESG and
   broader community that a BOF is not even needed, as there is already
   demonstrated strong consensus that a WG should be formed. Second, the
   IESG should not forget that BOFs are simply a tool, and may not even
   be the best tool in every situation.


8.  Security Considerations

   This document has no known security implications.


9.  IANA Considerations

   This document makes no requests to IANA.


10.  Acknowledgments

   This document has benefited from specific feedback from Brian
   Carpenter, Spencer Dawkins, John Klensin, Mark Townsley and Bert
   Wijnen.


11.  Normative References



12.  Informative References

   [RFC2418] "IETF Working Group Guidelines and Procedures," S. Bradner,
        September 1998.


13.  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




draft-narten-successful-bof-04.txt                             [Page 14]

INTERNET-DRAFT                                          December 3, 2008


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.


Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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-04.txt                             [Page 15]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/