Considerations for Having a Successful "Bar BOF" Side Meeting
draft-eggert-successful-bar-bof-09

[Ballot comment]
I agree with a number of the comments already made, particularly those by Wes, Ralph, and Jari.  I have nothing new to add to that.

[Ballot comment]
1. I'm in favor of moving away from the term "bar BOF".  The term, in
my opinion, has baggage in its relationship to "BOF" that would be
better left behind.

2. I encourage any additional verbiage that can be added to emphasize
the lack of any official standing afforded to side meetings; e.g.,
text to address the comment Wes posted that no inferences should be
drawn from the attendance of an AD.

3. In this sentence from the intro:

  During recent IETF meetings, "bar BOFs" have become increasingly
  indistinguishable from official IETF BOFs or sometimes even IETF
  working group meetings.

I think it's useful to mention something about "bar BOFs" being
(incorrectly) viewed as a mandatory prerequisite to an official IETF
BOF.

[Ballot comment]
I agree with Wes' and Sean's comments about inferring any level of support when an AD elects to attend (or not attend) a side meeting.

[Ballot comment]
The authors indicated they would make several changes based on last call comments (on -06) that are not reflected in this version. In particular there were comments from Ben Campbell and Spencer Dawkins on material outside the now deleted section 6.

[Ballot discuss]
A horrible error on your otherwise excellent draft:

> Anecdotal evidence exists that at least one Area Director has not
> been able to set foot outside the IETF hotel for a stretch of several
> days during IETF-77.

A week. A full week. I think they let me out on Thursday evening, though. And I saw the sun for the first time on Friday. And why do you pick on Anaheim?

Seriously though I do have a more serious issue. I agree with the thrust of the draft, of course, but I think it is written from a very typical IESG perspective where we try to prevent  from happening. But our role is not just to prevent bad things from happening, its also make good things happen. And I would argue that the draft misses some aspects of the problem from the point of view of the bar BOF folk when it tries to focus on the location of the meeting.

My main issue is that other than giving advice on where to meet, the draft says very little on how to go about making a successful bar BOF. The specifics of the meeting itself are just one aspect.

1) Unless you are an AD, chair, or key engineer at an important company, you will have trouble even finding the other people to talk to. Part of the reason why people come to the IETF meeting is to have side meetings. We should make it easy for them, but for many people it will be difficult to get started, even if they have an issue of their own. The working group is too busy and they follow their charter, so you don't get time on the agenda. You can't broadcast your desire to talk about the topic, you won't find the additional people.

I would like to suggest that the document be changed to recommend that its OK to broadcast in the WG meeting (if you get a slot) or on the mailing list that you are interested to talk about a particular topic, please contact such and such. And *then* you can have that bar BOF. Positive description of what the guys need to do, not just forbidding them to meet in the current way.

2) Coming up with new ideas, finding other people to talk to are key benefits of an IETF meeting. The document should more clearly stat that this is a desirable activity. Now it comes across a bit negative. E.g.:

  "... organizers
  should consider the value of holding side meetings at venues where
  such input can be more easily gathered."

3)

> Finally, some organizers may find
> the process to apply for an official BOF too complex, and so decide
> to simply mimic one.

But it *is* too complex, almost unbearably unlikely to result in a granted BOF. And that is not just the fault of the BOF organizers, we are to blame, too. Perhaps mostly us.

I think the draft should honestly state something about the current BOF processing being difficult.

[Ballot discuss]
I wanted to ballot "Yes" and move ahead with this document as a useful
piece of guidance. I certainly don't want to spend time over-polishing.

However...

  Thus, the fact that a Contribution is made at one of the side
  meetings or other "unofficial" or "semi-official" events described in
  this document does not change or limit the applicability of the
  IETF's IPR rules.  If you have a question regarding the applicability
  of the IETF IPR rules in any specific context or to any specific
  activity, you should consult your attorney or make an inquiry to the
  IESG.

This is not helpful. It is true that nothing changes the IETF's IPR
rules. But that doesn't say whether the IETF's IPR rules apply to
"side meetings".

Where does the concept that side meetings are "semi-official" come from?
I thought the whole thrust of the document was to say that side meetings
are not official in any way. Indeed the Abstract says it wants to
"stress the unofficial nature of these get-togethers."

