Considerations for Having a Successful Birds-of-a-Feather (BOF) Session
Note: This ballot was opened for revision 03 and is now closed.
Jari Arkko (was Discuss) Yes
( Lars Eggert ) Yes
( Pasi Eronen ) Yes
Comment (2008-11-05 for -)
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.)
( 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 -)
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.