Network Working Group                                          T. Narten
Request for Comments: 5434                                           IBM
Category: Informational                                    February 2009
Network Working Group                                          T. Narten
Request for Comments: 5434                                           IBM
Category: Informational                                    February 2009

Considerations for Having a Successful Birds-of-a-Feather (BOF) Session


Status of This Memo


This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.


Copyright Notice


Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2009 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( 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.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束( 许可证信息)在本文件发布之日生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。



This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful.


Table of Contents


   1. Introduction ....................................................2
   2. Recommended Steps ...............................................2
   3. The Importance of Understanding the Real Problem ................7
   4. The BOF Itself ..................................................8
   5. Post-BOF Follow-Up ..............................................9
   6. Pitfalls .......................................................10
   7. Miscellaneous ..................................................12
      7.1. Chairing ..................................................12
      7.2. On the Need for a BOF .....................................13
   8. Security Considerations ........................................13
   9. Acknowledgments ................................................13
   10. Informative Reference .........................................13
   1. Introduction ....................................................2
   2. Recommended Steps ...............................................2
   3. The Importance of Understanding the Real Problem ................7
   4. The BOF Itself ..................................................8
   5. Post-BOF Follow-Up ..............................................9
   6. Pitfalls .......................................................10
   7. Miscellaneous ..................................................12
      7.1. Chairing ..................................................12
      7.2. On the Need for a BOF .....................................13
   8. Security Considerations ........................................13
   9. Acknowledgments ................................................13
   10. Informative Reference .........................................13
1. Introduction
1. 介绍

This document provides suggestions on how to host a successful BOF at an IETF meeting. It is hoped that by documenting the methodologies that have proven successful, as well as listing some pitfalls, BOF organizers will improve their chances of hosting a BOF with a positive outcome.


There are many reasons for hosting a BOF. Some BOFs are not intended to result in the formation of a Working Group (WG). For example, a BOF might be a one-shot presentation on a particular issue, in order to provide information to the IETF Community. Another example might be to host an open meeting to discuss specific open issues with a document that is not associated with an active WG, but for which face-to-face interaction is needed to resolve issues. In many cases, however, the intent is to form a WG. In those cases, the goal of the BOF is to demonstrate that the community has agreement that:


- there is a problem that needs solving, and the IETF is the right group to attempt solving it.

- 有一个问题需要解决,IETF是尝试解决这个问题的正确团队。

- there is a critical mass of participants willing to work on the problem (e.g., write drafts, review drafts, etc.).

- 有相当数量的参与者愿意解决这个问题(例如,撰写草稿、审查草稿等)。

- the scope of the problem is well defined and understood, that is, people generally understand what the WG will work on (and what it won't) and what its actual deliverables will be.

- 问题的范围被很好地定义和理解,也就是说,人们通常理解工作组将要做什么(不做什么)以及它的实际可交付成果是什么。

- there is agreement that the specific deliverables (i.e., proposed documents) are the right set.

- 双方同意,具体交付物(即,拟定文件)是正确的。

- it is believed that the WG has a reasonable probability of having success (i.e., in completing the deliverables in its charter in a timely fashion).

- 相信工作组有合理的成功概率(即及时完成其章程中的可交付成果)。

Additional details on WGs and BOFs can be found in [RFC2418].


2. Recommended Steps
2. 建议的步骤

The following steps present a sort of "ideal" sequence for hosting a BOF where the goal is the formation of a working group. The important observation to make here is that most of these steps involve planning for and engaging in significant public discussion, and allowing for sufficient time for iteration and broad participation, so that much of the work of the BOF can be done on a public mailing list in advance of -- rather than during -- the BOF itself.


It is also important to recognize the timing constraints. As described in detail below, the deadline for scheduling BOFs is approximately six weeks prior to an IETF meeting. Working backwards from that date, taking into consideration the time required to write drafts, have public discussion, allow the ADs to evaluate the proposed BOF, etc., the right time to start preparing for a BOF is almost certainly the meeting prior to the one in which the BOF is desired. By implication, starting the work aimed at leading to a BOF only 2 months prior to an IETF meeting is, in most cases, waiting too long, and will likely result in the BOF being delayed until the following IETF meeting.


The recommended steps for a BOF are as follows:


1) A small group of individuals gets together privately, discusses a possible problem statement, and identifies the work to be done. The group acts as a sort of "design team" to formulate a problem statement, identify possible work items, and propose an agenda for a BOF.

1) 一小群人私下聚在一起,讨论一个可能的问题陈述,并确定要做的工作。该小组作为一种“设计团队”制定问题陈述,确定可能的工作项目,并提出BOF议程。