I think we can make a more significant pronouncement in this document,
but if you want it to come from the IESG then I think the whole of
Section 6 should be replaced with a note that the IESG are to be
consulted about the applicability of the IETF's IPR rules to side
meetings.

In particular, I take objection to...

  Informally, the above makes it appropriate, in order to provide a
  pointer to the relevant policies, to announce the "Note Well" text
  [NOTEWELL] in all such meetings.

...because this is clearly not the case. Indeed, it is absurd that if
I go to lunch with two other people during the week of the IETF meeting
when we all happen to be registered for the meeting that we are covered
by the Note Well. Maybe you would like this included in all menus in
all restaurants within a 10 mile radius?

And anyway, if you are defering to the IESG on this matter, it is not
correct for you to make this statement.

[Ballot discuss]
1. I agree with Jari's points in his DISCUSS. The current document seems to be too negative about making of the IETF meetings an opportunity to have people meet and discuss new work in the IETF. I believe that we need text that makes clear that this is not the intention.

2. I believe that the document needs to describe in a more balanced manner the different options of meeting to discuss new work. The principal thing in my opinion is to make clear that approving a room if available for side meetings needs not be read in any way as an endoresement of the work, but this should be a valid option

3. I find much of section 3 (where to meet) problematic. On one side the text acknowledges the problem many non-native English speakers have understanding native English speakers (and the other way actually) but encourages them to go and meet in bars and restaurants provided they are not too noisy! The point should be IMO - meet wherever and however you believe you can discuss in the best conditions, here are the options, we are here to help.

4. I would like to raise the point made by Wesley to a DISCUSS. At least we should discuss whether text is needed saying that the participation of the ADs (and maybe also of the IAB members) in side meetings should not be read as an endorsement of any kind, and that their participation is not useful because of the positions they hold, as side meetings are not part of any formal process.

[Ballot discuss]
1. I agree with Jari's points in his DISCUSS. The current document seems to be too negative about making of the IETF meetings an opportunity to have people meet and discuss new work in the IETF. I believe that we need text that makes clear that this is not the intention.

2. I believe that the document needs to describe in a more balanced manner the different options of meeting to discuss new work. The principal thing in my opinion is to make clear that approving a room if available for side meetings needs not be read in any way as an endoresement of the work, but this should be a valid option

3. I find much of section 3 (where to meet) problematic. On one side the text acknowledges the problem many non-native English speakes have understanding native English speakers (and the other way actually) but encourages them to go and meet in bars and restaurants provided they are too noise. The point should be IMO - meet wherever and however you believe you can discuss in the best conditions, here are the options, we are here to help.

4. I would like to raise the point made by Wesley to a DISCUSS. At least we should discuss whether text is needed saying that the participation of the ADs (and maybe also of the IAB members) in side meetings should not be read as an endorsement of any kind, and that their participation is not useful because of the positions they hold, as side meetings are not part of any formal process.

[Ballot comment]
1) I support Jari's comment #1.  I think people ought to be able to spam the community asking if there are people interested in topic X and then from those that respond try to set up the unofficial meeting (bar BOF/side-meeting).  I think that's different than spamming lists saying we're having a meeting in room z at 9pm that happens to conflict with the plenary.

2) I'm also not entirely sold on the need to abandon the term "bar BOF".

3) I wholly agree with Wes' comment about the AD attendance not necessarily being a good sign.  It might be worth adding that folks who ask an AD if they're coming shouldn't feel bad if the AD says "no" because it's not a sign of support or disapproval.  I've had to tell people that just because I wasn't going to make it that's okay to proceed because it's not an official meeting.

[Ballot discuss]
A horrible error on your otherwise excellent draft:

> Anecdotal evidence exists that at least one Area Director has not
> been able to set foot outside the IETF hotel for a stretch of several
> days during IETF-77.

A week. A full week. I think they let me out on Thursday evening, though. And I saw the sun for the first time on Friday. And why do you pick on Anaheim?

Seriously though I do have a more serious issue. I agree with the thrust of the draft, of course, but I think it is written from a very typical IESG perspective where we try to prevent  from happening. But our role is not just to prevent bad things from happening, its also make good things happen. And I would argue that the draft misses some aspects of the problem from the point of view of the bar BOF folk when it tries to focus on the location of the meeting.

