[要約] 要約：RFC 3929は、IETFにおけるコンセンサスがブロックされた意思決定に対する代替の意思決定プロセスを提案しています。 目的：このRFCの目的は、IETFの意思決定プロセスにおいてコンセンサスが達成できない場合に、効果的な代替手段を提供することです。
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
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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のDave Clarkの非常に引用されたCredoは、「大まかなコンセンサスと実行コード」を、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 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内のワーキンググループは、相互運用可能なメカニズムまたは一連の標準が一部の領域で利用できるようにするために行わなければならない技術的決定についてコンセンサスに達することができません。これらのほとんどの場合、ほぼ同じレベルの技術的成熟、展開、および仕様で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.
これは、ワーキンググループの最良の選択が参加者の将来の使用の見解に依存することを意味するため、特にそれぞれがわずかに異なるユースケースに対して最適化されている場合、特にそれぞれが最適化されている場合、提案の中から選択することは困難です。さまざまな提案が、実装、展開、またはさまざまなグループに使用するコストを割り当てると、さらなる問題が発生します。これは、自分のOXがgoされないようにするための通常の人間の反応であるためです。
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コミュニティに発行された最後の呼び出しは、そのようなメカニズムが使用されており、セット間のどの提案が選択されているかに注意する必要があります。これらの方法の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の通常の動作モードよりも優先されることはありません。
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].
コンセンサスプロセスの利点は、結果として生じる決定は、すべての当事者の利益を満たし、誰もがサポートできるという決定であるということです。欠点は、このような決定を開発することは、長期間にわたって多くの人々が関与する非常に遅いプロセスになる可能性があることです。また、障害の確率が比較的高い可能性があります。迅速な決定が必要な場合、コンセンサスアプローチが機能しない場合があります。コンセンサスルールプロセスも、変化に反対し、現状を維持したいものを支持する傾向があります。これらの人々はすべて、コンセンサスの妥協をサポートすることを拒否し、彼らは勝ちます（少なくとも彼らが変化を遅らせることができる限り）[紛争]。
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.
ガイドラインとして「大まかなコンセンサス」を使用すると、個人または小さな派ionsが一般的なサポートを持っている決定を簡単にブロックできないようにすることにより、コンセンサスプロセスの欠点の一部が制限されます。「実行中のコード」の試金石は、特定の提案に反対する声明が技術的に根拠があることを要求することにより、コンセンサスプロセスの欠点を制限することもできます。
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.
提案されたソリューションは、インターネットドラフトとして利用できる必要があり、議長がIETF仕様として公開される可能性があると考えるように、おそらくさらに改良されていると考えるように、十分に指定する必要があります。提案されたソリューションが十分に指定されていないことを椅子が示す場合、具体的な問題を特定する必要があり、これらの問題を解決するために提供される合理的な時間を提供する必要があります。提案されたソリューションの1つが「何もしない」場合、その効果の明示的なドラフトが利用可能でなければならないことに注意してください。ただし、グループが別の意思決定プロセスを呼び出すときに作成される場合があります。
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.
コンセンサス構築にはかなりの量の議論が必要であり、グループがコンセンサスに達する前に技術的な問題が必要な議論の量を示すための一般的なルールはありません。議論が十分であるかどうかについて質問がある場合、ワーキンググループの椅子は、議論を継続することを許可する側で常に誤りする必要があります。別の意思決定プロセスを使用する前に、ワーキンググループチェアは、技術的な問題と選択を要約し、コンセンサスを明示的に呼びかける必要があります。コンセンサスの呼びかけ中に新しい技術的なポイントが作成された場合、議論は継続する必要があります。新しいポイントが提起されていないが、グループがコンセンサスに到達できない場合、ワーキンググループは別の意思決定プロセスの使用を検討することができます。いかなる状況においても、別の意思決定プロセスを使用するために必要なワーキンググループはありません。
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では、議長は技術的な問題に関するコンセンサスを明示的に呼びかけ、その呼び出しが前進しなかった後にのみ進むべきであることに注意してください。ワーキンググループメンバーによるコメントのために、代替の意思決定方法を使用するかどうかについての別の最後の呼び出しが必要です。これは、代替方法を使用する決定が、標準のトラックでドキュメントを進める決定と同じくらい真剣に受け取るべきであることを示すためです。また、これが参加者が自分の立場を再考する最後の瞬間であるという明確なシグナルを提供します。別の意思決定プロセスを使用するという決定には、議長によって決定されるように、ワーキンググループの大まかなコンセンサスが必要です。使用するプロセスの選択は、最後の呼び出しで行われるか、ワーキンググループ内の個別の議論の対象となる可能性があります。グループが代替方法が必要であるが、使用する方法に関するコンセンサスに至らないというコンセンサスに到達した場合、外部レビューチーム（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人以上のボランティアが必要な場合は、[RFC3797]で概説されているプロセスに従って5人が選択されます。ここでは、NOMCOMに関しては、提携に関する同じ規則がここで適用され、1つの組織の負担を軽減し、レビューチームの「梱包」の意味を削除することに注意してください。
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か月に割り当てられます。チームのメンバーは、関連するワーキンググループチェアに拡張機能が必要になることを通知することにより、この割り当てを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の議論をすることができますが、グループの審議はアーカイブリストに載っている必要があります。
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に送信されます。
The decision statements will be tallied according to "instant-runoff voting" rules, also known as "preference voting" rules [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.
このメカニズムにより、ワーキンググループは、ワーキンググループの外の人々とワーキンググループ内のプロセスに関与しているレビューチームを指定することができます。各提案の単一の代表者を持つことは結果にヌル効果があるように見えるかもしれませんが、意思決定処理の規則のためにバイナリ選択がある場合を除き、これはありそうにありません（C.F. 4.1.4。）。4.1のように、ワーキンググループはIETFコミュニティに、IETF-Announceメーリングリストで公開されることにより、混合レビューチームを形成するつもりであることを通知します。その発表には、決定される問題の概要と、代替提案を含むインターネットドラフトのリストが含まれている必要があります。また、外部レビューチームの審議のためのアーカイブされたメーリングリストの名前と場所も含める必要があります。
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あたり5人の外部メンバーが選択されます。その上。6番目は、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か月割り当てられており、チームのメンバーは、レビューチームの椅子に通知することにより、2週間でその割り当てを延長することができます。
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アナウンセのメーリングリストで公開された公表を行うことにより、別の決定メカニズムを使用することを計画していることを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.
この方法では、決定を下すために単一のワーキンググループ参加者が選択されます。ワーキンググループの最後のコールの12か月前にワーキンググループに貢献した個人（C.F. 3.3、上）は、意思決定者を務めるためにボランティアをすることができます。個人は、ワーキンググループメーリングリストで公式声明を発表し、ワーキンググループが検討中のインターネットドラフトの著者として務めること、またはワーキンググループの公開会議で議論のあるコメントをすることにより、参加者としての資格を得ることができます。椅子はボランティアではないかもしれません。資格のある各ボランティアは、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] Eastlake、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] Galvin、J.、ed。「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] Mitton、D.、Stjohns、M.、Barkley、S.、Nelson、D.、Patil、B.、Stevens、M。、およびB. Wolff、「認証、認可、会計：プロトコル評価」、RFC 3127、2001年6月。
[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
[紛争]扱いにくい紛争に関する国際オンライントレーニングプログラム、「コンセンサスルールプロセス」、紛争研究コンソーシアム、米国コロラド大学。http://www.colorado.edu/conflict/pece/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.
著者は、ジョン・クレンシン、デイブ・クロッカー、ピート・レストニック、スペンサー・ドーキンス、スコット・ブラッドナー、ジョエル・ハルパーン、アヴリ・ドラ、メリンダ・ショア、ハラルド・アルベストランド、アレックス・シモネリスなど、この文書をレビューした人々の貢献とやりがいのある交換を認めたいと思います。キース・ムーア、ブライアン・カーペンター、アレックス・ルウスコフ。
Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A.
Ted Hardie Qualcomm、Inc。675 Campbell Technology Parkway Suite 200 Campbell、CA U.S.A.
EMail: hardie@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。