Possible sub-steps:


a) Consider whether the work might already fall within the scope of an existing Working Group, in which case a BOF might not even be necessary. Individual Working Group charters can be found at and indicate what a group is scoped to work on.

a) 考虑工作是否已经落入现有工作组的范围内,在这种情况下,BOF甚至可能不是必需的。个人工作组章程可在 并指出组的工作范围。

b) Select the area or areas in which the work most naturally fits by identifying WGs that most closely relate to the proposed work. Note that it is not uncommon to find that a work item could easily fit into two (or more) different areas and that no one area is the obvious home.

b) 通过确定与拟议工作最密切相关的工作组,选择工作最适合的一个或多个领域。请注意,发现一个工作项可以轻松地放入两个(或多个)不同的区域,并且没有一个区域是明显的家,这种情况并不少见。

c) Consult with specific WGs to see whether there is interest or whether the work is in scope. This can be done by posting messages directly to WG mailing lists, contacting the WG chairs, or contacting individuals known to participate in a particular WG (e.g., from their postings or from documents they have authored).

c) 咨询特定工作组,了解是否有兴趣或工作是否在范围内。这可以通过直接向工作组邮件列表发布消息、联系工作组主席或联系已知参与特定工作组的个人(例如,通过他们的帖子或他们编写的文档)来实现。

d) Consult with an area-specific mailing list about possible interest. (Most areas have their own area-specific mailing lists. Follow the links under each area at to find details.)

d) 咨询特定地区的邮件列表,了解可能的兴趣。(大多数地区都有自己特定地区的邮件列表。请按 以查找详细信息。)

e) Produce one or more Internet Drafts, describing the problem and/or related work. It cannot be emphasized enough that, for the BOF, drafts relating to understanding the problem space are much more valuable than drafts proposing specific solutions.

e) 制作一份或多份互联网草稿,描述问题和/或相关工作。对于BOF来说,与理解问题空间相关的草案比提出具体解决方案的草案更有价值,这一点再怎么强调也不为过。

Timeline: This step can easily take 1-2 months; hence, begin 3-4 months before an IETF meeting.


2) The group may (or may not) approach an Area Director (or other recognized or experienced leader) to informally float the BOF and get feedback on the proposed work, scope of the charter, specific steps that need to be taken before submitting a formal BOF request, etc. By "leader", we mean persons with significant IETF experience who can provide helpful advice; individuals who have successfully hosted BOFs before, current or former WG chairs, and IESG or IAB members would be good candidates.

2) 工作组可以(也可以不)与区域总监(或其他公认或有经验的领导)接触,以非正式方式浮动BOF,并获得“领导”对提议工作、章程范围、提交正式BOF请求前需要采取的具体步骤等的反馈,我们指的是具有丰富IETF经验、能够提供有用建议的人员;曾经成功主持过BOF的个人、现任或前任工作组主席、IESG或IAB成员都是很好的候选人。

The dividing line between steps 1) and 2) is not exact. At some point, one will need to approach one or more Area Directors (ADs) with a specific proposal that can be commented on. Step 1) helps shape an idea into something concrete enough that an AD can understand the purpose and provide concrete feedback. On the other hand, one shouldn't spend too much time on step 1) if the answer at step 2) would turn out to be "oh, we had a BOF on that once before; have you reviewed the archives?". Thus, there may be some iteration involving going back and forth between steps 1) and 2). Also, a quick conversation with an AD might lead them to suggest some specific individuals or WGs you should consult with.


