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

成功举办羽毛鸟(BOF)会议的考虑因素

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 (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.

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

Abstract

摘要

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.

本文件讨论了成功举办IETF羽毛之鸟(BOF)会议的策略和策略,特别是以组建IETF工作组为目标的会议。它基于参与过多次成功和失败的BOF的经验。

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.

本文件提供了如何在IETF会议上成功主持BOF的建议。希望通过记录已被证明成功的方法,以及列出一些陷阱,BOF组织者将提高举办具有积极成果的BOF的机会。

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:

举办转炉有很多原因。一些BOF的目的不是组建工作组(WG)。例如,为了向IETF社区提供信息,BOF可能是关于特定问题的一次性演示。另一个例子可能是主持一次公开会议,讨论与活跃工作组无关的特定公开问题,但需要面对面交流来解决问题。然而,在许多情况下,目的是组建工作组。在这些情况下,BOF的目标是证明社区同意:

- 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].

有关WGs和BOF的更多详细信息,请参见[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.

以下步骤提供了一种“理想”的BOF托管顺序,其目标是组建一个工作组。这里要做的重要观察是,这些步骤中的大多数都涉及到规划和参与重要的公共讨论,并允许有足够的时间进行迭代和广泛参与,因此BOF的大部分工作可以在BOF本身之前(而不是在BOF期间)在公共邮件列表上完成。

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.

认识到时间限制也很重要。如下文所述,安排BOF的截止日期约为IETF会议前六周。从该日期起,考虑到起草草案、进行公开讨论、允许ADs评估拟议的BOF等所需的时间,开始准备BOF的正确时间几乎可以肯定是在需要BOF的会议之前的会议。因此,在大多数情况下,在IETF会议前2个月才开始BOF工作的等待时间太长,可能会导致BOF推迟到下一次IETF会议。

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 http://www.ietf.org/html.charters/wg-dir.html and indicate what a group is scoped to work on.

a) 考虑工作是否已经落入现有工作组的范围内,在这种情况下,BOF甚至可能不是必需的。个人工作组章程可在http://www.ietf.org/html.charters/wg-dir.html 并指出组的工作范围。

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 http://www.ietf.org/html.charters/wg-dir.html to find details.)

d) 咨询特定地区的邮件列表,了解可能的兴趣。(大多数地区都有自己特定地区的邮件列表。请按http://www.ietf.org/html.charters/wg-dir.html 以查找详细信息。)

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.

时间线:这一步很容易需要1-2个月;因此,在IETF会议前3-4个月开始。

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.

步骤1)和2)之间的分界线不准确。在某个时候,你需要向一个或多个区域主管(ADs)提出一个可以评论的具体建议。步骤1)帮助将想法塑造成足够具体的东西,使广告能够理解目的并提供具体的反馈。另一方面,如果第2)步的答案是“哦,我们以前有过一次关于这个问题的BOF,那么你不应该在第1)步上花费太多时间,你看过档案了吗?”。因此,在步骤1)和2)之间可能会有一些涉及来回的迭代。此外,与广告的快速对话可能会让他们建议一些你应该咨询的特定个人或工作组。

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

总而言之,第1)步和第2)步涉及大量的“想法社会化”,即与许多不同的人进行讨论,试图就问题以及建立BOF的必要性和适当性达成一致。需要多少这样的讨论是非常主观的,但就达成协议而言,BOF是否合适至关重要。一种判断是否

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.

你很快就要把它做好了:当你第一次和别人谈论你的想法时,他们很快就同意BOF看起来很正常,没有任何重大问题。

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

时间线:步骤1-2)可能需要1-2个月;因此,在IETF会议前3-4个月开始。

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.

时间线:这一步很容易需要1个月或更长时间;它还需要早在互联网草稿停止之前就开始(以允许参与者提交草稿);因此,在IETF会议前2.5-3.5个月开始。

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.

时间线:这一步很容易需要1个月或更长时间;因此,在IETF会议前2.5个月开始。

5) Submit a formal request to have a BOF. Instructions for submitting a formal request can be found at http://www.ietf.org/instructions/MTG-SLOTS.html and http://www.ietf.org/ietf/1bof-procedures.txt. 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申请。有关提交正式申请的说明,请访问http://www.ietf.org/instructions/MTG-SLOTS.html 和http://www.ietf.org/ietf/1bof-procedures.txt. 请注意,作为提出正式请求的一部分,组织者必须确定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.

如果遵循了前面的步骤,区域总监(ADs)应该能够判断是否有足够的兴趣证明批准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.

注:毫无疑问,如果此时没有一个或多个互联网草案,要求广告批准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.

时间表:秘书处发布“重要会议日期”日历以及会议信息。提交正式BOF计划请求有一个明确的截止日期(会议前约六周)。请注意,在截止日期时,AD需要有足够的BOF信息来批准或拒绝请求,因此之前的所有步骤都需要完成。

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.

10)参照导师时间表,考虑参加相关的辅导班(“工作组主席培训”、“工作组领导培训”等)。如果您正在考虑担任拟议工作组的主席,情况尤其如此。由于工作组主席和BOF主席的角色有许多相似之处,本教程中涵盖的许多主题适用于主办BOF和制定章程。

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.

