Network Working Group T. Hardie
Request for Comments: 3929 Qualcomm, Inc.
Category: Experimental October 2004
Alternative Decision Making Processes
for Consensus-Blocked Decisions in the IETF
Status of this Memo
このメモの位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document proposes an experimental set of alternative decision-making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed.
この文書は、IETFワーキンググループで使用するための代替意思決定プロセスの実験セットを提案しています。グループは、特定の決定がなされなければならないが、判決自体に同意することはできませんコンセンサスに来ているIETFワーキンググループでは例数が少ないがあります。この文書では、これらのケースでの意思決定に到達するための代替メカニズムについて説明します。これは完全なリストを提供することではなく、必要なときに使用できるツールの既知のセットを提供するものではありません。
Dave Clark's much-quoted credo for the IETF describes "rough consensus and running code" as the key criteria for decision making in the IETF. Aside from a pleasing alliteration, these two touchstones provide a concise summary of the ideals that guide the IETF's decision making. The first implies an open process in which any technical opinion will be heard and any participant's concerns addressed; the second implies a recognition that any decision must be grounded in solid engineering and the known characteristics of the network and its uses. The aim of the IETF is to make the best possible engineering choices and protocol standards for the Internet as a whole, and these two principles guide it in making its choices and standards.
IETFのためのデイブ・クラークの多くの引用符で囲まれた信条は、IETFにおける意思決定のための重要な基準として「ラフコンセンサスとランニングコード」を記載します。別に楽しい頭韻から、これら二つの試金石は、IETFの意思決定を導く理想の簡潔な概要を提供します。最初は、技術的な意見を聞くことができますし、任意の参加者の懸念に対処するオープンなプロセスを意味します。第二は、任意の決定は固体工学および既知のネットワークの特性及びその用途に接地されなければならないことを認識することを意味します。 IETFの目的は、全体として、インターネットのために可能な限り最高のエンジニアリングの選択肢とプロトコル標準を作ることであり、これらの2つの原則は、その選択肢や基準を作る際に、それを導きます。
In a small number of cases, working groups within the IETF cannot reach consensus on a technical decision that must be made in order to ensure that an interoperable mechanism or set of standards is available in some sphere. In most of these cases, there are two or more competing proposals at approximately the same level of technical maturity, deployment, and specification. In some cases, working groups can achieve consensus to advance multiple proposals and either to revisit the question with experience or to build the required mechanisms to handle multiple options for the life of the protocol. In other cases, however, a working group decides that it must advance a single proposal.
例少数では、IETF内のワーキンググループは、標準の相互運用可能な機構やセットは、いくつかの分野で利用可能であることを確実にするためになされなければならない技術的な意思決定について合意に達することができません。これらのケースのほとんどでは、ほぼ同じ技術的な成熟度のレベル、展開、および仕様で、二つ以上の競合する提案がなされています。いくつかのケースでは、ワーキンググループは、複数の提案を進めると経験で質問を再訪するか、プロトコルの生活のために複数のオプションを処理するために必要な仕組みを構築するためにどちらかのコンセンサスを達成することができます。他の例では、しかし、ワーキンググループは、単一の提案を進めなければならないことを決定しました。
Choosing among proposals can be difficult especially when each is optimized for slightly different use cases, as this implies that the working group's best choice depends on the participants' views of likely future use. Further problems arise when different proposals assign costs in implementation, deployment, or use to different groups, as it is a normal human reaction to seek to prevent one's own ox from being gored.
提案の中から選択すると、これはワーキンググループの最良の選択の可能性が高い将来の使用の参加者の見解に依存していることを暗示するように、それぞれが、わずかに異なるユースケース用に最適化されている場合は特に困難な場合があります。さらなる問題は、さまざまな提案が実装、導入にコストを割り当てる場合に発生する、またはそれがgoredされているから、自分の牛を防ぐために追求する正常なヒトの反応があるとして、異なるグループに使用します。
This document proposes a set of experimental mechanisms for use in such cases. To gauge the results of the use of these mechanisms, the Last Call issued to the IETF community should note such a mechanism is being used and which proposal among the set was chosen. If and when the community becomes satisfied that one or more of these methods is useful, it should be documented in a BCP.
この文書では、このようなケースでの使用のための実験的なメカニズムのセットを提案しています。これらのメカニズムの使用の結果を評価するために、IETFコミュニティに発行された最後のコールは、そのようなメカニズムが使用されており、セットの中どの案が選ばれました注意してください。そしてコミュニティがこれらのいずれかの方法が有用であることを満足になった場合なら、それはBCPに文書化されなければなりません。
In no way should this experiment or any future BCP for this small number of cases take precedence over the IETF's normal mode of operation.
決してこの例数が少ないため、この実験や将来のBCPは、操作のIETFの通常モードよりも優先されなければなりません。
The Conflict Research Consortium at the University of Colorado outlines the pros and cons of consensus as follows:
次のようにコロラド州の大学で紛争研究コンソーシアムは、コンセンサスの長所と短所の概要を示します。
The advantage of consensus processes is that the resulting decision is one that meets the interests of all the parties and that everyone can support. The disadvantage is that developing such a decision can be a very slow process, involving many people over a long period of time. There is also a relatively high probability of failure. If a quick decision is needed, the consensus approach may not work. Consensus rule processes also tend to favor those that oppose change and want to preserve the status quo. All these people have to do is refuse to support any consensus compromises and they will win (at least as long as they can delay change) [CONFLICT].
コンセンサス・プロセスの利点は、得られた決定はすべての当事者の利益に合致し、誰もがサポートできる1つであるということです。欠点は、そのような決定を開発することは、長期間にわたって多くの人々を含む、非常に遅いプロセスになることができるということです。失敗の比較的高い確率もあります。迅速な意思決定が必要な場合は、コンセンサスアプローチが動作しない場合があります。コンセンサスルールプロセスも変更に反対し、現状を維持したいものを好む傾向があります。すべてのこれらの人々は、任意のコンセンサス妥協をサポートすることを拒否されなければならないと、彼らは（少なくとも限り、彼らは変更を遅らせることができますよう）[CONFLICT]勝ちます。
Using "rough consensus" as a guideline limits some of the disadvantages of consensus processes by ensuring that individuals or small factions cannot easily block a decision that otherwise has general support. The touchstone of "running code" can also limit the disadvantages of consensus processes by requiring that statements opposing particular proposals be technically grounded.
ガイドラインとして「ラフコンセンサス」を使用することで、個人や小派閥が簡単そうでない一般的なサポートを持って意思決定をブロックしないことを確実にすることで、コンセンサスの方法の欠点の一部を制限します。 「コードを実行する」の試金石は、特定の提案に対向文が技術的に接地することを要求することにより、コンセンサスプロセスの欠点を制限することができます。
These limitations do not change the core mechanisms of consensus-building, however, and the IETF process continues to require individual participants both to use their best engineering judgment to select among proposals and to balance their own interests with those of the Internet as a whole. Active participation and a willingness to compromise, possibly on key points, are needed. Historically, this has worked because a large majority of participants have recognized that the Internet's growth and enhancement are more important overall than any specific short-term advantage.
これらの制限は、しかし、合意形成のコアメカニズムを変更しないと、IETFプロセスは、提案の中から選択するために最善工学的判断を使用し、インターネット全体のものと自分の利益のバランスをとるために、個々の参加者の両方を必要とし続けています。積極的な参加と、おそらく重要なポイントで、妥協する意欲が必要です。歴史的に、これは、参加者の大多数は、インターネットの成長と強化が任意の特定の短期的なメリットよりも全体的にもっと重要であると認識しているので、取り組んできました。
In other words, "rough consensus" is sufficient in most cases in the IETF to ensure not only that individuals or small groups are heard when they raise technical objections, but also that they cannot block progress when general agreement has been reached. This document does not suggest changing the usual mechanisms for achieving progress; it proposes mechanisms for use when a working group has consensus that it must make a decision but cannot make that decision by the usual rules.
言い換えれば、「ラフコンセンサスは、」彼らは技術的な異議を提起する場合、個人や小グループが聞こえていることだけではなく、確実にするために、だけでなく、一般的な合意に達したとき、彼らは進歩をブロックできないことをIETFにおけるほとんどのケースで十分です。この文書では、進捗状況を達成するための通常のメカニズムを変更示唆していません。ワーキンググループは、それが決定を下す必要がありますが、通常の規則によってその判断を下すことができないの合意がある場合には、使用するためのメカニズムを提案しています。
In general, working groups should consider using alternate decision-making processes when it is clear both that a choice must be made and that the choice cannot be made with continued discussion, refinement of specifications, and implementation experience. A guideline for determining whether these conditions have been met is included below.
一般的には、ワーキンググループは、選択がなされなければならないの両方のことと選択肢が継続的な議論、仕様の改善、および実装経験で行うことができないことは明らかであるとき、代替意思決定プロセスを使用して検討すべきです。これらの条件が満たされているかどうかを判断するためのガイドラインは、以下に含まれています。
There must be a clear statement of the decision to be reached. This may be in the working group's charter, in requirements documents, or in other documents developed by the working group. Prior to any invocation of an alternate decision making process, the Chair(s) should confirm with the working group that there is general agreement on the decision to be reached. This should include a specific consensus call on whether the working group can advance multiple proposals or must select a single proposal for the work item.
到達するための意思決定の明確な声明がなければなりません。これは、ワーキンググループの憲章では、要件文書に、またはワーキンググループによって開発された他の文書であってもよいです。代替的な意思決定プロセスの任意の呼び出しの前に、椅子（単数または複数）の決定に到達するために一般的な合意があることをワーキンググループに確認しなければなりません。これは、ワーキンググループが複数の提案を進めることができるか、作業項目のための単一の提案を選択しなければならないかどうかについての具体的なコンセンサスの呼び出しを含める必要があります。
Proposed solutions must be available as Internet-Drafts and must be sufficiently specified so that the Chair(s) believe they could be published as an IETF specification, possibly with further refinement. If the Chair indicates that a proposed solution is insufficiently specified, concrete problems must be identified, and a reasonable amount of time provided to resolve those problems must be provided. Note that if one of the proposed solutions is "do nothing", an explicit Draft to that effect must be available; it may, however, be produced when the group invokes an alternate decision-making process.
提案されたソリューションは、インターネットドラフトとして利用可能でなければならず、議長（s）は、彼らはおそらく、さらに洗練された、IETF仕様として公開される可能性が信じていることを十分になるように指定する必要があります。議長が提案された解決策が不十分に指定されていることを示している場合、具体的な問題が識別されなければならない、とそれらの問題を解決するために提供される時間の合理的な金額を用意する必要があります。提案された解決策の一つが、「何もしない」であれば、その旨を明示的な案が利用可能でなければならないことに注意してください。グループ代替意思決定プロセスを呼び出すときには、しかしながら、製造することができます。
3.3. The working group has discussed the issue without reaching resolution
3.3. ワーキンググループは、解像度に到達することなく、問題を議論しています
Consensus-building requires significant amounts of discussion, and there is no general rule for indicating how much discussion a technical issue requires before a group should reach consensus. If there is any question about whether the discussion has been sufficient, the working group chair(s) should always err on the side of allowing discussion to continue. Before using an alternate decision making process, the working group chair(s) should also make an explicit call for consensus, summarizing the technical issues and the choice to be made. If new technical points are made during the call for consensus, discussion should continue. If no new points are raised, but the group cannot come to consensus, the working group may consider using an alternate decision making process. Under no circumstances is the working group required to use an alternate decision-making process.
合意形成は、議論を大量に必要とし、グループが合意に達する必要があります前に、技術的な問題が必要とどのように多くの議論を示すための一般的なルールはありません。議論が十分なされているかどうかについての疑問がある場合は、ワーキンググループの議長（複数）は、常に議論が継続できるようにするのに越し必要があります。別の意思決定プロセスを使用する前に、ワーキンググループ議長（複数可）も行うことが技術的な問題と選択肢をまとめ、合意のための明示的な呼び出しを行う必要があります。新しい技術的なポイントはコンセンサスのための呼び出し中に行われた場合、議論は継続すべきです。新しいポイントが提起されていないが、グループはコンセンサスに来ることができない場合は、ワーキンググループは、代替意思決定プロセスを使用して検討することができます。いかなる状況下で代替意思決定プロセスを使用するために必要なワーキンググループです。
3.4. There is an explicit working group last call to use an alternate method
3.4. 別の方法を使用する明示的なワーキンググループの最後の呼び出しがあります
In item 3.3 above, it is noted that the Chair(s) should make an explicit call for consensus on the technical issues and should proceed only after that call has yielded no forward progress. A different Last Call on whether to use an alternate decision-making method is required, with a stated period for comments by working group members. This is to indicate that the decision to use an alternate method should be taken at least as seriously as the decision to advance a document on the standards track. It also provides a clear signal that this is a last moment for participants to reconsider their positions. The decision to use an alternate decision making process requires the rough consensus of the working group, as determined by the Chair(s). The choice of which process to use may be made in the Last Call or may be the subject of separate discussions within the working group. If the group comes to consensus that an alternative method is required but does not come to consensus on the method to use, an external review team (c.f. section 4.1, below) will be formed.
アイテム上記3.3には、椅子（s）は技術的な問題について合意するための明示的な呼び出しを行うべきであり、そのコールはない前進が得られなかった後にのみ進行しなければならないことに留意されたいです。別の意思決定の方法を使用するかどうかの異なるラストコールは、ワーキンググループのメンバーのコメントのための規定の期間に、必要です。これは、別の方法を使用するという決定は、標準化過程の上のドキュメントを進める意思決定と少なくとも同じ真剣に取られるべきであることを示すためです。また、これは、参加者が自分の位置を再考するための最後の瞬間であるという明確なシグナルを提供します。椅子によって決定されるように、代替の意思決定プロセスを使用するという決定は、ワーキンググループのラフコンセンサスを必要とします。使用するプロセスの選択は、ラストコールで行うことができるか、ワーキンググループ内の別の議論の対象となる場合があります。グループは、別の方法が必要とされているが、使用する方法について合意に達していないコンセンサスになる場合は、外部評価チーム（C.F.セクション4.1は、以下）に形成されます。
In discussions regarding this document, several points have been raised about the viability of any mechanism that requires consensus to use an alternative to consensus-based decision making. Some individuals have pointed out that groups having trouble achieving consensus on a technical matter may have similar problems achieving consensus on a procedural matter. Others have been concerned that this will be used as an attempt to end-run around rough consensus. These are valid concerns, and they point both to the need to retain rough consensus as the baseline mechanism and the need to exercise caution when using these alternate methods. More importantly though, they highlight the nature of these alternatives. They are primarily mechanisms that allow people to recognize the need for compromise in a new way, by backing away from entrenched technical positions and by putting the technical choice in the hands of the broader community. They highlight that the choice for each participant is now between achieving a result and failure.
この文書に関する議論では、いくつかの点では合意に基づく意思決定への代替を使用するための合意を必要とするあらゆるメカニズムの実行可能性について提起されています。いくつかの個体は、技術的な問題に関するトラブル達成コンセンサスを有する基が、手続きの問題について合意を達成する同様の問題を抱えていることが指摘されています。他の人はこれが荒いコンセンサスを中心に、実行を終了しようとする試みとして使用されることが懸念されています。これらは有効な懸念事項であり、それらは、ベースラインのメカニズムとこれらの代替方法を使用する際には注意を払う必要性などラフコンセンサスを維持する必要性の両方を指します。さらに重要なことは、しかし、彼らはこれらの選択肢の性質を強調表示します。彼らは主に、人々が離れて定着し技術職からのバックアップでより広範なコミュニティの手に技術的な選択肢を置くことによって、新しい方法で妥協の必要性を認識させる仕組みです。彼らは、各参加者のための選択が結果と失敗の達成の間で今であることを強調しています。
There is a fundamental tension between the IETF community's desire to get the best decision for a particular technical problem and its desire to get a decision that has community buy-in in the form of rough consensus. These mechanisms cannot resolve that fundamental tension. They may, however, provide a way forward in some situations that might otherwise end in a deadlock or stagnation.
特定の技術的な問題やラフコンセンサスの形でコミュニティバイインを持って意思決定を得るためにその欲求のために最善の決断を取得するためのIETFコミュニティの欲望の間には根本的な緊張があります。これらのメカニズムは、その根本的な緊張を解決することはできません。彼らは、しかし、そうでない場合は、デッドロックまたは停滞に終わるかもしれないいくつかの状況で進むべき道を提供することができます。
In setting up an alternate method, care must be taken that the process by which the decision is reached remains open and focused on the best technical choice for the Internet as a whole. The steps set out below provide a straw proposal for four such mechanisms. These systems are relatively heavyweight, partially to highlight the gravity of invoking these methods and partially to ensure that the IETF community as a whole is alerted to and kept informed of the process. Note that alternate procedures have been used in the past; see [RFC3127] for a description of that used in the decision between two competing candidate protocols for Authentication, Authorization, and Accounting. By setting out these proposals, this document does not intend to limit working group choice but intends to provide a set of well-defined processes that obviate the need for reinvention in most cases.
別の方法を設定するには、注意が意思決定に到達するプロセスが開いたままであることに注意しなければならないと全体としてのインターネットのための最高の技術の選択に焦点を当てました。下記に示す手順では、このような4つのメカニズムのためのわらの提案を提供しています。これらのシステムは、部分的にこれらのメソッドを呼び出すの重力を強調するために、部分的に全体としてIETFコミュニティはに警告およびプロセスが通知保たれていることを保証するために、比較的重量級です。代替の手順は、過去に使用されてきたことに留意されたいです。認証、許可、およびアカウンティングのための2つの競合する候補プロトコル間の決定に使用されるものの説明については、[RFC3127]を参照。これらの提案を設定することで、この文書はワーキンググループの選択を制限するつもりはなく、ほとんどの場合、改革の必要性を除去明確に定義されたプロセスのセットを提供することを意図していません。
The working group notifies the IETF community that it intends to form an external review team by making a public announcement on the IETF-announce mailing list. That announcement should include a summary of the issue to be decided and a list of the Internet-Drafts containing the alternate proposals. It should also include the name and location of an archived mailing list for the external review team's deliberations.
ワーキンググループは、IETF-announceメーリングリストに公告を行うことによって、外部レビューチームを形成していきIETFコミュニティに通知します。発表が決定する問題の概要と代替案を含むインターネットドラフトのリストを含める必要があります。また、外部審査チームの審議のためにアーカイブされたメーリングリストの名前と場所を含める必要があります。
External review teams have five members who must meet the same eligibility requirements as those set out for a voting member of the NomCom [RFC3777]. Explicitly excluded from participation in external review teams are all those who have contributed to the relevant working group mailing list within the previous twelve months, the IESG, the IAB, and the members of an active NomCom.
外部レビューチームはNomCom [RFC3777]の投票メンバーにしたものと同じ資格要件を満たさなければならない5人のメンバーを持っています。過去12ヶ月以内に、関連するワーキンググループのメーリングリストに貢献してきたすべての人を明示的に外部審査チームへの参加から除外され、IESG、IAB、およびアクティブNomComのメンバー。
Volunteers to serve on the review team send their names to the IETF executive director. Should more than five volunteer, five are selected according to the process outlined in [RFC3797]. Note that the same rules on affiliation apply here as to the NomCom, to reduce the burden on any one organization and to remove any implication of "packing" the review team.
レビューチームに奉仕するボランティアは、IETFのエグゼクティブディレクターに自分の名前を送信します。以上5人のボランティアよりも、5は、[RFC3797]に概略を示す方法に従って選択されるべきです。いずれかの組織の負担を軽減するために、レビューチームを「梱包」のいずれかの意味を削除するには、所属の同じ規則がNomComに、ここで適用されることに注意してください。
Participants in the working group may actively solicit others to volunteer to serve on the review team but, as noted above, they may not serve themselves if they have commented on the list within the previous twelve months.
積極的に他人を勧誘するワーキンググループの参加者は、上述のように、彼らは過去12ヶ月以内にリストにコメントしている場合、彼らは自分たちに仕えていないことが、レビューチームに奉仕するボランティアだけに。
The external review team is alloted one month for deliberations. Any member of the team may extend this allotment by two weeks by notifying the relevant working group Chair(s) that the extension will be required.
外部評価チームは、審議のために1ヶ月allotedされます。チームのメンバーは、拡張が必要とされること、関連するワーキンググループチェア（単数または複数）を通知することによって、2週間、この割当てを拡張することができます。
The team commits to reading the summary provided during the IETF announcement and all of the relevant Internet-Drafts. Members may also read the archived mailing list of the working group and may solicit clarifications from the document authors, the working group chairs, or any other technical experts they choose. All such solicitations and all deliberations among the review team of the proposals should take place on the archived mailing list mentioned in the IETF announcement. The team members may, of course, have one-on-one discussions with relevant individuals by phone, email, or in person, but group deliberations should be on the archived list.
チームは、関連するインターネットドラフトのIETF発表し、すべての間に提供要約を読みにコミットします。また、メンバーは、ワーキンググループのアーカイブされたメーリングリストを読むことができるし、文書の作成者、ワーキンググループチェア、またはそれらが選択した任意の他の技術専門家からの明確化を求めることがあります。このようなすべての勧誘や提案の審査チームの中で、すべての審議は、IETF発表で言及アーカイブメーリングリストで行われるべき。チームのメンバーは、もちろん、電話、電子メール、または人ですることにより、関連する個人との一対一の議論があるかもしれませんが、グループの審議は、アーカイブされたリストにする必要があります。
Each member of the external review team writes a short decision statement, limited to one page. That decision statement contains a list of the proposals in preference order. It may also contain a summary of the review team member's analysis of the problem and proposed solutions, but this is not required. These decision statements are sent to the archived mailing list, the relevant working group chair(s), and the IESG.
外部レビューチームの各メンバーは1ページに制限され、短い決定文を書き込みます。この決定文は、優先順位の提案のリストが含まれています。また、問題と提案されたソリューションの審査チームメンバーの分析の要約を含んでいてもよいが、これは必須ではありません。これらの決定文はアーカイブのメーリングリストに送信され、関連するワーキンググループ議長（S）、およびIESG。
The decision statements will be tallied according to "instant-runoff voting" rules, also known as "preference voting" rules [VOTE].
決定文は、「嗜好投票」ルール[VOTE]としても知られている「インスタント流出投票」規則に従って集計されます。
This mechanism allows the working group to designate a review team that involves those outside the working group and those who have been involved in the process within the working group. Although it may appear that having a single representative of each proposal will have a null effect on the outcome, this is unlikely, except when there is a binary choice, because of the rules for decision-statement processing (c.f. 4.1.4.). As in 4.1, the working group notifies the IETF community that it intends to form a mixed review team by making a public announcement on the IETF-announce mailing list. That announcement should include a summary of the issue to be decided and a list of the Internet-Drafts containing the alternate proposals. It should also include the name and location of an archived mailing list for the external review team's deliberations.
このメカニズムは、ワーキンググループは作業グループ外のものと、作業グループ内のプロセスに関わってきた人々が関与レビューチームを指定することができます。それは、各提案の単一の代表を持つことが結果にヌル影響を与えるように見えるかもしれないが、これは決定文の処理のための規則で、バイナリの選択肢がある場合を除いて、ほとんどありません（4.1.4 C.F.。）。 4.1のように、ワーキンググループは、IETF-announceメーリングリストに公告を行うことによって混合レビューチームを形成していきIETFコミュニティに通知します。発表が決定する問題の概要と代替案を含むインターネットドラフトのリストを含める必要があります。また、外部審査チームの審議のためにアーカイブされたメーリングリストの名前と場所を含める必要があります。
Mixed review teams are composed of one designated representative of each of the proposals, typically the Internet-Draft's principal author, and six external members. Five of the external members are selected per 4.1.1. above. The sixth is designated by the IESG as a chair of the group. Though the primary role of the chair is to ensure that the process is followed, she or he may vote and engage in the deliberations.
ミックスレビューチームは、一つの提案のそれぞれの指定された代表、一般的にインターネットドラフトの主要執筆者、および6人の外部メンバーで構成されています。外部メンバーのファイブは、4.1.1ごとに選択されています。上記。第六のグループの椅子としてIESGによって指定されます。椅子の主な役割は、プロセスが続いていることを確実にするためですが、彼女または彼が投票し、審議に従事することができます。
The review team is alloted one month for its deliberations, and any member of the team may extend that allotment by two weeks by notifying the review team Chair this the extension will be required.
レビューチームは、その審議のために1ヶ月allotedされ、チームのメンバーは、この拡張が必要になるレビューチームの議長に通知することによって、二週間でその割当てを延長することができます。
The review team commits to reading the summary provided during the IETF announcement and all of the relevant Internet-Drafts. Members may also read the archived mailing list of the working group, and of any other technical experts as they see fit. All such solicitations and all deliberations among the review team of the proposals should take place on the archived mailing list mentioned in the IETF announcement.
レビューチームは、関連するインターネットドラフトのIETF発表し、すべての間に提供要約を読みにコミットします。彼らが合うようにメンバーはまた、ワーキンググループのアーカイブされたメーリングリストを読んで、他の技術専門家のこと。このようなすべての勧誘や提案の審査チームの中で、すべての審議は、IETF発表で言及アーカイブメーリングリストで行われるべき。
As in 4.1.3, above.
4.1.3と同様に、上記の。
As in 4.1.4, above.
4.1.4と同様に、上記の。
As in 4.1 and 4.2, the working group notifies the IETF community that it plans to use an alternate decision mechanism by making a public announcement on the IETF-announce mailing list. That announcement should include a summary of the issue to be decided and a list of the Internet-Drafts containing the alternate proposals.
4.1と4.2のように、ワーキンググループは、IETF-announceメーリングリストに公告を行うことによって、代替決定メカニズムを使用する予定IETFコミュニティに通知します。発表が決定する問題の概要と代替案を含むインターネットドラフトのリストを含める必要があります。
In this method, a single working group participant is selected to make the decision. Any individual who has contributed to the working group in the twelve months prior to the working group Last Call on the technical question (c.f. 3.3, above) may volunteer to serve as the decision maker. Individuals may qualify as participants by having made a public statement on the working group mailing list, by serving as an author for an Internet-Draft under consideration by the working group, or by making a minuted comment in a public meeting of the working group. The Chair(s) may not volunteer. Each qualified volunteer sends her or his name to the working group chair and the IETF Executive Director within three weeks of the announcement sent to the IETF-announce mailing list. The IETF Executive Director then uses the selection procedures described in [RFC3797] to select a single volunteer from the list. That volunteer decides the issue by naming the Internet-Draft containing the selected proposal in an email to the relevant working group chair, the working mailing list, and the IESG.
この方法では、単一のワーキンググループの参加者は、決定を行うために選択されています。 （上記、3.3 C.F.）前にワーキンググループの技術的な質問にラストコールへの12ヶ月の間にワーキンググループに貢献した任意の個人が意思決定者として機能するようにボランティアがあります。個人は、ワーキンググループで検討中でインターネットドラフトのための著者として働くことによって、またはワーキンググループの公開会合でminutedコメントをすることによって、ワーキンググループのメーリングリストに公式声明を作ったことで、参加者としての資格があります。議長（複数可）ボランティアなくてもよいです。各資格のボランティアには、IETF-announceメーリングリストに送られた発表の3週間以内にワーキンググループの議長とIETFのエグゼクティブ・ディレクターに彼女や彼の名前を送信します。 IETF理事は、リストから単一のボランティアを選択するために、[RFC3797]に記載の選択手順を使用します。そのボランティアは、関連するワーキンググループの議長、作業メーリングリスト、およびIESGに電子メールで選択した提案書を含むインターネットドラフトに名前を付けることで、問題を決定します。
Among the small number of cases for which consensus is not an appropriate method of decision-making are an even smaller number for which the decision involves no technical points at all and a need to select among options randomly. The IDN working group, as an example, needed to designate a specific DNS prefix. As the decision involved early access to a scarce resource, a random selection was required. In such cases, a working group may ask IANA to make a random assignment from among a set of clearly delineated values. Under such circumstances, IANA will be guided by [RFC3797] in its selection procedures. Under extraordinary circumstances, the working group may, with the approval of the IESG, ask IANA to select among a pool of Internet-Drafts in this way.
コンセンサスは、意思決定の適切な方法されていない症例の少数の中の決定は全く技術的ポイントを伴わないれるさらに小さい数とランダムオプションの中から選択する必要があります。 IDNワーキンググループは、一例として、特定のDNSプレフィックスを指定する必要がありました。希少資源への早期アクセスを関与決定として、ランダムな選択が必要でした。このような場合には、ワーキンググループが明確に線引き値のセットの中からランダムに割り当てを作るためにIANAを求めることができます。このような状況下では、IANAは、その選択手順に[RFC3797]によって導かれます。異常な状況下では、ワーキンググループは、IESGの承認を得て、このようにインターネットドラフトのプールの中から選択するIANAを求めることができます。
The technical decisions made by these processes may be appealed according to the same rules as any other working group decision, with the explicit caveat that the working group's consensus to use an alternate method stands in for the working group's consensus on the technical issue.
これらのプロセスによって作られた技術的な決定は、別の方法を使用するには、ワーキンググループのコンセンサスは、技術的な問題に関するワーキンググループのコンセンサスのためで立っていることを明示的に警告して、他のワーキンググループの決定と同じルールに従って上訴することができます。
The risk in moving to a system such as this is that it shifts the basis of decision making within the IETF. In providing these mechanisms, it is hoped that certain decisions that may be intractable under consensus rules may be reached under the rules set out here. The risk, of course, is that forcing the evaluation to occur under these rules may allow individuals to game the system.
このようなシステムへの移行におけるリスクは、それはIETF内の意思決定の基礎をシフトしていることです。これらのメカニズムを提供するには、コンセンサス規則の下で手に負えないかもしれ特定の意思決定がここに設定されたルールの下に到達することができることが期待されます。リスクは、当然のことながら、これらの規則の下で発生する評価を強制的に個人がシステムをゲームすることを可能にするということです。
Section 4.3 may require the IANA to make random selections among a known set of alternates.
4.3節は、交互の既知のセットの中からランダムに選択を行うためにIANAが必要な場合があります。
[RFC3797] Eastlake, D., "Publicly Verifiable Nomination Committee (NomCom) Random Selection", RFC 3797, June 2004.
[RFC3797]イーストレイク、D.、 "公開検証指名委員会（NomCom）ランダムに選択"、RFC 3797、2004年6月。
[RFC3777] Galvin, J., Ed. "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
[RFC3777]ガルビン、J.、エド。 「IABとIESGの選択、確認、およびリコール処理：指名とリコール委員会の操作」、BCP 10、RFC 3777、2004年6月。
[RFC3127] Mitton, D., StJohns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.
[RFC3127]ミットン、D.、StJohns、M.、バークリー、S.、ネルソン、D.、パティル、B.、スティーブンス、M.、およびB.ヴォルフ、 "認証、認可、およびアカウンティング：プロトコル評価"、 RFC 3127、2001年6月。
[VOTE] Center for Democracy and Voting. "Frequently Asked Questions about IRV", http://www.fairvote.org/irv/faq.htm.
[VOTE]民主主義と投票のためのセンター。 http://www.fairvote.org/irv/faq.htm、「よくIRVについてのよくあるご質問」。
[CONFLICT] International Online Training Program on Intractable Conflict,"Consensus Rule Processes", Conflict Research Consortium, University of Colorado, USA. http://www.colorado.edu/conflict/peace/treatment/ consenpr.htm
[CONFLICT]難治紛争に関する国際オンライン・トレーニング・プログラム、「コンセンサスルール・プロセス」、紛争研究コンソーシアム、コロラド大学、USA。 http://www.colorado.edu/conflict/peace/treatment/ consenpr.htm
The author would like to acknowledge the contributions and challenging exchanges of those who reviewed this document, among them John Klensin, Dave Crocker, Pete Resnick, Spencer Dawkins, Scott Bradner, Joel Halpern, Avri Dora, Melinda Shore, Harald Alvestrand, Alex Simonelis, Keith Moore, Brian Carpenter, and Alex Rousskov.
著者は、ジョン・クレンシン、デイブ・クロッカー、ピート・レズニック、スペンサードーキンススコット・ブラッドナー、ジョエル・ハルパーン、Avriドラ、メリンダ・ショア、ハラルドAlvestrand、アレックスSimonelisその中で、この文書をレビューする人の貢献と挑戦的な交流を承認したいと思いますキース・ムーア、ブライアン・カーペンター、そしてアレックスRousskov。
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A.
テッドハーディークアルコム社675キャンベル・テクノロジー・パークウェイスイート200キャンベル、CA U.S.A.
EMail: hardie@qualcomm.com
メールアドレス：hardie@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。