One document matched: draft-narten-successful-bof-02.txt
Differences from draft-narten-successful-bof-01.txt
INTERNET-DRAFT Thomas Narten
IBM
<draft-narten-successful-bof-02.txt> March 5, 2007
Considerations for Having a Successful BOF
<draft-narten-successful-bof-02.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 in six months.
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-02.txt [Page 1]
INTERNET-DRAFT March 5, 2007
2. Ideal Steps.............................................. 3
3. The BOF Itself........................................... 7
4. Pitfalls................................................. 8
5. Miscellaneous............................................ 10
5.1. Chairing............................................ 10
5.2. On The Need For A BOF............................... 11
6. Security Considerations.................................. 11
7. IANA Considerations...................................... 11
8. Acknowledgments.......................................... 11
9. Normative References..................................... 12
10. Informative References.................................. 12
11. Author's Address........................................ 12
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
draft-narten-successful-bof-02.txt [Page 2]
INTERNET-DRAFT March 5, 2007
- 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)
2. Ideal 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, with 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 one month prior to the 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
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 too late, and will
likely result in the BOF being delayed until the following IETF
meeting.
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:
a) Consider whether the work might already fall within scope for
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
draft-narten-successful-bof-02.txt [Page 3]
INTERNET-DRAFT March 5, 2007
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
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
draft-narten-successful-bof-02.txt [Page 4]
INTERNET-DRAFT March 5, 2007
(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 different 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 agenda 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-3 months
before the IETF meeting.
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 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
draft-narten-successful-bof-02.txt [Page 5]
INTERNET-DRAFT March 5, 2007
2 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 area Area Directors 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 1 month 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
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
draft-narten-successful-bof-02.txt [Page 6]
INTERNET-DRAFT March 5, 2007
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
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 potential 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 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 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:
draft-narten-successful-bof-02.txt [Page 7]
INTERNET-DRAFT March 5, 2007
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.
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
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
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.,
draft-narten-successful-bof-02.txt [Page 8]
INTERNET-DRAFT March 5, 2007
asking such a question serves no purpose. Even worse, such
questions can demonstrate that there is no consensus (yet) for the
work and thus no WG should be formed. 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 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 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 ask the following question?
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),
causing people to not realize that it would be of interest to
them
draft-narten-successful-bof-02.txt [Page 9]
INTERNET-DRAFT March 5, 2007
- 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.
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 alloted 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.
5. Miscellaneous
5.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 the
management work. Thus do not be surprised (or offended!) if the AD
draft-narten-successful-bof-02.txt [Page 10]
INTERNET-DRAFT March 5, 2007
want to pick one or more co-chairs for either the BOF or a followon
WG.
5.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 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 shold 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.
6. Security Considerations
This document has no known security implications.
7. IANA Considerations
This document makes no requests to IANA.
8. Acknowledgments
This document has benefited from specific feedback from Brian
Carpenter, Spencer Dawkins, John Klensin, Mark Townsley and Bert
Wijnen.
draft-narten-successful-bof-02.txt [Page 11]
INTERNET-DRAFT March 5, 2007
9. Normative References
10. Informative References
[RFC2418] "IETF Working Group Guidelines and Procedures," S. Bradner,
September 1998.
11. 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.
draft-narten-successful-bof-02.txt [Page 12]
INTERNET-DRAFT March 5, 2007
Copyright Statement
Copyright (C) The IETF Trust (2007).
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-02.txt [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-23 04:19:48 |