Considerations for Having a Successful Birds-of-a-Feather (BOF) Session
draft-narten-successful-bof-04

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 www.ietf.org.  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.)