My main issue is that other than giving advice on where to meet, the draft says very little on how to go about making a successful bar BOF. The specifics of the meeting itself are just one aspect.

1) If you are an AD, chair, or key engineer at an important company, you will have trouble even finding the other people to talk to. Part of the reason why people come to the IETF meeting is to have side meetings. We should make it easy for them, but for many people it will be difficult to get started, even if they have an issue of their own. The working group is too busy and they follow their charter, so you don't get time on the agenda. You can't broadcast your desire to talk about the topic, you won't find the additional people.

I would like to suggest that the document be changed to recommend that its OK to broadcast in the WG meeting (if you get a slot) or on the mailing list that you are interested to talk about a particular topic, please contact such and such. And *then* you can have that bar BOF. Positive description of what the guys need to do, not just forbidding them to meet in the current way.

2) Coming up with new ideas, finding other people to talk to are key benefits of an IETF meeting. The document should more clearly stat that this is a desirable activity. Now it comes across a bit negative. E.g.:

  "... organizers
  should consider the value of holding side meetings at venues where
  such input can be more easily gathered."

3)

> Finally, some organizers may find
> the process to apply for an official BOF too complex, and so decide
> to simply mimic one.

But it *is* too complex, almost unbearably unlikely to result in a granted BOF. And that is not just the fault of the BOF organizers, we are to blame, too. Perhaps mostly us.

I think the draft should honestly state something about the current BOF processing being difficult.

[Ballot comment]
A horrible error on your otherwise excellent draft:

> Anecdotal evidence exists that at least one Area Director has not
> been able to set foot outside the IETF hotel for a stretch of several
> days during IETF-77.

A week. A full week. I think they let me on Thursday evening, though. And I saw the sun for the first time on Friday.

[Ballot comment]
A horrible error on your otherwise excellent draft:

> Anecdotal evidence exists that at least one Area Director has not
> been able to set foot outside the IETF hotel for a stretch of several
> days during IETF-77.

A week. A full week. I think they let me on Thursday evening, though. And I saw the sun for the first on Friday.

[Ballot discuss]
The list conversation on the "Applicability of IPR Rules" section does not appear to have concluded. I plan to move to YES on this document once that conversation completes.

[Ballot comment]
To comment on Stephen's comment about the use of the term "bar bof". The traditionalist in me prefers to retain that term since it goes back to the origins of the IETF. However I am conscious that the term "bar bof" may well be a cultural issue for some folks. As such it would be good to find a term that was not synonymous with alcohol, but was somewhat more colorful and descriptive than "side meeting". Unfortunately no such term springs to mind.

[Ballot comment]
I very much like this document.

I think it would be helpful to cite RFC 5434 as early as possible in the document. I suggest adding a parenthetical statement to Section 1:

  New IETF work often fits into an existing working group
  and does not require an official "birds of a feather" (BOF) session
  to determine community consensus (for more detailed information
  about BOF sessions, see [RFC 5434]).

In Section 3:

s/much more ineffective/much less effective/

Perhaps make this change in Section 4:

s/too complex/too complex or troublesome/

There is a typo in Section 4:

s/a certain procedures/certain procedures/

[Ballot comment]
1) I'm not won over to the idea of discouraging the term "bar bof"
generally. I do think we should distinguish those from side-meetings
held as if they were formal wg sessions though and we should discourage
the holding of the latter kind of meeting. So, I'd suggest changing
the last sentence of the abstract to say something like:

  "This document recommends that the community use
  the term "bar BoF" exclusively to refer to side
  meetings that are held in bars and the like and
  to abandon the use of the term for meetings that
  are held in more formal settings such as IETF
  meeting rooms."

(2) The same change as (1) would be needed in the intro, 2nd
last para.

(3) I think the IETF LC discussion about IPR should result in
some change to section 6, depending on where that goes. I
reckon that a good outcome to that might be that the Note Well
ought be popped up for side-meetings in IETF meeting rooms
but not otherwise.

(4) I think Wes' suggestion about AD attendance is worth
adding.

(5) People have been known to forget their laptops after
extended bar BoF sessions in real bars. That could be added
to the security considerations.

(6) I guess the Trilogy project may be finished now, so you
may want to change the tense of the ack.

[Ballot comment]
It may be worthwhile to give some tips on inviting (or not inviting) area directors to your "side meeting" / bar-BOF.