It may turn out that it is unclear in which area the proposed work best fits. In such cases, when approaching multiple ADs, it is best to approach the ADs approximately simultaneously, state that you are unsure in which area the work fits, and ask for advice (e.g., by stating "I'm not sure which area this work best fits under, but it looks like it might be Internet or Security or both"). When contacting multiple ADs, it is strongly advised that you inform them of which other ADs you are conversing with. In particular, it is usually counterproductive and not advisable to go "AD shopping", where if one AD gives you an answer you don't like, you go to another, without telling him/her what the first AD said, in the hopes of getting a more favorable answer.


To summarize, steps 1) and 2) involve a lot of "socializing an idea", that is, having discussions with a number of different people to attempt gaining agreement on the problem and the need for and appropriateness of having a BOF. How much such discussion is needed is very subjective, but it is critical in terms of getting agreement that a BOF is appropriate. One way to tell if


you are close to getting it right: when talking to someone about your idea for the first time, they quickly agree that a BOF seems in order and don't have any major concerns.


Timeline: Steps 1-2) can easily take 1-2 months; hence, begin 3-4 months before an IETF meeting.


3) Create a public mailing list and post a "call for participation" for the proposed BOF topic on various mailing lists (e.g., the IETF list). The call for participation advertises that a "community of interest" is being formed to gauge whether there is sufficient interest to host a BOF. The goal is to draw in other interested potential participants, to allow them to help shape the BOF (e.g., by giving them time to write a draft, ask for agenda time, help scope the work of the proposed work, argue that a BOF is (or is not) needed, etc.).

3) 创建一个公共邮件列表,并在各种邮件列表(如IETF列表)上发布拟议BOF主题的“参与呼吁”。呼吁参与宣传正在形成一个“利益共同体”,以评估是否有足够的利益来主办一个BOF。目标是吸引其他感兴趣的潜在参与者,让他们帮助制定BOF(例如,给他们时间起草草案、要求议程时间、帮助确定拟议工作的范围、论证是否需要BOF等)。

Timeline: This step can easily take 1 month or longer; it also needs to be started well before the Internet-Drafts cutoff (to allow participants to submit drafts); hence, begin 2.5-3.5 months before the IETF meeting.


4) Have substantive mailing list discussion. It is not enough for a handful of people to assert that they want a BOF; there needs to be broader community interest. A public mailing list allows ADs (and others) to gauge how much interest there really is on a topic area, as well as gauge how well the problem statement has been scoped, etc. At this phase of the BOF preparation, the emphasis should be on getting agreement on the problem statement; discussions about specific solutions tend to be distracting and unhelpful.

4) 进行实质性的邮件列表讨论。仅仅一小撮人宣称他们想要一个BOF是不够的;需要有更广泛的社区利益。公共邮件列表允许ADs(和其他人)衡量人们对某个主题领域的真正兴趣,以及衡量问题陈述的范围等。在BOF准备的这个阶段,重点应该是就问题陈述达成一致意见;关于具体解决方案的讨论往往会分散注意力,毫无帮助。

Timeline: this step can easily take 1 month or longer; hence, begin 2.5 months before the IETF meeting.


5) Submit a formal request to have a BOF. Instructions for submitting a formal request can be found at and Note that as part of making a formal request, the organizers must identify the area in which the BOF will be held (the Area Directors of that area will be required to approve the BOF), include a proposed BOF agenda, estimate the attendance, list conflicts with other sessions that should be avoided, etc.

5) 提交正式的BOF申请。有关提交正式申请的说明,请访问 和 请注意,作为提出正式请求的一部分,组织者必须确定BOF将在哪个区域举行(该区域的区域主管将被要求批准BOF),包括提议的BOF议程、估计出席人数、列出应避免的与其他会议的冲突等。

If the previous steps have been followed, the Area Directors (ADs) should be in a good position to gauge whether there is sufficient interest to justify approval of a BOF.


Note: it almost goes without saying that without one or more Internet Drafts at this point, it is generally pointless to ask an AD to approve a BOF.


Timeline: The Secretariat publishes an "important meeting dates" calendar along with meeting information. There is a firm deadline (about six weeks prior to the meeting) for submitting a formal BOF scheduling request. Note that at the time of the deadline, an AD will need to have sufficient information about the BOF to approve or reject the request, so all of the previous steps will need to have completed.


6) During the 2-4 weeks before an IETF (assuming a BOF has been approved and scheduled), the focus (on the mailing list) should be on identifying areas of agreement and areas of disagreement. Since disagreement, or "lack of consensus", tends to be the main reason for not forming a WG, focusing on those specific areas where "lack of consensus" exists is critically important. In general, only after those disagreements have been resolved will a WG be formed; thus, the main goal should be to find consensus and work through the areas of disagreement. Alternatively, a specific case should be made about why the charter, as it is written, is the best one, in spite of the stated opposition.

6) 在IETF之前的2-4周内(假设BOF已经批准和安排),重点(在邮件列表上)应该是确定一致的领域和不一致的领域。由于分歧或“缺乏共识”往往是不成立工作组的主要原因,因此关注“缺乏共识”的具体领域至关重要。一般来说,只有在这些分歧得到解决后,才会成立工作组;因此,主要目标应该是找到共识,解决分歧领域。或者,应该提出一个具体的案例,说明为什么尽管有明确的反对意见,但书面的《宪章》是最好的。

7) Prior to the BOF, it is critical to produce a proposed charter and iterate on it on the mailing list to attempt to get a consensus charter. Ultimately, the most important question to ask during a BOF is: "should a WG with the following charter be formed?". It goes without saying that a charter with shortcomings (no matter how seemingly trivial to fix) will not achieve consensus if folk still have issues with the specific wording.

7) 在BOF之前,制定一份提议的章程,并在邮件列表上重复该章程,以试图获得一致的章程,这一点至关重要。最后,在BOF期间要问的最重要的问题是:“是否应该成立一个具有以下章程的工作组?”。不言而喻,如果民间对具体措辞仍有异议,一份有缺陷的宪章(无论修复起来多么微不足道)将无法达成共识。

8) Decide what questions will be asked during the BOF itself. Since the exact wording of the questions is critical (and hard to do on the fly), it is strongly recommended that those questions be floated on the mailing list and to the ADs prior to the BOF. This will enable people to understand what they will be asked to approve and will allow the questions to be modified (prior to the BOF) to remove ambiguities, etc. Likewise, discussing these questions in advance may lead to refinement of the charter so that the questions can be answered affirmatively.

8) 决定在BOF期间将提出哪些问题。由于问题的确切措辞至关重要(而且很难即时解决),因此强烈建议在BOF之前将这些问题发布在邮件列表和广告上。这将使人们能够理解他们将被要求批准的内容,并允许修改问题(在BOF之前),以消除歧义等。同样,提前讨论这些问题可能会导致章程的完善,从而可以肯定地回答问题。

9) At the meeting, but before the BOF takes place, plan a meeting with all of the presenters to have them meet each other, review the agenda, and make sure everyone understands what is expected of them (e.g., what time constraints they will be under when

9) 在会议上,但在BOF举行之前,与所有演讲者计划一次会议,让他们见面,审查议程,并确保每个人都了解对他们的期望(例如,他们将在什么时候受到什么时间限制)

presenting). Use this time to also work through any disagreements that still remain. Do the same "in the hallway" with other interested parties!


10) Consult the tutorial schedule and consider attending relevant tutorial sessions ("Working Group Chair Training", "Working Group Leadership Training", etc.). This is especially the case if you are considering being the chair of a proposed WG. Since the role of the WG chair and BOF chair have a number of parallels, a number of the topics covered in the tutorial apply to hosting a BOF and developing a charter.


3. The Importance of Understanding the Real Problem
3. 理解真实问题的重要性

Throughout the process of chartering new work in the IETF, a key issue is understanding (and finding consensus) on what the real, underlying problem is that the customer, operator, or deployer of a technology has and that the WG needs to address. When a WG finishes an effort, the WG's output will only be useful if it actually solves a real, compelling problem faced by the actual user of the technology (i.e., the customer or operator). Unfortunately, there have been more than a few IETF WGs whose output was not adopted, and in some of those cases the cause was a lack of understanding of the real problem the operator had. In the end, the WG's output simply didn't address the right problem.


Another issue that can happen is discussions about specific (or competing) solution approaches effectively stalemating the WG (or BOF), making it unable to make progress. In some of those cases, the arguments about the appropriateness of specific technologies are actually proxies for the question of whether a proposed approach adequately addresses the problem. If there is a lack of clarity about the actual underlying problem to be solved, there may well be unresolvable arguments about the suitability of a particular technical approach, depending on one's view of the actual problem and the constraints associated with it. Hence, it is critical for all work to be guided by a clear and shared understanding of the underlying problem.


The best description and understanding of an actual problem usually comes from the customer, operator, or deployer of a technology. They are the ones that most clearly understand the difficulties they have (that need addressing) and they are the ones who will have to deploy any proposed solution. Thus, it is critical to hear their voice when formulating the details of the problem statement. Moreover, when evaluating the relative merits of differing solution approaches, it is often helpful to go back to the underlying problem statement for guidance in selecting the more appropriate approach.


4. The BOF Itself
4. 转炉本身

For the BOF itself, it is critically important to focus on the bottom line:


What is it that one is attempting to achieve during the BOF?


Or, stated differently, after the BOF is over, by what criteria will you decide whether or not the BOF was successful?


A good BOF organizer keeps a firm focus on the purpose of the BOF and crafts an agenda in support of that goal. Just as important, presentations that do not directly support the goal should be excluded, as they often become distractions, sow confusion, and otherwise take focus away from the purpose of the BOF. If the goal is to form a WG, everything should lead to an (obvious) answer to the following question:


Does the room agree that the IETF should form a WG with the following (specific) charter?


One of the best ways to ensure a "yes" answer to the above, is by performing adequate preparation before the BOF to ensure that the community as a whole already agrees that the answer is "yes". How does one do that? One good way seems to be:


1) Have a public discussion with sufficient time to allow iteration and discussion. (Hence, start a minimum of 3 months prior to the IETF meeting.)

1) 进行公开讨论,有足够的时间进行迭代和讨论。(因此,至少在IETF会议前3个月开始。)

2) Work with the community to iterate on the charter and be sure to address the significant concerns that are being raised. (One can address the concerns in advance -- and get advance agreement -- or one can have those concerns be raised (again) during the BOF -- in which case it is likely that the proposed charter will not be good enough to get agreement during the actual BOF).

2) 与社区合作,反复讨论宪章,并确保解决提出的重大问题。(人们可以提前解决这些问题——并获得事先协议——或者在BOF期间(再次)提出这些问题——在这种情况下,拟议的章程可能不足以在实际的BOF期间达成协议)。

3) During the BOF, keep the agenda tightly focused on supporting the need for the WG and otherwise making the case that the group has identified a clearly-scoped charter and has agreement on what the set of deliverables should be.

3) 在BOF期间,将议程紧紧地集中在支持工作组的需要上,并以其他方式证明工作组已经确定了明确的章程范围,并就应交付的内容达成了一致意见。

Another important reason for holding a BOF is to establish an understanding of how the attendees (and the larger community) feel about the proposed work. Do they understand and agree on the problem that needs solving? Do they agree the problem is solvable, or that new protocol work is needed? To better understand the degree of agreement, it is useful to ask the audience questions.


Whenever asking questions, it is important to ask the right ones -- questions that show where there is agreement and questions that probe the details around where agreement is lacking. Good questions typically focus on aspects of the problem in a piecewise fashion, establishing areas of consensus and identifying areas where additional work is needed. Poor questions do not serve to focus future discussion where it is needed. The following are examples of questions that are often useful to ask.


1) Is there support to form a WG with the following charter? (That is, the charter itself is ready, as shown by community support.)

1) 是否支持按照以下章程组建工作组?(也就是说,宪章本身已经准备就绪,社区支持就是明证。)

2) Does the community think that the problem statement is clear, well-scoped, solvable, and useful to solve?

2) 社区是否认为问题陈述清晰、范围明确、可解决且有助于解决?

3) Can I see a show of hands of folk willing to review documents (or comment on the mailing list)?

3) 我能看到愿意审阅文件(或在邮件列表上发表评论)的人举手示意吗?

4) Who would be willing to serve as an editor for the following document(s)? (BOF chairs should take note of individuals who raise their hands, but it is also a useful gauge to see if there is a critical mass of editors to work on all the documents that are to be produced.)

4) 谁愿意担任以下文件的编辑?(BOF主席应注意举手的个人,但这也是一个有用的衡量标准,以确定是否有足够数量的编辑参与所有将要制作的文件。)

5) Does the community think that given the charter revisions discussed during the BOF (subject to review and finalization on the mailing list), a WG should be formed?

5) 社区是否认为,鉴于BOF期间讨论的章程修订(根据邮件列表进行审查和最终确定),应成立工作组?

6) How many people feel that a WG should not be formed? (If the number of no responses is significant, it would help to ask those saying no why they are opposed.)

6) 有多少人认为不应该成立工作组?(如果没有回应的数量很大,询问那些说不的人为什么反对会有帮助。)

7) Before asking a particular question, it is sometimes very appropriate to ask: Do people feel like they have sufficient information to answer the following question or is it premature to even ask the question?

7) 在问一个特定的问题之前,有时问一个问题是非常合适的:人们是否觉得他们有足够的信息来回答下面的问题,或者问这个问题是否为时过早?

Unfortunately, it is also easy to ask the wrong questions. Some examples are given in a later section.


5. Post-BOF Follow-Up
5. 转炉后跟进

After the BOF has taken place, it is advisable to take assessment of how well things went and what the next steps are. The ADs should be included in this assessment. Some things to consider:


1) Did the BOF go well enough that the logical next step is to focus on refining the charter and becoming a WG before the next IETF meeting? If so, there will almost certainly be additional discussion on the mailing list to refine the charter and work out a few remaining items.

1) BOF是否进展顺利,下一步的逻辑是在下一次IETF会议之前专注于完善章程并成为工作组?如果是这样的话,几乎可以肯定的是,在邮件列表上会有更多的讨论,以完善章程,并制定出一些剩余的项目。

Note that it can be difficult to determine in some cases whether a WG is a feasible next step. Much will depend on details of how the BOF went and/or whether the contentious items can either be resolved on the mailing list or simply be excluded from the charter and dealt with later (if at all). Much will also depend on the relevant AD's assessment of whether the proposed work is ready to move forward. Sometimes even a seemingly contentious BOF can result in a WG being formed quickly -- provided the charter is scoped appropriately.


If the next step is to attempt to form a WG, the charter needs to be finalized on the BOF-specific mailing list. Once done, the IESG can be asked to formally consider the charter. The IESG then (usually) posts the proposed charter to the IETF list for community feedback and makes a decision based in part on the feedback it receives.


2) It may be the case that enough additional work still needs to take place that aiming for a second (and final) BOF makes more sense. In that case, many of the steps outlined earlier in this document would be repeated, though at a faster pace.

2) 在这种情况下,可能还需要进行足够的额外工作,以使第二次(也是最后一次)转炉的目标更有意义。在这种情况下,将重复本文件前面概述的许多步骤,尽管速度更快。

The expectations for a second BOF are generally higher than those for an initial BOF. In addition to the work done up through the first BOF, the first BOF will have highlighted the key areas where additional work is needed. The time leading up to the second BOF will need to be spent working through those outstanding issues. Second BOFs should not be a repeat of the first BOF, with the same issues being raised and the same (unsatisfactory) responses provided. The second BOF needs to show that all previously identified issues have been resolved and that formation of a WG is now in order.


6. Pitfalls
6. 陷阱

Over the years, a number of pitfalls have been (repeatedly) observed:


1) Waiting too long before getting started. It is very difficult to prepare for a BOF on short notice. Moreover, ADs are placed in a no-win situation when asked to approve a BOF for which the community has not had a chance to participate. Steps 1-4 in Section 2 above are designed to show the ADs that there is

