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

Note: This ballot was opened for revision 04 and is now closed.

(Jari Arkko) (was Discuss) Yes

(Lars Eggert) Yes

(Pasi Eronen) Yes

Comment (2008-11-05 for -)
No email
send info
I think this a very useful document, and I'm balloting "Yes".

Some thoughts that perhaps could be considered if the document
is updated (but these are not absolutely necessary by any means):

Would it be useful to say more about what happens after the
face-to-face BOF session? For example, in the case of ALTO, the BOF
session did not reach consensus about a specific charter.  Apparently,
some people were surprised that the discussion continued (and reach
rough consensus) on the mailing list -- I guess they were expecting a
2nd BOF about the topic. IMHO having a 2nd BOF is probably not very
useful if there hasn't been any discussion on the mailing lists in
between -- but it does occasionally happen anyway. If you have
some experiences or advice to share about this topic, I think
that would be a valuable addition to the document.

Another topic is how to define the scope. In several places, the
document emphasizes focusing more on the problem being solved, than
the (possibly multiple) solution proposals.  While I agree in theory,
applying this advice can IMHO be difficult in practice (and has been
the source of problems for BOFs I've seen).

One aspect is that if there already are detailed protocol
specifications as Internet-Drafts, the authors of those drafts are not
necessarily very good in answering the question "what's the problem
being solved by your draft" in a way that others would grasp. Or at
least the answer might be very specific to their favorite solution.

A second aspect is that one person's problem can be somebody else's
solution. If the draft authors say they're solving A, you can always
ask what's the problem B being solved by solving A? And so on -- this
quest for the next-higher-level goal/problem could in theory continue
indefinitely, but in my experience, it's not easy to determine what
level is the best for BOF success.

For example, in the OAUTH BOF in IETF73, my guess (I haven't seen any
charter proposal text, so this is a wild guess, in fact) is that the
BOF would focus on whether IETF should start work on "OAuth 1.1"
(something improving the current OAuth 1.0, but not radically
different). That's probably more likely to result in success than
starting from blank slate problem "how can one web site access your
data on another site" (given this problem, it's certainly possible to
imagine a wide range of solutions quite different from OAuth 1.0,
reusing whatever your favourite security technology is -- X.509 proxy
certificates, SAML, SPKI, Keynote delegation, Kerberos, identity-based
crypto, Liberty ID-WSF, WS-*, elliptic curves, ...). I don't have good
suggestions on what the document should exactly say, other than
perhaps highlight that the "problem" can be defined in many ways, and
both making it too wide (making the solution space too large to be
manageable and discussable in a 2-3 hour session) or too narrow
(making the solution space narrow to a single existing draft) can lead
to unsuccessful BOF.

Some additional minor comments:

In couple of places, the document says the deadline for scheduling
BOFs is approximately one month prior to the IETF meeting; for recent
IETFs (IETF 72 and 73), it's been 6 or 7 weeks.

The document has several URLs pointing to pages on  It's
quite possible that the currently ongoing website redesign project
will break them. (But I'm not suggesting removing the URLs, and I
don't have a good solution in mind, either.)

(Russ Housley) (was Discuss, Yes) Yes

(Cullen Jennings) Yes

(Dan Romascanu) Yes

(Ross Callon) No Objection

(Chris Newman) No Objection

(Tim Polk) No Objection

Comment (2008-11-05 for -)
No email
send info
This is a very useful document, and I support publication as an RFC.  I believe the
draft would be improved if a couple of issues, but given the document's proven utility
as-is, I cannot justify a discuss.  

I have issues with both the structure and content of item 3) "asking the wrong question"
in Section 4, "Pitfalls".  

First on structure, Item 3) includes a half page list of the *right* questions to ask
during a BOF.  I think this is extremely important material, and entirely misplaced.
I believe it should be moved to Section 3, "The BOF Itself".  The remaining material
under item 3) is focused on the problem of wrong questions, and should stay in
Section 4.

The following is an excerpt from the opening paragraph in item 3):

                                                                         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 (yet) for the
      work and thus no WG should be formed.

WRT content, I have real issues with the last sentence in the quoted text,
"Even worse..."  

Demonstrating that consensus does not exist (yet) is part of the
process and does not preclude WG formation in the future.  The
problem with the "wrong questions" is that they do not reveal anything
about why consensus does not exist so there is no way to make progress.

The seven right questions seemed to focus on aspects of the problem
in a piecewise fashion, establishing areas of consensus and identifying 
areas where additional work is needed.  The wrong questions do not
serve to focus future discussion where it is needed.  I think a few
additional sentences on wrong questions could convey this more clearly.

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection