[要約] RFC 5434は、成功したBirds-of-a-Feather（BOF）セッションを行うための考慮事項を提供しています。このRFCの目的は、BOFセッションの主催者が参加者の関心を引きつけ、有意義な議論を促進するためのガイダンスを提供することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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 Birds-of-a-Feather（BOF）セッションを成功させるための戦術と戦略について説明します。特にIETFワーキンググループの形成に向けた1つのセッションについて説明します。これは、成功と失敗の両方で多数の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
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をホストする理由はたくさんあります。一部のBOFは、ワーキンググループ（WG）の形成をもたらすことを意図していません。たとえば、BOFは、IETFコミュニティに情報を提供するために、特定の問題に関するワンショットプレゼンテーションである可能性があります。別の例は、オープンミーティングを開催して、アクティブなWGに関連付けられていないが、問題を解決するために対面の相互作用が必要なドキュメントで特定のオープンな問題を議論することです。ただし、多くの場合、WGを形成することです。そのような場合、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.
- 問題の範囲は、よく定義され理解されています。つまり、人々は一般に、WGが何で機能するか（そしてそれが何をしないか）、そしてその実際の成果物が何であるかを理解しています。
- 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).
- WGには成功する合理的な確率があると考えられています（つまり、憲章をタイムリーに完成させる際）。
Additional details on WGs and BOFs can be found in [RFC2418].
WGSおよびBOFの詳細については、[RFC2418]に記載されています。
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自体の前ではなく - ではなく -
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.
タイミングの制約を認識することも重要です。以下で説明するように、BOFSのスケジューリングの期限は、IETF会議の約6週間前です。その日から後方に作業して、ドラフトを書くのに必要な時間を考慮し、公開討論を行い、広告が提案されたBOFなどを評価することを許可します。BOFが望まれます。含意により、IETF会議のわずか2か月前にBOFにつながることを目的とした作業を開始することは、ほとんどの場合、あまりにも長く待っており、次のIETF会議までBOFが遅延する可能性があります。
The recommended steps for a BOF are as follows:
BOFの推奨手順は次のとおりです。
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) 作業がすでに既存のワーキンググループの範囲内に該当する可能性があるかどうかを検討してください。個々のワーキンググループチャーターは、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) 提案されている作業に最も密接に関連するWGを識別することにより、作品が最も自然に適合するエリアまたはエリアを選択します。ワークアイテムが2つの（またはそれ以上の）異なる領域に簡単に収まることができ、誰も明らかな家ではないことを見つけることは珍しいことではないことに注意してください。
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) 特定のWGSに相談して、関心があるかどうか、または作業が範囲にあるかどうかを確認してください。これは、WGメーリングリストに直接メッセージを投稿したり、WGチェアに連絡したり、特定のWGに参加することが知られている個人に連絡することで実行できます（例：投稿または執筆した文書から）。
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) 問題や関連する作業を説明する1つ以上のインターネットドラフトを作成します。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経験を持つ人を意味します。以前にBOFSを正常にホストしたことがある個人、現在または以前のWG椅子、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）の間の分割線は正確ではありません。ある時点で、コメントできる特定の提案を使用して、1つ以上のエリアディレクター（ADS）にアプローチする必要があります。ステップ1）アイデアを、広告が目的を理解し、具体的なフィードバックを提供できるほど具体的なものにアイデアを形作るのに役立ちます。一方、ステップ1にあまり時間を費やしてはいけません。ステップ2の回答が「ああ、以前にBOFがありました。アーカイブをレビューしましたか？」したがって、手順1）と2）の間を行き来することを含むいくつかの反復があるかもしれません。また、広告との簡単な会話により、特定の個人またはWGSを提案することができます。
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.
要約すると、手順1）および2）多くの「アイデアを社交する」、つまり、多くの異なる人々と、BOFを持つことの必要性と適切性について合意を得るために多くの異なる人々と話し合うことが含まれます。そのような議論がどれほど必要かは非常に主観的ですが、BOFが適切であるという合意を得るという点で重要です。あなたがそれを正しくすることに近づいているかどうかを判断する1つの方法：初めてあなたのアイデアについて誰かに話すとき、彼らは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が欲しいと主張するだけでは十分ではありません。より広いコミュニティの関心が必要です。公開メーリングリストでは、広告（およびその他）がトピック領域に実際にどれだけの関心があるかを測定することができます。また、問題のステートメントがスコープされたなどを測定することができます。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/1bofprocedures.txtにあります。正式なリクエストの一環として、主催者は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.
注：この時点で1つ以上のインターネットドラフトがなければ、広告に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スケジューリングリクエストを提出するための確固たる期限（会議の約6週間前）があります。締め切りの時点で、広告はリクエストを承認または拒否するために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が承認され、スケジュールされていると仮定）、（メーリングリストに）焦点は、合意の領域と意見の相違の領域を特定することです。意見の相違、または「コンセンサスの欠如」は、WGを形成しない主な理由である傾向があり、「コンセンサスの欠如」が存在する特定の領域に焦点を当てることが非常に重要です。一般に、これらの意見の相違が解決された後にのみ、WGが形成されます。したがって、主な目標はコンセンサスを見つけ、意見の相違の分野を介して作業することです。あるいは、記載されている反対にもかかわらず、憲章が書かれているように、なぜ憲章が最良のものであるかについて特定のケースを作成する必要があります。
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の間に尋ねる最も重要な質問は、「次のチャーターを持つWGを形成する必要がありますか？」です。言うまでもなく、欠点を持つ憲章は（修正するのがどれほど些細なことであっても）、人々がまだ特定の言葉遣いに問題がある場合、コンセンサスを達成しません。
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 presenting). Use this time to also work through any disagreements that still remain. Do the same "in the hallway" with other interested parties!
9) 会議で、しかしBOFが開催される前に、すべてのプレゼンターとの会議を計画して、彼らがお互いに会って、議題をレビューし、誰もが彼らに期待されることを理解していることを確認してください（例えば、彼らが下にある時間の制約提示時）。この時間を使用して、まだ残っている意見の相違を実行します。他の利害関係者と同じ「廊下で」をしてください！
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）チュートリアルスケジュールを参照し、関連するチュートリアルセッション（「ワーキンググループチェアトレーニング」、「ワーキンググループリーダーシップトレーニング」などに参加することを検討してください。これは、提案されたWGの議長であることを検討している場合に特に当てはまります。WGチェアとBOFチェアの役割には多くの類似点があるため、チュートリアルでカバーされている多くのトピックがBOFのホストとチャーターの開発に適用されます。
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で新しい仕事をチャーターするプロセス全体を通して、重要な問題は、実際の根本的な問題がテクノロジーの顧客、オペレーター、または展開者が持っていること、およびWGが対処する必要があることを理解する（そしてコンセンサスを見つける）ことです。WGが努力を終えると、WGの出力は、実際にテクノロジーの実際のユーザー（つまり、顧客またはオペレーター）が直面する実際の説得力のある問題を実際に解決した場合にのみ役立ちます。残念ながら、出力が採用されていないIETF WGSがいくつかあり、そのような場合には、原因はオペレーターが抱えていた実際の問題の理解の欠如でした。最終的に、WGの出力は正しい問題に対処しませんでした。
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.
発生する可能性のあるもう1つの問題は、特定の（または競合する）ソリューションアプローチがWG（または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.
実際の問題の最良の説明と理解は、通常、テクノロジーの顧客、オペレーター、または展開から来ています。彼らは、彼らが持っている困難を最も明確に理解しているものであり（対処する必要がある）、提案されたソリューションを展開しなければならないものです。したがって、問題のステートメントの詳細を策定するときに、彼らの声を聞くことが重要です。さらに、異なるソリューションアプローチの相対的なメリットを評価する場合、より適切なアプローチを選択する際のガイダンスのために、基礎となる問題ステートメントに戻ることがしばしば役立ちます。
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の目的から集中するため、除外されるべきです。目標がWGを形成することである場合、すべてが次の質問に対する（明らかな）答えにつながるはずです。
Does the room agree that the IETF should form a WG with the following (specific) charter?
部屋は、IETFが次の（具体的な）チャーターでWGを形成することに同意しますか？
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つは、BOFの前に適切な準備を実行して、コミュニティ全体が答えが「はい」であることにすでに同意するようにすることです。どうやってそれをしますか？良い方法の1つは次のとおりです。
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の間に、アジェンダをWGの必要性をサポートすることに密接に焦点を当て、その他の方法でグループが明確にスコープされた憲章を特定し、成果物のセットがどうあるべきかについて合意していることを主張します。
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を保持するもう1つの重要な理由は、参加者（およびより大きなコミュニティ）が提案された仕事についてどのように感じるかを理解することです。彼らは解決が必要な問題を理解し、同意しますか？彼らは問題が解決可能であること、または新しいプロトコル作業が必要であることに同意しますか？合意の程度をよりよく理解するために、聴衆に質問することが役立ちます。
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) 次の憲章でWGを形成するためのサポートはありますか？（つまり、コミュニティのサポートが示すように、チャーター自体の準備ができています。）
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で議論されたチャーターの改訂（メーリングリストでのレビューと最終化の対象となる）を考えると、WGを形成する必要があると考えていますか？
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) WGを形成すべきではないと感じる人は何人ですか？（応答なしの数が重要な場合、なぜ反対されているのかと言わない人に尋ねるのに役立ちます。）
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.
残念ながら、間違った質問をすることも簡単です。いくつかの例を後のセクションに示します。
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.
BOFが行われた後、物事がどれほどうまくいったか、次のステップが何であるかを評価することをお勧めします。この評価には広告を含める必要があります。考慮すべきいくつかのこと：1）論理的な次のステップは、次のIETF会議の前にチャーターの改良とWGになることに焦点を合わせることであるため、BOFは十分にうまくいきましたか？もしそうなら、チャーターを改良し、残りのいくつかのアイテムを解決するために、メーリングリストに関する追加の議論がほぼ確実に行われます。
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.
場合によっては、WGが実行可能な次のステップであるかどうかを判断することは困難な場合があることに注意してください。多くは、BOFがどのように進んだか、および/または論争の多いアイテムをメーリングリストで解決できるか、単にチャーターから除外して後で対処できるかの詳細に依存します。また、提案された作業が前進する準備ができているかどうかの関連する広告の評価にも多くのものが依存します。一見論争的なBOFでさえ、チャーターが適切にスコープされていれば、WGが迅速に形成されることがあります。
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.
次のステップがWGを形成しようとする場合、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) BOFがより理にかなっているため、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.
2番目のBOFの期待は、一般に、最初のBOFの期待よりも高いです。最初のBOFを通じて行われた作業に加えて、最初のBOFは、追加の作業が必要な重要な領域を強調しています。2番目のBOFに至るまでの時間は、これらの顕著な問題に費やす必要があります。2番目のBOFは、最初のBOFの繰り返しであってはなりません。同じ問題が提起され、同じ（不十分な）応答が提供されます。2番目のBOFは、以前に特定されたすべての問題が解決され、WGの形成が整っていることを示す必要があります。
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 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.
1) 開始するまでずっと待っています。短期間でBOFの準備は非常に困難です。さらに、コミュニティが参加する機会がなかったBOFを承認するように求められたとき、広告は勝ちない状況に置かれます。上記のセクション2のステップ1-4は、特定の取り組みに対するコミュニティのサポートがあるという広告を示すように設計されています。これらのステップを短絡すると、広告が（通常）情報が少なすぎるという判断を行うことを強制します。さらに、コミュニティは関与していないため、重要な（および有効な）異議が提起される可能性がはるかに高くなります。多くの場合、これらの異議は事前に対処された可能性があります - もしそれらを事前に作業するのに十分な時間があったなら。
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:
質問する不合理な質問の例：
- 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リストと、ある程度関連する特定のWGリストに宣伝されるべきです。
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の目的が問題の声明とWGの必要性について合意することである場合、特定のソリューションに関するプレゼンテーション。この時点でのソリューションは、「中途半端」であり、ソリューションの側面についての議論を行うことを可能にします。代わりに、WGを形成するかどうかに合意することに焦点を当てる必要があります。
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の椅子は、プレゼンターに重要なポイントを作るのに十分な時間を与える必要があります。プレゼンターのスライドを事前に進めて、それらがトピックになり、時間スロット内に収まるようにすることは役立つかもしれません。
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（および最終的なWG）の議長を務めると想定しています。どちらの仮定も常に真実ではありません。広告は、BOFがスムーズに実行され、生産的であることを確認する必要があります。いくつかのトピックについては、BOFが論争になることは当然のことです。そのような場合、広告は、より経験豊富な人がBOFを議長または共同議長にしたいと思うかもしれません。また、BOFの組織化に関心のある人は、特定の技術の運転に最も関心があることがよくあります（そして、努力がどのような方向をとるべきかについて強く意見を持っているかもしれません）。ワーキンググループは、WG自体を管理するのではなく、熱心に関与する関係者が技術作業に集中できる場合に、より効果的になります。したがって、広告がBOFまたはフォローオンWGの1つ以上の共同議長を選択したい場合、驚かないでください（または気分を害してください！）。
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.
このドキュメントは、WGを形成するメリットに関する幅広い公開討論を許可し、積極的に関与する必要性を強調しています。驚くかもしれませんが、WGを形成する前にBOFを持つという実際のプロセス要件はありません。実際のプロセス要件は、単に[RFC2418]に記載されているように、IESG（作業を後援する広告と一緒に）が正式な憲章を承認することです。実際には、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.
ここで行うことができる2つの観察結果があります。第一に、BOFは、（厳密に言えば）必要であるためではなく、それが必要であると想定されるため、またはADがBOFが追加の一般参加を得るという点で有益であると感じているために、しばしば保持されます。したがって、WGの形成に関心のある人は、BOFを作成するためだけでなく、IESGとより広範なコミュニティにBOFが必要ではないことを納得させるために、上記のステップを使用することを真剣に検討する必要があります。、WGを形成する必要があるという強いコンセンサス。第二に、IESGはBOFが単なるツールであり、あらゆる状況で最高のツールでさえないことを忘れてはなりません。
This document has no known security implications.
このドキュメントには、セキュリティへの影響は既知のものではありません。
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.
この文書は、Jari Arkko、Brian Carpenter、Dave Crocker、Spencer Dawkins、Lisa Dusseault、Pasi Eronen、John Klensin、Tim Polk、Mark Townsley、およびBert Wijnenからの特定のフィードバックの恩恵を受けています。
[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. PO Box 12195 -BRQA/502 Research Triangle Park、NC 27709-2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
電話：919-254-7798メール：narten@us.ibm.com