diff options
Diffstat (limited to 'doc/rfc/rfc6771.txt')
| -rw-r--r-- | doc/rfc/rfc6771.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc6771.txt b/doc/rfc/rfc6771.txt new file mode 100644 index 0000000..277dcd3 --- /dev/null +++ b/doc/rfc/rfc6771.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Eggert +Request for Comments: 6771 NetApp +Category: Informational G. Camarillo +ISSN: 2070-1721 Ericsson + October 2012 + + + Considerations for Having a Successful "Bar BOF" Side Meeting + +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 + as "side meeting", in order to stress the unofficial nature of these + get-togethers. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + + + + +Eggert & Camarillo Informational [Page 1] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6771. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +1. Introduction + + A typical IETF meeting is full of sessions of different kinds. In + addition to official IETF and IRTF sessions listed in the meeting + agenda (such as working and research group meetings, area meetings, + or plenaries), many other unofficial meetings take place. These + include meetings between IETF participants from one organization or + company, design team meetings, Internet-Draft editing sessions, + interoperability testing, directorate lunches, and many others. + + Some of these unofficial get-togethers are organized by individual + participants with a common interest in initiating new IETF work of + some kind. New IETF work often fits into an existing working group + and does not require an official "birds of a feather" (BOF) session + [RFC5434] to determine community consensus. Nevertheless, the phrase + "bar BOF" has commonly been used in the community when talking about + such informal get-togethers that are held to discuss potential new + work. [RFC4677] (which has been obsoleted by [RFC6722]) + characterizes a "bar BOF" as + + an unofficial get-together, usually in the late evening, during + which a lot of work gets done over drinks. Bar BOFs spring up in + many different places around an IETF meeting, such as restaurants, + coffee shops, and (if we are so lucky) pools. + + During recent IETF meetings, "bar BOFs" have become increasingly + indistinguishable from official IETF BOFs or sometimes even IETF + working group meetings. The symptoms of this trend are unofficial + "bar BOFs" that are held in regular IETF meeting rooms with + + + +Eggert & Camarillo Informational [Page 2] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + + classroom-style seating, agendas with lengthy slide presentations, + use of microphone lines, and even formal consensus calls. And, + perhaps most importantly, such meetings have a distinct lack of + drinks. + + This document argues that this trend is not helpful in reaching the + ultimate goal of many of these get-togethers, i.e., to brainstorm + about a technical topic that may eventually lead to new IETF work. + It encourages the organizers of these unofficial get-togethers to + consider the benefits of holding them in much less formal settings. + + This document also recommends that the community abandon the term + "bar BOF". The distinction between a BOF, i.e., an official IETF + activity, and a "bar BOF", i.e., an unofficial get-together, is lost + on many IETF participants, especially newcomers. The similarity in + terms has even caused confusion to the point where some participants + believe that a "bar BOF" is a required step in the IETF process in + order to apply for an official BOF, which is obviously false. For + these reasons, the remainder of this document will use the term "side + meeting" instead and recommends that the community do the same, in + order to stress the unofficial nature of these get-togethers. + + Before going into more detailed advice on how to hold side meetings, + it is important to remember that many participants are extremely busy + during an IETF meeting. Although having a side meeting to discuss an + idea in an informal face-to-face setting is attractive, the + scheduling of such meetings is very difficult and needs to happen + weeks, if not months, prior to the meeting itself. Conference calls, + email discussions, wikis, jabber group chats, and other ways for + interacting are also effective at developing ideas and easier to + schedule. + +2. How to Invite + + A good rule of thumb is that a side meeting to discuss and develop a + proposal for new IETF work should include the necessary participants + to achieve that purpose and no more. Smaller meetings are usually + more successful than larger meetings. + + Hence, it is often useful to limit attendance carefully. Publicly + broadcasting an announcement for a side meeting on a particular + topic, e.g., on an IETF mailing list, is therefore not usually a good + method of inviting the desired set of participants. + + One reason is that if the announcement happens to attract a large + response, the logistics of organizing a side meeting for a larger + group quickly becomes very difficult. Small groups fit comfortably + around a table at a bar or a restaurant or can find a quiet corner in + + + +Eggert & Camarillo Informational [Page 3] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + + an IETF hallway for a discussion. Larger groups require dedicated + meeting facilities, which are limited during IETF meetings, and they + generally require much more careful planning in order to get work + done. + + When publicly announcing a side meeting, it is often not even + possible for the organizers to determine how large the resulting get- + together will be, forcing them to over-provision for the "best case" + of a substantial attendance, even in cases where this turns out to be + not necessary. And even when a large group comes together, it often + mostly consists of "tourists". Tourists usually do not actively + participate in the get-together at all, or they participate with an + intent to learn about a topic, which can derail a planned discussion + of specific issues and turn it into a tutorial. The attendance of + tourists requires finding a larger room and makes the interactions + between the active participants more cumbersome, e.g., because + microphones need to be used in larger rooms. There are times to + expose new ideas to a broader community, but think carefully before + publicly announcing a side meeting. + + So while publicly announcing a side meeting can be useful in order to + gather interested people for a discussion, it often makes sense to + still limit attendance. For example, an announcement could say, "We + have a table reserved at restaurant X for Y people. If you are + interested in attending, please briefly explain how you will + contribute to the discussion we are planning to have". If more than + Y people respond, the organizers make a selection. + + Selecting or specifically inviting IESG or IAB members is not + necessary and may not even be advisable in many cases. Some ideas + need time to form before they result in anything cohesive, and a side + meeting is a good time to develop new ideas. It is usually most + useful to approach Area Directors (ADs) and IAB members for comments + after an idea has solidified enough so that an elevator pitch can be + given. Also, it should be clear that if an AD or IAB member 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. On the + other hand, when an AD or IAB member declines to attend a side + meeting, that is usually not a sign of disinterest or disapproval -- + these people have busy schedules, especially during an IETF week. + + In the initial stages of developing a proposal for new IETF work, the + ability for interested and experienced participants to brainstorm is + tremendously important. Brainstorming is facilitated by direct, + interactive, and high-bandwidth discussions. This is clearly much + more easily achieved in a smaller setting, where half-baked ideas can + be dissected and developed. This is often not possible in a larger + + + +Eggert & Camarillo Informational [Page 4] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + + group. Even worse, a badly run large meeting can sometimes "poison + the waters" for a proposed idea by convincing the broader community + that the proposal is confused, not ready, or otherwise uninteresting. + + Another reason to discuss new work proposals in smaller groups is + scope creep, i.e., the tendency of an initially rather tightly scoped + area of new work to expand, because people will argue that whatever + the initial topic was, it should be expanded to include their + particular item of interest. This is harder to control in larger + groups. Keeping the scope of new work items narrow is important, + because eventual chartering decisions are often much more difficult + for larger items of new work than for smaller ones. + + It is important to understand that in the IETF, proposals for new + work are judged based on their technical merits and on whether there + is enough energy and interest in the community to complete the work + in a timely manner. This happens in the relevant working group, if + one exists, or else during an official BOF session. How many warm + bodies fill a room during an unofficial side meeting has no influence + on this decision and is not a good metric for reporting interest in a + topic to the community or to employers. Discussions about new work + are often controversial, and people will show up just to watch the + fireworks, learn about a new topic, or make sure the new work does + not interfere with work they are already pursuing, without being + interested contributing in some way to the actual proposal itself. + + Some side meetings are organized to discuss a topic that is also + being discussed in an existing working group, either before or after + the working group itself meets. Some working groups call these side + meetings "ad hoc sessions". The fact that a side meeting is + organized by a chair or key participant of a working group in order + to discuss topics related to the working group does not make it any + more official than other side meetings. An "ad hoc session" is not + an official working group session, and no decisions relevant to a + working group can be made. Working group consensus can only be + established during official sessions or on the mailing list + [RFC2418]. + +3. Where to Meet + + As the colloquial name "bar BOF" implied, such side meetings are + traditionally held in bars or restaurants. Recently, there has been + a distinct shift towards holding such get-togethers in regular IETF + meeting rooms. One reason for this trend has been discussed in + Section 2, namely, that an uncontrolled broadcast announcement + requires over-provisioning of facilities. + + + + + +Eggert & Camarillo Informational [Page 5] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + + A second reason for this trend is that some participants, e.g., non- + native English speakers or participants with hearing difficulties, + find it difficult to interact or follow a discussion in noisy + environments, such as restaurants and especially bars. The + organizers of side meetings are encouraged to take this factor into + consideration when finding a meeting place. Quiet restaurants are + not hard to find, and many offer private dining rooms at no extra + charge for larger parties. + + A likely third reason why side meetings are increasingly held in IETF + rooms is that the booking of such a room currently requires approval + by an Area Director. The reason for this practice is simply to make + sure that IETF-paid rooms are used for meetings that are in the + widest sense IETF-related. However, the approval of a room request + for a side meeting has been known to sometimes be reported as Area + Director "support" for the topic of the meeting to the community or + to employers. No such support is expressed or implied when Area + Directors approve room requests! Many routinely say "yes" to every + incoming request as long as there are meeting rooms available (and + there are typically lots of meeting rooms available outside of normal + working group meeting slots). + + Holding side meetings in IETF meeting rooms does not make them any + more official or valid than get-togethers that happen in other + places. Participants have recently begun to list the times and + locations of some side meetings on a wiki page, but that does not + make them part of the official IETF agenda or otherwise change their + unofficial status. + + IETF meeting rooms clearly do not provide the most supportive + environment for side meetings that require brainstorming on a new + technical proposal. One reason is that the classroom-style seating + often present in IETF meeting rooms tends to spread people out in + rows, all facing towards a front presenter, which is good for + presentations but bad for discussion. Because IETF meeting rooms + tend to be large and people have a natural tendency to spread out, + holding a meeting in one often requires microphone use, which is + cumbersome, slows a discussion down, and leads to "question-answer" + dialogs between two people, which is much less effective than a group + discussion around a restaurant table. + + Another reason is more pragmatic. Because the organizers of + unofficial get-togethers can only use IETF meeting rooms during times + when they are not otherwise in use, such side meetings often happen + during breakfast, lunch, dinner, or later in the evening. This + prolongs the time during which IETF participants are stuck in the + same rooms they're stuck in for the rest of the day, and it prevents + them from having a regular and at least somewhat relaxed meal. + + + +Eggert & Camarillo Informational [Page 6] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + + 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. (IETF 77 was held in Anaheim, CA, and the food + options in and near the hotel were, let's say, of severely limited + quality.) It is unlikely that participants in the consequential + mental and bodily state will make productive contributions to a side + meeting or, in the case of Area Directors, will be extremely + receptive towards new work proposals. + + Food, drink, and a relaxed atmosphere in which to have a discussion + are an essential part of a successful side meeting, because they + often need to happen during meal times. IETF meeting rooms offer + neither. + +4. How to Meet + + Several of the recent side meetings that were held in IETF meeting + rooms emulated official IETF meetings to a degree that made them + indistinguishable from a regular working group meeting for the + average IETF attendee. This included detailed agendas, lengthy + presentations, organizers who refer to themselves as "bar BOF + chairs", emulating blue sheets (see Section 4.5 of [RFC4677]), and + even hums and other consensus calls (see Section 5.2 of [RFC4677]). + + It is not clear as to why this has been happening. One attempt at an + explanation may be that holding a get-together in an IETF room and + having the organizers behave like chairs behave during regular IETF + sessions is causing a Pavlovian stimulus in the attendees. Another + explanation attempt is that an IETF meeting room simply does not + allow many other forms of discussion. Finally, some organizers may + find the process to apply for an official BOF too complex or + troublesome (and probably rightfully so) and so decide to simply + mimic one, or they had applied for an official BOF, got turned down, + and then decided to hold the same meeting as a side meeting. + + Whatever the reason for this development, it is reasonably obvious + that running a side meeting with a focus on making quick progress on + a technical proposal in a way that emulates running a working group + session is not very productive. Working group sessions follow + certain procedures due to larger audiences, the need to establish + formal consensus, etc., that a side meeting can do without. + + Having side meetings mimic working group meetings is also confusing + to attendees. In at least one case, some side meeting participants + believed that they were attending an actual working group meeting, + and incorrect press announcements were generated. When side meetings + take place at restaurants or elsewhere away from IETF meeting rooms, + the chance for confusion is much lower. + + + +Eggert & Camarillo Informational [Page 7] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + + Because the reasons for organizing such a get-together are diverse, + this section is not making more specific suggestions, other than to + note that meeting outside of an IETF meeting room is likely going to + shift the dynamics sufficiently so that better interactions and + results become possible. + +5. When to Meet + + Side meetings are often scheduled following IETF evening plenaries, + which sometimes end before the time indicated on the meeting agenda + but have in the past also ended much later. It is therefore useful + to avoid scheduling side meetings that follow IETF plenaries at a + fixed time. Instead, it is recommended to schedule them relative to + the end of the plenary, i.e., "X minutes after the end of the + plenary". That way, attendees do not need to wait around if a + plenary finishes early and do not need to leave a plenary should it + run late. + + Section 3 of [RFC5434] raises the issue that it is essential to + understand all angles of a given problem for which IETF work is + proposed. This means that input from the community that can be found + at IETF meetings is not all that should be considered. It can be + argued that input from other communities -- operator, research, + regulatory, etc. -- is at least as important. Hence, organizers + should consider the value of holding side meetings at venues where + such input can be more easily gathered, such as operator fora (RIPE, + NANOG, etc.), research conferences, or other events. + +6. Conclusions + + Side meeting organizers are encouraged to rekindle the original + spirit behind them and organize them outside IETF meeting rooms, at + venues with food and drink, for smaller groups, and in a way that + does not needlessly mimic the way official IETF sessions are + conducted. + + It can often be useful to discuss proposals for new IETF work face- + to-face in an informal setting, but conference calls, email + discussions, wikis, and other means for interactions are also + effective at developing ideas, especially given the scheduling + difficulties when busy individuals are involved during an IETF + meeting. + + Finally, it is important to remember that all side meetings during an + IETF week are purely informal and have no official status whatsoever. + + + + + + +Eggert & Camarillo Informational [Page 8] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + +7. Security Considerations + + A security AD pointed out that people have been known to forget their + laptops after side meetings held in real bars. The organizers of + side meetings should therefore remind any attending security ADs (and + possibly others) to take their belongings with them after the side + meeting ends or the bar closes, whichever happens first. + +8. Acknowledgments + + The name and title of this document have been chosen to resemble + those used by Thomas Narten for his guidelines document on holding a + successful BOF [RFC5434], as a sign of appreciation for a document + that has proven to be invaluable many times over. + + Several folks provided feedback and input on this document, including + Jari Arkko, Fred Baker, Scott Bradner, Ben Campbell, Jorge Contreras, + Spencer Dawkins, Ralph Droms, Wesley Eddy, Frank Ellermann, Adrian + Farrel, Stephen Farrell, David Harrington, Russ Housley, Cullen + Jennings, John Klensin, Al Morton, Robert Sparks, and Dan Wing. + + Lars Eggert was partly funded by [TRILOGY], a research project + supported by the European Commission under its Seventh Framework + Program. + +9. Informative References + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's + Guide to the Internet Engineering Task Force", RFC 4677, + September 2006. + + [RFC5434] Narten, T., "Considerations for Having a Successful Birds- + of-a-Feather (BOF) Session", RFC 5434, February 2009. + + [RFC6722] Hoffman, P., "Publishing the "Tao of the IETF" as a Web + Page", RFC 6722, August 2012. + + [TRILOGY] "Trilogy Project", <http://www.trilogy-project.org/>. + + + + + + + + + + +Eggert & Camarillo Informational [Page 9] + +RFC 6771 Successful Bar BOF Side Meetings October 2012 + + +Authors' Addresses + + Lars Eggert + NetApp + Sonnenallee 1 + Kirchheim 85551 + Germany + + Phone: +49 151 12055791 + EMail: lars@netapp.com + URI: http://eggert.org/ + + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eggert & Camarillo Informational [Page 10] + |