1) 等待太久才开始。在短时间内准备转炉是非常困难的。此外,当被要求批准一个社区没有机会参与的BOF时,广告被放置在一个没有赢家的情况下。上述第2节中的步骤1-4旨在显示存在的广告

community support for a particular effort. Short-circuiting those steps forces an AD to make a judgment call with (usually) too little information. Moreover, because the community has not been involved, it is much more likely that significant (and valid) objections will be raised. Often, those objections could have been dealt with in advance -- had there been sufficient time to work through them in advance.


2) Too much discussion/focus on solutions, rather than showing that support exists for the problem statement itself, and that the problem is well-understood and scoped. The purpose of the BOF is almost never to show that there are already proposed solutions, but to demonstrate that there is a real problem that needs solving, a solution would be beneficial to the community, it is believed that a solution is achievable, and there is a critical mass of community support to actually put in the real work of developing a solution.

2) 太多的讨论/关注于解决方案,而不是显示对问题陈述本身的支持,以及对问题的理解和范围。BOF的目的几乎从来都不是要表明已经提出了解决方案,而是要证明有一个真正的问题需要解决,一个解决方案将有利于社区,人们相信解决方案是可以实现的,而且,在制定解决方案的实际工作中,需要大量的社区支持。

3) Asking the wrong question during the BOF. Often, BOF organizers feel like they need a "show of hands" on specific questions. But, unless a question is clear, well scoped, focused enough to establish where there is agreement (and where not), etc., asking such a question serves little purpose. Even worse, asking poor questions can frustrate the BOF participants and lead to additional questions at the microphone, derailing the focus of the BOF.

3) 在BOF期间提出错误的问题。通常,BOF组织者觉得他们需要在具体问题上“举手”。但是,除非一个问题明确、范围明确、足够集中,能够确定哪里有协议(哪里没有),等等,否则问这样的问题没有什么意义。更糟糕的是,提出糟糕的问题会让BOF参与者感到沮丧,并导致更多的问题出现在麦克风前,从而使BOF的焦点脱轨。

Examples of unreasonable questions to ask:

Examples of unreasonable questions to ask:translate error, please retry

- Asking folk to approve or review a charter that is put on screen but has not been posted to the mailing list sufficiently in advance. (You cannot ask folk to approve something they have not seen.)

- 要求民众批准或审查屏幕上显示但尚未充分提前发布到邮件列表中的章程。(你不能要求人们批准他们没有看到的东西。)

- Asking multi-part questions in which it is not clear (in advance) what all of the exact questions will be and which choices a participant needs to choose from.

- 提出多部分问题,其中不清楚(事先)所有确切问题是什么以及参与者需要从中选择哪些选项。

4) Poorly advertised in advance, thus, the BOF itself does not include the "right" participants. This can happen for a number of reasons, including:

4) 因此,BOF本身并不包括“合适”的参与者,因为事先的宣传很差。发生这种情况的原因有很多,包括:

- giving the BOF a "cute" but unintuitive name (or acronym), preventing people from realizing that it would be of interest to them.

- 给BOF一个“可爱”但不直观的名字(或首字母缩略词),防止人们意识到这会引起他们的兴趣。

- failing to advertise the BOF in advance to the community of people that might be interested. At a minimum, the existence of a proposed BOF should be advertised on the IETF list as well as on specific WG lists that are somewhat related.

- 未能提前向可能感兴趣的社区宣传BOF。至少,提议的BOF的存在应在IETF列表以及某些相关的特定工作组列表上公布。

5) Providing agenda time for the "wrong" presentations. There is an (unfortunate) tendency to give anyone who requests agenda time an opportunity to speak. This is often a mistake. Presentations should be limited to those that address the purpose of the BOF. More important, presentations should not distract from the BOF's purpose, or open up ratholes that are a distraction to the more basic purpose of the BOF. An example of problematic presentations:

