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

[Ballot discuss]
I saw constructive Last Call comments from Spencer Dawkins, Dave
  Crocker, and Gonzalo Camarillo.  I have not see responses to any of
  them.  Please provide responses, even if it is to indicate the reason
  that their suggestions are not going to be accepted.

  Jari has one small concern that deserves attention. The document
  advocates early preparation for the BOF. However, the timelines
  listed in the document do not match current reality:

    As described in detail below, the deadline for scheduling BOFs
    is approximately one month prior to the IETF meeting.
    ...
    There is a firm deadline (about 1 month prior to the meeting)
    for submitting a formal BOF scheduling request.

  The IETF 73 dates, it says:

    September 15, Monday - Cutoff date ... for preliminary BOF proposals
    September 29, Monday - Cutoff date for ADs to schedule BOFs
    (IAB - IESG BOF Call on October 3rd)
    October 6, Monday - Cutoff date for Area Directors to approve BOFs
    Meeting: 16-21 November 2008

  Suggestion: s/((one)|(1)) month/six weeks/

[Ballot discuss]
This is a great document, and needs to be published as an RFC ASAP.

I do have one small concern that I would like to discuss on the call
before balloting Yes, however. One of the points of the document
is to advocate early preparation for the BOF. However, the timelines
listed in the document do not match current reality:

  As described in detail below, the deadline for scheduling BOFs is
  approximately one month prior to the IETF meeting.
  ...
  There is a firm deadline (about 1 month prior to the meeting) for
  submitting a formal BOF scheduling request.

Yet when I look at IETF-73 dates, it says:

  September 15, Monday - Cutoff date ... for preliminary BOF proposals
  September 29, Monday - Cutoff date for ADs to schedule BOFs
  (IAB - IESG BOF Call on October 3rd)
  October 6, Monday - Cutoff date for Area Directors to approve BOFs
  Meeting: 16-21 November 2008

By my count that is six, seven or nine weeks, depending on what event you
count to. We could talk about whether our timelines or the document are
wrong (I'm more in the former camp, personally). But the fact of the
matter is that the document gives a too rosy picture about the
deadlines.

I would suggest an edit: s/((one)|(1)) month/six weeks/

[Ballot discuss]
This is a great document, and needs to be published as an RFC ASAP.

I do have one small concern that I would like to discuss on the call
before balloting Yes, however. One of the points of the document
is to advocate early preparation for the BOF. However, the timelines
listed in the document do not match current reality:

  As described in detail below, the deadline for scheduling BOFs is
  approximately one month prior to the IETF meeting.
  ...
  There is a firm deadline (about 1 month prior to the meeting) for
  submitting a formal BOF scheduling request.

Yet when I look at IETF-73 dates, it says:

  September 15, Monday - Cutoff date ... for preliminary BOF proposals
  September 29, Monday - Cutoff date for ADs to schedule BOFs
  (IAB - IESG BOF Call on October 3rd)
  October 6, Monday - Cutoff date for Area Directors to approve BOFs
  Meeting: 16-21 November 2008

By my count that is six or eight weeks, depending on what event you
count to. We could talk about whether our timelines or the document are
wrong (I'm more in the former camp, personally). But the fact of the
matter is that the document gives a too rosy picture about the
deadlines.

I would suggest an edit: s/((one)|(1)) month/six weeks/

[Ballot discuss]
This is a great document, and needs to be published as an RFC ASAP.

I do have one small concern that I would like to discuss on the call
before balloting Yes, however. One of the points of the document
is to advocate early preparation for the BOF. However, the timelines
listed in the document do not match current reality:

  As described in detail below, the deadline for scheduling BOFs is
  approximately one month prior to the IETF meeting.
  ...
  There is a firm deadline (about 1 month prior to the meeting) for
  submitting a formal BOF scheduling request.

Yet when I look at IETF-73 dates, it says:

  September 15, Monday - Cutoff date ... for preliminary BOF proposals
  September 29, Monday - Cutoff date for ADs to schedule BOFs
  (IAB - IESG BOF Call on October 3rd)
  October 6, Monday - Cutoff date for Area Directors to approve BOFs
  Meeting: 16-21 November 2008

By my count that is six or eight weeks, depending on to what even you
count. We could talk about whether our timelines or the document are
wrong (I'm more in the former camp, personally). But the fact of the
matter is that the document gives a too rosy picture about the
deadlines.

I would suggest an edit: s/((one)|(1)) month/six weeks/

[Ballot discuss]
This is a great document, and needs to be published as an RFC ASAP.

I do have one small concern that I would like to discuss on the call
before ballot yes, however. One of the points of the document
is to advocate early preparation for the BOF. However, the timelines
listed in the document do not match current reality:

  As described in detail below, the deadline for scheduling BOFs is
  approximately one month prior to the IETF meeting.
  ...
  There is a firm deadline (about 1 month prior to the meeting) for
  submitting a formal BOF scheduling request.

Yet when I look at IETF-73 dates, it says:

  September 15, Monday - Cutoff date ... for preliminary BOF proposals
  September 29, Monday - Cutoff date for ADs to schedule BOFs
  (IAB - IESG BOF Call on October 3rd)
  October 6, Monday - Cutoff date for Area Directors to approve BOFs
  Meeting: 16-21 November 2008

By my count that is six or eight weeks, depending on to what even you
count. We could talk about whether our timelines or the document are
wrong (I'm more in the former camp, personally). But the fact of the
matter is that the document gives a too rosy picture about the
deadlines.

I would suggest an edit: s/((one)|(1)) month/six weeks/

[Ballot comment]
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.

[Ballot comment]
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.)

[Ballot comment]
[This is a very useful document, and I support publication as an RFC.  That said, I do have
a couple of issues with the draft.

I have not decided whether I believe these issues rise to the level of a discuss, so I have
documented my issues as a comment for now.  Hopefully, this will stimulate discussion
and perhaps resolution before the call, and help me decide whether to ballot No Obj or
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.

[Ballot discuss]
I saw constructive Last Call comments from Spencer Dawkins, Dave
  Crocker, and Gonzalo Camarillo.  I have not see responses to any of
  them.  Please provide responses, even if it is to indicate the reason
  that their suggestions are not going to be accepted.