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ドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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ワーキンググループの形成に向け、特に1をホストするための戦術と戦略について説明します。それは、成功と失敗の両方の数多くのBOFsに参加したの経験に基づいています。
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をホストするための多くの理由があります。いくつかのBOFsは、ワーキンググループ（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].
WGとBOFsの追加の詳細は、[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のための準備を開始する権利時間はほぼ確実に先立ち1のミーティングですここでBOFが望まれています。暗にことで、ほとんどの場合、あまりにも長い間待っているIETFミーティングにのみ2ヶ月前BOFにつながるに向けた作業を開始し、BOFは、次のIETF会合まで延期されている中でそうなります。
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）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）の仕事は、ほとんど自然に最も密接に提案された作業に関連の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）関心があるかどうかの作業がスコープ内にあるかどうかを確認するために、特定のWGに相談してください。これは、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）の問題および/または関連の仕事を記述する、一つ以上のインターネットドラフトを生成します。 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）ADは目的を理解し、具体的なフィードバックを提供できることを十分に具体的なものにアイデアを形作るのに役立ちます。ステップ2で答えが）「;あなたがアーカイブを検討している？ああ、私たちは前に一度その上BOFを持っていた」ことが判明するだろう一方、1）は、ステップ1であまりにも多くの時間を費やすべきではありません。このように、ステップ間で前後に行く含むいくつかの繰り返しがあるかもしれない1）及び2）。また、ADとの迅速な会話はあなたと相談すべきいくつかの特定の個人やのWGを提案するためにそれらを導くかもしれません。
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.
それはどのエリア提案作品のベストフィットでは不明であることが判明することがあります。このような場合には複数の広告に近づいたときに、それはおよそ同時に広告をアプローチするのが最善である、仕事がフィットするエリアであなたがわからない状態、と私はどのエリアこの作品はよく分からない」示すことによって、例えば（アドバイスを求めます最高のフィットの下で、それは、インターネットやセキュリティ、またはその両方」）であるかもしれないようです。複数の広告に接触した場合、強くあなたがあなたと会話している他のどの広告を知らせることをお勧めします。特に、1つのADは、あなたが好きではない答えを与えるならば、あなたは最初のADが期待して、言った彼女/彼に告げず、別のに行く「ADショッピング」を、行くために通常は逆効果とはお勧めできませんのより有利な答えを得ます。
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が適切である合意を得るという点で重要です。初めてのアイデアについて誰かに話すとき、彼らはすぐにBOFが順番に思えるし、すべての主要な懸念を持っていないことに同意します：あなたは右のそれを得るために接近している場合は、1つの方法は教えてくれます。
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を承認するADを依頼することが一般的に無意味であることは言うまでもないです。
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週間前に会議に）しっかりと期限があります。締め切りの時点で、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（BOFが承認およびスケジュールされていると仮定して）前に2~4週間の間、メーリングリストにフォーカス（）契約と不一致の領域の領域を同定することにあるべきです。不一致、または「コンセンサスの欠如」ので、「コンセンサスの欠如は、」決定的に重要で存在するこれらの特定分野に焦点を当て、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のWGよりも多くありました。最後に、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.
起こることができるもう一つの問題は、進捗状況を作るために、それができなくなって、特定の（または競合する）効果的にWG（またはBOF）をstalematingソリューションのアプローチについての議論です。これらの例のいくつかでは、特定の技術の妥当性についての議論は、実際に提案されたアプローチが適切に問題に対処するかどうかの問題のためのプロキシです。解決すべき実際の根本的な問題についての明確性の欠如がある場合は、十分に実際の問題と、それに関連付けられた制約の1つのビューに応じて、特定の技術的なアプローチの適合性について、解決できない引数があるかもしれません。したがって、それは根本的な問題を明確にし、共通の理解によって導かれるすべての作業のために重要です。
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?
それは1つが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:
上記の「はい」の回答を確保するための最良の方法の一つは、全体としてコミュニティはすでに答えは「イエス」であることに同意することを確認するために、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の間に）または1つは、これらの懸念が再び（上げることができ - - （一つは、事前に懸念に対処することができます - と事前合意を得た場合には、提案憲章は、合意を得るために十分ではないだろうと思われます）実際の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を保持するためのもう一つの重要な理由は、参加者（およびより大きなコミュニティが）提案の仕事についてどのように感じているかの理解を確立することです。彼らが理解し、解決する必要のある問題について合意していますか？彼らは、問題が解決可能である、または新しいプロトコルの作業が必要であることに同意しますか？より良い一致度を理解するには、聴衆の質問をするのに便利です。
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）以下の書類（S）用のエディタとしての役割を果たすことをいとわない誰ですか？ （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:
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ミーティングの前にWGになるに集中することであることを十分に行っていましたか？もしそうなら、ほぼ確実にチャーターを洗練して、いくつかの残りの項目を動作するようにメーリングリストで追加の議論があるだろう。
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が行った方法の詳細に依存しますずっと。多くはまた、提案された作品が前方に移動する準備ができているかどうかの関連するADの評価に依存します。時には一見論争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.
第BOFへの期待が初期BOFのものよりも一般に高いです。最初のBOFを通じて、最大行われた作業に加えて、最初のBOFは、追加の作業が必要とされている主要な分野を強調しているだろう。二BOFに至るまでの時間は、これらの未解決の問題を通して作業に費やしたする必要があります。第二BOFsは、同じ問題が発生し、同じ（不十分な）応答が提供されていると、最初のBOFの繰り返しであってはなりません。二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
1）始める前に、あまりにも長い間待っています。短期間でのBOFのために準備することは非常に困難です。コミュニティが参加する機会がなかったため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.
特定の努力のためのコミュニティサポート。これらのステップを短絡すると、（通常は）あまりにも少ない情報で審判の判定を作るためにADを強制します。コミュニティが関与していなかったので、また、それが重要な（かつ有効な）異議が提起されることがはるかに可能性があります。多くの場合、これらの異議は、事前に対処されている可能性 - 事前にそれらを介して動作するのに十分な時間がありました。
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のより基本的な目的に邪魔されratholesを開くべきではありません。問題のあるプレゼンテーションの例：
- 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の必要性について合意を得ることです。この時点でのソリューションは、あまりにも多くの場合、「半焼き」であり、議論は解決策の側面にratholeすることができます。代わりに、フォーカスは、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自体を管理する上よりも、技術的な仕事に専念させるとより効果的です。このように、驚いて（または気分を害する！）されていないADが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]に記載されているように（一緒にAD（S）作業のスポンサー付き）IESG正式なチャーターを承認することは、単純です。実際には、BOFsは、提案された作業に関するより広範なコミュニティに係合するようにして許容できるチャーターを生成するために使用されます。
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つの観測があります。まず、BOFsはしばしば開催され、彼らは（厳密に）されているので必要ですが、それが想定されるため、彼らは必要とされているか、広告がBOFが、追加の市民参加を得るという点において有益であることを感じるので。したがって、WGを形成することに興味のある人は、ちょうどBOFを作成する目的のためではない上記の手順を使用して真剣な考慮を払う必要がありますが、すでに実証されているとして、IESGとBOFも必要とされていない広範な地域社会を説得するためにWGが形成されるべきであること、強いコンセンサス。第二に、IESGはBOFsは、単にツールであることを忘れてはならない、とさえあらゆる状況で最適なツールではないかもしれません。
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.
この文書では、ヤリArkko、ブライアン・カーペンター、デイブ・クロッカー、スペンサードーキンスリサDusseault、パシEronen、ジョン・クレンシン、ティムポーク、マークTownsley、およびバートWijnenから特定のフィードバックの恩恵を受けています。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418]ブラドナーの、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
トーマスNarten氏IBMコーポレーション3039コーンウォリスアベニュー。私書箱12195 - BRQA / 502リサーチトライアングルパーク、ノースカロライナ州27709から2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
電話：919-254-7798 Eメール：narten@us.ibm.com