It should say that this isn't necessary, and may not even be advisable in many cases.  Some groups need time to form before they're ready with anything cohesive, and a side-meeting is a good time to establish that BEFORE approaching ADs and describing proposals.

It should be clear that if an AD attends a side-meeting, it is not necessarily a show of support.  They may simply be interested, or often may be concerned or troubled with some aspect of the potential work and relation to existing work  As the side-meeting may be in early stages of developing a viable WG or BoF proposal, there are likely to be many such concerns.
.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Considerations for Having a Successful "Bar BOF" Side Meeting) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Considerations for Having a Successful "Bar BOF" Side Meeting'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  New work is typically brought to the IETF by a group of interested
  individuals.  IETF meetings are a convenient place for such groups to
  hold informal get-togethers to discuss and develop their ideas.  Such
  side meetings, which are not reflected in the IETF meeting agenda and
  have no official status, are often half-jokingly referred to as "bar
  BOF" sessions, to acknowledge that some of them may eventually lead
  to a proposal for an official IETF BOF ("birds of a feather" session)
  on a given topic.

  During recent IETF meetings, many such "bar BOF" get-togethers have
  been organized and moderated in ways that made them increasingly
  indistinguishable from official IETF BOFs or sometimes even IETF
  working group meetings.

  This document argues that this recent trend is not helpful in
  reaching the ultimate goal of many of these get-togethers, i.e., to
  efficiently discuss and develop ideas for new IETF work.  It
  encourages the organizers to consider the benefits of holding them in
  much less formal settings, and to also consider alternative means to
  develop their ideas.  This document also recommends that the
  community abandon the term "bar BOF" and instead use other terms such
  "side meeting", in order to stress the unofficial nature of these
  get-togethers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-eggert-successful-bar-bof/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-eggert-successful-bar-bof/


No IPR declarations have been submitted directly on this I-D.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?

The document shepherd is Gonzalo Camarillo who believes this document
is ready for publication.

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

The document has been reviewed by key members of the community.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?

No concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

No concerns.

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

There seems to be consensus, although a few individuals may disagree
with parts of the document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

The document passes ID nits.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].

The document only contains Informative references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

The document contains a null IANA Considerations Section.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?

The document does not contain formal language.


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

        Relevant content can frequently be found in the abstract and/or
        introduction of the document. If not, this may be an
        indication that there are deficiencies in the abstract or
        introduction.

  New work is typically brought to the IETF by a group of interested
  individuals.  IETF meetings are a convenient place for such groups to
  hold informal get-togethers to discuss and develop their ideas.  Such
  side meetings, which are not reflected in the IETF meeting agenda and
  have no official status, are often half-jokingly referred to as "bar
  BOF" sessions, to acknowledge that some of them may eventually lead
  to a proposal for an official IETF BOF ("birds of a feather" session)
  on a given topic.

  During recent IETF meetings, many such "bar BOF" get-togethers have
  been organized and moderated in ways that made them increasingly
  indistinguishable from official IETF BOFs or sometimes even IETF
  working group meetings.

  This document argues that this recent trend is not helpful in
  reaching the ultimate goal of many of these get-togethers, i.e., to
  efficiently discuss and develop ideas for new IETF work.  It
  encourages the organizers to consider the benefits of holding them in
  much less formal settings, and to also consider alternative means to
  develop their ideas.  This document also recommends that the
  community abandon the term "bar BOF" and instead use other terms such
  "side meeting", in order to stress the unofficial nature of these
  get-togethers.


    Working Group Summary

        Was there anything in the discussion in the interested
        community that is worth noting? For example, was there
        controversy about particular points or were there decisions
        where the consensus was particularly rough? Was the document
        considered in any WG, and if so, why was it not adopted as a
        work item there?

The document was not considered in any particular WG. Issues related
to this document have been widely discussed on the IETF General
mailing list.

    Document Quality   

        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to implement
        the specification? Are there any reviewers that merit special
        mention as having done a thorough review, e.g., one that
        resulted in important changes or a conclusion that the document
        had no substantive issues? If there was a MIB Doctor, Media
        Type or other expert review, what was its course (briefly)? In
        the case of a Media Type review, on what date was the request
        posted?   

This document does not specify any network protocol.