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]