在IETF中包租新工作的整个过程中,一个关键问题是理解(并找到共识),了解客户、运营商或技术部署者拥有的、工作组需要解决的真正的潜在问题是什么。当工作组完成一项工作时,工作组的输出只有在它真正解决了技术的实际用户(即客户或运营商)所面临的真正的、令人信服的问题时才有用。不幸的是,有超过几个IETF工作组的输出未被采用,在某些情况下,原因是对操作员的实际问题缺乏了解。最后,工作组的输出根本没有解决正确的问题。

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.

另一个可能发生的问题是关于特定(或竞争性)解决方案方法的讨论会使工作组(或BOF)陷入僵局,无法取得进展。在其中一些情况下,关于特定技术是否合适的争论实际上是拟议方法是否充分解决问题的代理。如果对要解决的实际根本问题缺乏明确性,则很可能存在无法解决的关于特定技术方法适用性的争论,这取决于人们对实际问题的看法以及与之相关的约束条件。因此,所有工作都必须以对根本问题的明确和共同理解为指导。

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:

对于BOF本身而言,关注底线至关重要:

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

在BOF期间,人们试图实现的目标是什么?

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

或者,换言之,在BOF结束后,您将根据什么标准来决定BOF是否成功?

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:

一个好的BOF组织者会坚定地关注BOF的目的,并制定一个支持该目标的议程。同样重要的是,不直接支持目标的演讲也应该被排除在外,因为它们往往会分散注意力,制造混乱,并使注意力偏离BOF的目的。如果目标是成立工作组,那么一切都应导致以下问题的(明显)答案:

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

会议室是否同意IETF应按照以下(具体)章程成立工作组?

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:

确保上述答案为“是”的最佳方法之一是在BOF之前进行充分准备,以确保整个社区已经同意答案为“是”。你是怎么做到的?一个好办法似乎是:

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.

举办BOF的另一个重要原因是了解与会者(以及更大的社区)对拟议工作的感受。他们是否理解并同意需要解决的问题?他们是否同意问题是可以解决的,还是需要新的协议工作?为了更好地理解一致程度,向观众提问是很有用的。

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:

在BOF发生后,建议对情况进行评估,以及下一步的步骤。广告应包括在本评估中。需要考虑的一些事项:

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.

注意,在某些情况下,很难确定工作组是否是可行的下一步。这在很大程度上取决于BOF进展的细节和/或争议项目是否可以在邮件列表上解决,或者干脆从章程中排除,然后再处理(如果有的话)。这在很大程度上还将取决于相关广告对拟议工作是否准备就绪的评估。有时,即使是一个看似有争议的BOF也可能导致工作组迅速成立——只要章程的范围适当。

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.

如果下一步是尝试组建工作组,则需要在BOF特定邮件列表上最终确定章程。一旦完成,IESG可以被要求正式考虑宪章。IESG然后(通常)将提议的章程发布到IETF列表中,以获得社区反馈,并部分根据收到的反馈做出决策。

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.

第二次转炉的期望值通常高于第一次转炉的期望值。除了通过第一个转炉完成的工作外,第一个转炉还将突出需要额外工作的关键领域。第二次转炉前的时间需要花在解决这些悬而未决的问题上。第二次BOF不应重复第一次BOF,提出相同的问题并提供相同(不满意)的答复。第二个转炉需要表明,所有先前确定的问题都已得到解决,工作组的组建现在已就绪。

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.

BOF组织者通常认为他们将主持BOF(以及最终的工作组)。这两种假设都不总是正确的。ADs需要确保转炉平稳运行并具有生产力。对于某些话题,BOF肯定会引起争议。在这种情况下,ADs可能希望有一位更有经验的人担任BOF主席或共同主席。此外,那些对组织BOF感兴趣的人往往对推动某项技术最感兴趣(并且可能对努力的方向持有强烈的观点)。如果让热情参与的各方专注于技术工作,而不是管理工作组本身,那么工作组通常会更有效。因此,如果广告想要为BOF或后续工作组选择一个或多个联席主席,不要感到惊讶(或生气!)。

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.

本文件强调了允许并积极参与关于成立工作组优点的广泛公众讨论的必要性。这可能会让一些人感到惊讶,但在形成工作组之前,并没有实际的流程要求有一个转炉。实际的过程要求只是IESG(连同赞助工程的AD)批准[RFC2418]中所述的正式章程。在实践中,BOF用于让更广泛的社区参与拟议的工作,并帮助制定可接受的章程。

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.

这里有两个观察结果。首先,举办BOF通常不是因为(严格地说)需要它们,而是因为假设它们是需要的,或者因为广告认为BOF在获得更多公众参与方面是有益的。因此,那些有兴趣成立工作组的人应该认真考虑使用上述步骤,不仅仅是为了创建BOF,而是为了说服IESG和更广泛的社区,甚至不需要BOF,正如已经证明的那样,应该成立工作组的强烈共识。其次,IESG不应忘记,BOF只是一种工具,甚至可能不是所有情况下的最佳工具。

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: narten@us.ibm.com

电话:919-254-7798电子邮件:narten@us.ibm.com