RFC3929 日本語訳
3929 Alternative Decision Making Processes for Consensus-BlockedDecisions in the IETF. T. Hardie. October 2004. (Format: TXT=26493 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Hardie Request for Comments: 3929 Qualcomm, Inc. Category: Experimental October 2004
コメントを求めるワーキンググループT.ハーディー要求をネットワークでつないでください: 3929年のクアルコムInc.カテゴリ: 実験的な2004年10月
Alternative Decision Making Processes
for Consensus-Blocked Decisions in the IETF
IETFでのコンセンサスで妨げられた決定のための代替の意志決定の過程
Status of this Memo
この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).
Copyright(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ワーキンググループには少ない数のケースがあります。 このドキュメントは、それらの場合で決断を下すために代替のメカニズムについて説明します。 完全なりストを提供することが意味されるのではなく、これは、必要であると使用できる知られているセットのツールを提供するために意味されます。
1. Introduction
1. 序論
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の意志決定の主要な評価基準と説明します。 微笑ましい頭韻は別として、これらの2つの試金石がIETFの意志決定を誘導する典型の簡潔な概要を提供します。 1番目は、どんな技術的な意見も聞かれる開いている過程とどんな関係者の関心も記述したのを含意します。 2番目はネットワークとその用途のしっかりした工学と知られている特性にどんな決定も根拠がなければならないという認識を含意します。 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
少ない数の場合では、IETFの中のワーキンググループは共同利用できるメカニズムか1セットの規格がそうであることを確実にするためにしなければならない技術的判断のときに全員の意見が一致できません。
Hardie Experimental [Page 1] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[1ページ]RFC3929のコンセンサスで妨げられたDecisions
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.
何らかの球では、利用可能です。 これらの場合の大部分では、ほとんど同じレベルの技術的成熟度、展開、および仕様に基づく提案は、2であるかさらに競争しています。 いくつかの場合、ワーキンググループは経験で質問を再訪させるか、またはプロトコルの人生において複数のオプションを扱うために必要なメカニズムを造るために複数の提案とどちらかを進めるコンセンサスを達成できます。 しかしながら、他の場合では、ワーキンググループは、ただ一つの提案を進めなければならないと決めます。
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.
特にそれぞれによるわずかに異なった使用のために最適化されて、ケースでありこれが、ワーキンググループが最も良いのを含意するときこの選択が関係者の視点次第であるということであるときに、提案の中で選ぶのはありそうな今後の使用で難しい場合があります。 異なった提案が実現、展開、または使用でのコストを異なったグループに配属するとき、さらなる問題は起こります、自分自身の雄牛が突き刺されるのを防ごうとするのが、通常の人間の反応であるので。
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.
このドキュメントは使用のためにそのような場合1セットの実験メカニズムを提案します。 これらのメカニズムの使用の結果を測るために、IETF共同体に発行されたLast Callは、そのようなメカニズムがセットの中の使用されて、どの提案が選ばれたかということであることに注意するはずです。 共同体がなるなら、これらの方法の1つ以上が役に立つのが満たされて、それは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の操作の正規モードの上で決して、優先するはずがありません。
2. Rough Consensus as a baseline approach
2. 基線アプローチとしての荒いConsensus
The Conflict Research Consortium at the University of Colorado outlines the pros and cons of consensus as follows:
コロラド大学のConflict Research Consortiumは以下のコンセンサスの賛否両論について概説します:
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].
コンセンサスを得るためのプロセスの利点は結果として起こる決定が皆がすべてのパーティーの関心を満たして、支持できるものであるということです。 不都合はそのような決定を開発するのが、非常に遅い過程であるかもしれないということです、長日月の間、多くの人々にかかわって。 また、失敗の比較的高い確率があります。 素早い決定が必要であるなら、コンセンサスアプローチは働かないかもしれません。 また、コンセンサス規則の過程は変化に反対するものを支持して、現状を保存したい傾向があります。 これらの人々がしなければならないのが、どんなコンセンサス妥協も支持するのを拒否することであり、それらは勝つでしょう(延着できる限り、少なくとも、変化してください)[CONFLICT]。
Hardie Experimental [Page 2] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[2ページ]RFC3929のコンセンサスで妨げられたDecisions
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で十分です。 このドキュメントは、進歩を遂げるために普通のメカニズムを変えるのを示しません。 ワーキンググループに決定しなければなりませんが、普通の規則でその決定をすることができないというコンセンサスがあるとき、それは使用のためにメカニズムを提案します。
3. Conditions for use
3. 使用のための状態
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.
一般に、ワーキンググループは、選択をしなければならなくて、継続的な議論で選択はすることができないそれが明確であるときに過程を作っている補欠の両方決定、仕様の気品、および実現経験を使用すると考えるべきです。 これらの条件を満たしてあるかどうか決定するためのガイドラインは以下に含まれています。
3.1. There is a clear decision to be reached
3.1. 達するという明確な決定があります。
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.
達するという決定の明確な声明があるに違いありません。 これはワーキンググループの特許、要件ドキュメント、またはワーキンググループによって開発された他のドキュメントにあるかもしれません。 交互の意志決定の過程のどんな実施の前にも、議長は、ワーキンググループと共に達するという決定には一般協定があると確認するべきです。 これは、ワーキンググループが複数の提案を進めることができるかどうかに関して特定のコンセンサス呼び出しを含まなければならないべきであるか、または仕事項目のためにただ一つの提案を選択しなければなりません。
Hardie Experimental [Page 3] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[3ページ]RFC3929のコンセンサスで妨げられたDecisions
3.2. Proposals are available in Draft form
3.2. 提案はDraftフォームで利用可能です。
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.
議長は、提案された解決策をインターネット草稿として利用可能でなければならなく、十分指定しなければならないので、IETF仕様としてそれらを発行できたと信じています、ことによるとさらなる気品で。 議長が、提案された解決策が不十分に指定されるのを示すなら、具体的な問題を特定しなければなりません、そして、それらの問題を解決するために提供された十分な量の時間を提供しなければなりません。 明白なDraftが提案された解決策の1つが「何もしないでください」であるなら、その趣旨で利用可能でなければならないことに注意してください。 しかしながら、グループが交互の意志決定の過程を呼び出すとき、それは生産されるかもしれません。
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
上の項目3.3では、議長が専門的な問題に関するコンセンサスのための明白な電話をかけるべきであり、その呼び出しがどんな前進の進歩ももたらしていなかった後にだけ続くべきであると述べられます。 交互の意思決定法を使用するかどうかの異なったLast Callが必要です、ワーキンググループのメンバーによるコメントのために述べられた期間で。 これは、代替方法を使用するという決定が標準化過程の上でドキュメントを進めるという決定と少なくとも同じくらい真剣に受け止められるべきであるのを示すためのものです。 また、関係者が彼らの位置を再考するように、それはこれが最後の瞬間であるというはっきり聞こえる信号を提供します。 交互の意志決定の過程を使用するという決定はワーキンググループの荒いコンセンサスを必要とします、議長によって決定されるように。 選択は、どの過程を使用するかをLast Callで作られているかもしれないか、ワーキンググループの中の別々の議論の対象であるかもしれません。 グループが意識を取り戻すなら
Hardie Experimental [Page 4] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[4ページ]RFC3929のコンセンサスで妨げられたDecisions
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.
別法が必要ですが、使用する方法に関するコンセンサスに来ないというコンセンサス、外部レビューチーム(下の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共同体の願望と中で共同体買わせる決定を得るその願望の間には、荒いコンセンサスの形に基本的な緊張があります。 これらのメカニズムはその基本的な緊張を決議できません。 しかしながら、彼らはそうでなければ行き詰まりか停滞に終わるかもしれないいくつかの状況で道を前方に提供するかもしれません。
4. Alternate Methods
4. 代替方法
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共同体が全体で警告されて、維持されたのを保証するためにこれらの方法を部分的に呼び出す重力を目立たせるのは過程について知らせました。 代替手順が過去に使用されたことに注意してください。 Authentication、Authorization、およびAccountingに2つの競争している候補プロトコルの間の決定に使用されるその記述に関して[RFC3127]を見てください。 これらの提案を出すことによって、このドキュメントは、ワーキンググループ選択を制限しないつもりですが、多くの場合、再発明の必要性を取り除く1セットの明確な過程を提供するつもりです。
Hardie Experimental [Page 5] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[5ページ]RFC3929のコンセンサスで妨げられたDecisions
4.1. Alternate Method One: External Review Team Formation
4.1. 方法1を交替してください: 外部レビューチーム構成
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における公示にメーリングリストを示させることによって外部レビューチームを形成するつもりであるようにIETF共同体に通知します。 その発表は決められるべき問題の概要と交互の提案を含むインターネット草稿のリストを含むべきです。 また、それは外部レビューチームの熟考のための格納されたメーリングリストの名前と位置を含むべきです。
4.1.1. External Review Team Membership
4.1.1. 外部レビューチーム会員資格
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カ月以内にリストを批評したなら、上で述べたように、彼らは自分たちに役立たないかもしれません。
4.1.2. External Review Team Deliberation
4.1.2. 外部レビューチーム熟考
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カ月割り当てられます。 拡大が必要であるように関連ワーキンググループ議長(s)に通知することによって、チームのどんなメンバーもこの割当てを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発表で言及した格納されたメーリングリストで行われるべきです。 メールするか、チームメンバーがもちろん電話で関連個人と-1つについて1議論するかもしれません、自分で、グループ熟考しか格納されたリストにあるべきではありません。
Hardie Experimental [Page 6] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[6ページ]RFC3929のコンセンサスで妨げられたDecisions
4.1.3. Decision Statements
4.1.3. 決定声明
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ページに制限された短い決定声明を書きます。 その決定声明は好みの命令における提案のリストを含んでいます。 それは、また、レビューチームメンバーの問題の分析の概要を含んだかもしれなくて、解決策を提案しましたが、これは必要ではありません。 格納されたメーリングリスト、関連ワーキンググループいす、およびIESGにこれらの決定声明を送ります。
4.1.4. Decision Statement Processing
4.1.4. 決定声明処理
The decision statements will be tallied according to "instant-runoff voting" rules, also known as "preference voting" rules [VOTE].
また、「好みの票」が[VOTE]を統治するので知られていて、「即時の決勝戦票」に従って声明が記録されるという決定は統治されます。
4.2. Alternate Method Two: Mixed Review Team
4.2. 方法Twoを交替してください: 肯定否定両面のある批評チーム
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.
このメカニズムで、ワーキンググループはワーキンググループの中でワーキンググループの外のそれらと過程にかかわったものにかかわるレビューチームを指定できます。 それぞれの提案の独身の代表がいるとヌル影響が結果に与えられるように見えるかもしれませんが、これはありそうもないです、2進の選択がある時を除いて、決定声明処理のための規則のために(c. f。 4.1.4.). 4.1のように、ワーキンググループは、IETF発表しているメーリングリストに公示することによって肯定否定両面のある批評チームを形成するつもりであるようにIETF共同体に通知します。 その発表は決められるべき問題の概要と交互の提案を含むインターネット草稿のリストを含むべきです。 また、それは外部レビューチームの熟考のための格納されたメーリングリストの名前と位置を含むべきです。
4.2.1. Mixed Review Team Membership
4.2.1. 肯定否定両面のある批評チーム会員資格
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.
肯定否定両面のある批評チームはそれぞれの提案の1人の任命された代表者、通常インターネット草稿の共著の中心となる著者、および6人の外部のメンバーで構成されます。 5人の外部のメンバーが上で4.1単位で.1に選択されます。 6番目はグループの教授の職としてIESGによって指定されます。 いすの第一の役割が過程が従われているのを保証することですが、彼女か彼が、熟考を投票して、従事するかもしれません。
4.2.2. Mixed Review Team Deliberation
4.2.2. 肯定否定両面のある批評チーム熟考
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.
レビューチームは熟考のためにあるカ月割り当てられます、そして、チームのどんなメンバーもその割当てをレビューチーム議長に通知することによって必要である2週間広げるかもしれません。
Hardie Experimental [Page 7] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[7ページ]RFC3929のコンセンサスで妨げられたDecisions
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発表で言及した格納されたメーリングリストで行われるべきです。
4.2.3. Decision Statements
4.2.3. 決定声明
As in 4.1.3, above.
同じくらい中、4.1 .3 上。
4.2.4. Decision Statement Processing
4.2.4. 決定声明処理
As in 4.1.4, above.
同じくらい中、4.1 .4 上。
4.3. Alternate Method Three: Qualified Short-Straw Selection
4.3. 方法Threeを交替してください: 適切な脆いわらの選択
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発表しているメーリングリストに公示することによって交互の決定機構を使用するのを計画しているように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.
この方法で、独身のワーキンググループの関係者は決定をするのに選ばれます。 技術的な質問でワーキンググループLast Callの前の12カ月でワーキンググループに貢献したどんな個人(c. f。 3.3 上) 意思決定者として機能するのを買って出るかもしれません。 個人はワーキンググループメーリングリストで声明書を作ったことによって、関係者の資格を得るかもしれません、インターネット草稿のための作者としてワーキンググループ、またはワーキンググループの公開の会合における書き留められたコメントをすることによって考慮で勤めることによって。 議長は買って出ないかもしれません。 それぞれの適任のボランティアはIETF発表しているメーリングリストに送られた発表の3週間以内にワーキンググループいすとIETF専務の彼女か彼の名前をところに送ります。 そして、IETF専務はリストから独身のボランティアを選ぶために[RFC3797]で説明された選択手順を用います。 メールに関連ワーキンググループいす、働くメーリングリスト、およびIESGに選択された提案を含むとインターネット草稿を命名することによって、そのボランティアは黒白をつけます。
4.4. Alternate Method Four: Random Assignment
4.4. 方法Fourを交替してください: 無作為の課題
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,
どのコンセンサスが意志決定の適切な方法でないかケースの少ない数の中に、決定がテクニカルポイントを全く伴わないさらに少ない数とオプションの中で手当たりしだいに選択する必要があります。 例としてのIDNワーキンググループ
Hardie Experimental [Page 8] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[8ページ]RFC3929のコンセンサスで妨げられたDecisions
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.
特定のDNS接頭語を指定するのが必要でした。 決定が不十分なリソースへの早めのアクセスにかかわったとき、ランダム・セレクションが必要でした。 そのような場合、ワーキンググループは、1セットの明確に図で表わされた値から無作為の課題をするようにIANAに頼むかもしれません。 これでは、IANAは[RFC3797]によって選択手順で誘導されるでしょう。 特別事情、ワーキンググループがIESGの承認をもってインターネット草稿のプールの中でこのように選択するようにIANAに頼むかもしれない下。
5. Appeals
5. 上告
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.
代替方法を使用するワーキンググループのコンセンサスが専門的な問題に関するワーキンググループのコンセンサスの代役を務めるという明白な警告によるいかなる他のワーキンググループ決定とも同じ規則に従って、これらの工程でされた技術的判断は上告されるかもしれません。
6. Security Considerations
6. セキュリティ問題
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の中で意志決定の基礎を移行させるということです。 これらのメカニズムを提供する際に、コンセンサス規則の下で手に負えないかもしれないある決定にここに設定された規則の下で達していることが望まれています。 リスクはもちろん評価がこれらの規則の下で起こらせるとゲームへのシステムが個人に許容されるかもしれないということです。
7. IANA Considerations
7. IANA問題
Section 4.3 may require the IANA to make random selections among a known set of alternates.
セクション4.3は、IANAが知られているセットの補欠の中でランダム・セレクションをするのを必要とするかもしれません。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC3797] Eastlake, D., "Publicly Verifiable Nomination Committee
(NomCom) Random Selection", RFC 3797, June 2004.
[RFC3797] イーストレーク、D.、「公的に証明可能な指名委員会(NomCom)ランダム・セレクション」、RFC3797、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選択、確認、およびリコールは以下を処理します」。 「指名とリコール委員会の操作」、BCP10、RFC3777、2004年6月。
8.2. Informative References
8.2. 有益な参照
[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.ヴォルフ、「認証、認可、以下を説明すること」。 「プロトコル評価」、RFC3127、2001年6月。
Hardie Experimental [Page 9] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[9ページ]RFC3929のコンセンサスで妨げられたDecisions
[VOTE] Center for Democracy and Voting. "Frequently Asked
Questions about IRV", http://www.fairvote.org/irv/faq.htm.
[投票します] 民主主義と票のためのセンター。 「IRVに関するよく出る質問」、 http://www.fairvote.org/irv/faq.htm 。
[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
米国Intractable Conflictの上の[CONFLICT]国際Online企業向けインターネット利用訓練プログラム、「コンセンサスRule Processes」、Conflict Research Consortium、コロラド大学、 http://www.colorado.edu/conflict/peace/treatment/ consenpr.htm
10. Acknowledgements
10. 承認
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.
作者は貢献、このドキュメントを再検討した人のやりがいがある交換、それらの中でジョンKlensin、デーヴ・クロッカー、ピートレズニック、スペンサー・ダウキンズ、スコット・ブラドナー、ジョエル・アルペルン、Avriドラ、メリンダShore、ハラルドAlvestrand、アレックスSimonelis、キース・ムーア、ブライアンCarpenter、およびアレックスRousskovを承認したがっています。
11. Author's Address
11. 作者のアドレス
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A.
テッドハーディークアルコムInc.675キャンベル技術公園道路Suite200カリフォルニアキャンベル(米国)
EMail: hardie@qualcomm.com
メール: hardie@qualcomm.com
Hardie Experimental [Page 10] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
IETF2004年10月のハーディー実験的な[10ページ]RFC3929のコンセンサスで妨げられたDecisions
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hardie Experimental [Page 11]
ハーディーExperimentalです。[11ページ]
一覧
スポンサーリンク