5) 为“错误”的演讲提供议程时间。有一种(不幸的)倾向,就是给任何要求议程时间的人一个发言的机会。这通常是一个错误。演示文稿应限于涉及BOF目的的内容。更重要的是,演示不应偏离BOF的目的,也不应打开阻碍BOF更基本目的的鼠洞。有问题的演示示例:

- presentations on specific solutions, when the purpose of the BOF is to get agreement on the problem statement and the need for a WG. Solutions at this point are too-often "half-baked" and allow discussion to rathole on aspects of the solutions. Instead, the focus should be on getting agreement on whether to form a WG.

- 当BOF的目的是就问题陈述和工作组的需要达成一致意见时,就具体解决方案进行演示。在这一点上,解决方案往往是“半生不熟”的,并允许对解决方案的各个方面进行讨论。相反,重点应该是就是否成立工作组达成一致。

6) Poor time management, leading to insufficient time for discussion of the key issues (this is often closely related to 5). When presentations run over their allotted time, the end result is either squeezing someone else's presentation or having insufficient discussion time. Neither is acceptable nor helpful. BOF chairs need to give presenters just enough time to make key points -- and no more. It may well be helpful to go over a presenter's slides in advance, to ensure they are on-topic and will fit within the time slot.

6) 时间管理不善,导致讨论关键问题的时间不足(这通常与5密切相关)。当演示文稿超过分配的时间时,最终结果要么是压缩了其他人的演示文稿,要么是讨论时间不足。这两者都不可接受,也没有帮助。BOF主席需要给演讲者足够的时间来提出关键点,而不是更多。提前检查演示者的幻灯片可能会很有帮助,以确保它们与主题相符,并且能够在规定的时间段内播放。

7. Miscellaneous
7. 混杂的
7.1. Chairing
7.1. 主持

BOF organizers often assume that they will be chairing a BOF (and the eventual WG). Neither assumption is always true. ADs need to ensure that a BOF runs smoothly and is productive. For some topics, it is a given that the BOF will be contentious. In such cases, ADs may want to have a more experienced person chairing or co-chairing the BOF. Also, those interested in organizing the BOF often are the most interested in driving a particular technology (and may have strongly held views about what direction an effort should take). Working Groups are often more effective when passionately involved parties are allowed to focus on the technical work, rather than on managing the WG itself. Thus, do not be surprised (or offended!) if the AD wants to pick one or more co-chairs for either the BOF or a follow-on WG.


7.2. On the Need for a BOF
7.2. 论转炉的必要性

This document highlights the need for allowing for and actively engaging in a broad public discussion on the merits of forming a WG. It might surprise some, but there is no actual process requirement to have a BOF prior to forming a WG. The actual process requirement is simply that the IESG (together with the AD(s) sponsoring the work) approve a formal charter as described in [RFC2418]. In practice, BOFs are used to engage the broader community on proposed work and to help produce an acceptable charter.


There are two observations that can be made here. First, BOFs are often held not because they are (strictly speaking) required, but because it is assumed they are needed or because ADs feel that a BOF would be beneficial in terms of getting additional public participation. Hence, those interested in forming a WG should give serious consideration to using the steps outlined above not just for the purposes of creating a BOF, but to convince the IESG and the broader community that a BOF is not even needed, as there is already demonstrated, strong consensus that a WG should be formed. Second, the IESG should not forget that BOFs are simply a tool, and may not even be the best tool in every situation.


8. Security Considerations
8. 安全考虑

This document has no known security implications.


9. Acknowledgments
9. 致谢

This document has benefited from specific feedback from Jari Arkko, Brian Carpenter, Dave Crocker, Spencer Dawkins, Lisa Dusseault, Pasi Eronen, John Klensin, Tim Polk, Mark Townsley, and Bert Wijnen.


10. Informative Reference
10. 资料性参考

[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.

[RFC2418]Bradner,S.,“IETF工作组指南和程序”,BCP 25,RFC 2418,1998年9月。

Author's Address


Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195

Thomas Narten IBM Corporation 3039 Cornwallis Ave.邮政信箱12195-北卡罗来纳州三角研究公园BRQA/502 27709-2195

Phone: 919-254-7798 EMail: