doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc5434.txt b/doc/rfc/rfc5434.txt
new file mode 100644
index 0000000..741bc9a
--- /dev/null
+++ b/doc/rfc/rfc5434.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                          T. Narten
+Request for Comments: 5434                                           IBM
+Category: Informational                                    February 2009
+
+
+Considerations for Having a Successful Birds-of-a-Feather (BOF) Session
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (http://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Recommended Steps ...............................................2
+   3. The Importance of Understanding the Real Problem ................7
+   4. The BOF Itself ..................................................8
+   5. Post-BOF Follow-Up ..............................................9
+   6. Pitfalls .......................................................10
+   7. Miscellaneous ..................................................12
+      7.1. Chairing ..................................................12
+      7.2. On the Need for a BOF .....................................13
+   8. Security Considerations ........................................13
+   9. Acknowledgments ................................................13
+   10. Informative Reference .........................................13
+
+
+
+
+
+Narten                       Informational                      [Page 1]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+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.
+
+      - 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 it won't) 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 the formation of a working group.  The
+   important observation to make here is that most of these steps
+   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.
+
+
+
+
+Narten                       Informational                      [Page 2]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+   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
+   long, 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 sub-steps:
+
+      a) Consider whether the work might already fall within the 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 the area or areas in which the work most naturally fits
+         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.)
+
+
+
+
+
+
+Narten                       Informational                      [Page 3]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+      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, and
+      IESG or IAB members would be good candidates.
+
+      The dividing line between steps 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 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 in which area the proposed work
+      best fits.  In such cases, when approaching multiple ADs, it is
+      best to approach the ADs approximately simultaneously, state that
+      you are unsure in which area the work fits, 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 attempt gaining 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
+
+
+
+Narten                       Informational                      [Page 4]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+      you are close to getting it right: 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
+      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 tend 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
+      in which the BOF will be held (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.
+
+
+
+Narten                       Informational                      [Page 5]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+      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 disagreement, 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 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 to the ADs prior to the BOF.  This
+      will enable people to understand what they will be asked to
+      approve and will allow the questions to be modified (prior to the
+      BOF) to remove ambiguities, etc.  Likewise, discussing these
+      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
+
+
+
+
+
+Narten                       Informational                      [Page 6]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+      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
+   the operator had.  In the end, the WG's output simply didn't address
+   the right problem.
+
+   Another issue that can happen is discussions about specific (or
+   competing) solution approaches effectively stalemating the WG (or
+   BOF), making it 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 have
+   (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 for
+   guidance in selecting the more appropriate approach.
+
+
+
+Narten                       Informational                      [Page 7]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+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 or not the BOF was successful?
+
+   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?
+
+   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 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.
+
+
+
+Narten                       Informational                      [Page 8]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+   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 the problem statement is clear,
+      well-scoped, solvable, and useful to solve?
+
+   3) Can I see a show of hands of folk willing to review documents (or
+      comment on the mailing list)?
+
+   4) Who would be willing to serve as an editor for the following
+      document(s)?  (BOF chairs should take note of individuals who
+      raise their hands, but it is also a useful gauge to see if 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 Follow-Up
+
+   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:
+
+
+
+
+
+
+Narten                       Informational                      [Page 9]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+   1) Did the BOF go well enough that the logical next step is to focus
+      on refining the charter and becoming 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 simply be excluded from the
+      charter and dealt with later (if at all).  Much will also 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
+      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, though 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
+
+
+
+Narten                       Informational                     [Page 10]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+      community support for a particular effort.  Short-circuiting those
+      steps forces 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 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 they need 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 unreasonable questions to ask:
+
+      - 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.)
+
+      - 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:
+
+      - giving the BOF a "cute" but unintuitive name (or acronym),
+        preventing people from realizing that it would be of interest to
+        them.
+
+
+
+
+
+
+Narten                       Informational                     [Page 11]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+      - 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
+        on specific WG lists that are somewhat related.
+
+   5) Providing agenda time for the "wrong" presentations.  There is an
+      (unfortunate) tendency to give 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 BOF's
+      purpose, or open up ratholes that are a distraction to the more
+      basic purpose of the BOF.  An example 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.
+        Instead, the focus should be on getting agreement on 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
+      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
+   wants to pick one or more co-chairs for either the BOF or a follow-on
+   WG.
+
+
+
+Narten                       Informational                     [Page 12]
+
+RFC 5434                Successful BOF Sessions            February 2009
+
+
+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
+   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 creating a BOF, but to convince the IESG and the
+   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.  Acknowledgments
+
+   This document has benefited from specific feedback from Jari Arkko,
+   Brian Carpenter, Dave Crocker, Spencer Dawkins, Lisa Dusseault, Pasi
+   Eronen, John Klensin, Tim Polk, Mark Townsley, and Bert Wijnen.
+
+10.  Informative Reference
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, September 1998.
+
+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
+
+
+
+Narten                       Informational                     [Page 13]
+