Network Working Group T. Hardie
Request for Comments: 3929 Qualcomm, Inc.
Category: Experimental October 2004
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）互联网协会（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.
Dave Clark被大量引用的IETF信条将“大致共识和运行代码”描述为IETF决策的关键标准。除了令人愉悦的头韵外，这两块试金石还简要概括了指导IETF决策的理想。第一种方法意味着一个公开的过程，在此过程中，将听取任何技术意见，并解决任何参与者的问题；第二点意味着认识到，任何决策都必须建立在坚实的工程和网络及其用途的已知特征的基础上。IETF的目标是为整个互联网做出最佳的工程选择和协议标准，这两个原则指导IETF做出选择和标准。
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内的工作组无法就必须作出的技术决定达成共识，以确保实现互操作机制或标准集
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.
在某些领域可用。在大多数情况下，在技术成熟度、部署和规范水平大致相同的情况下，存在两个或多个相互竞争的方案。在某些情况下，工作组可以达成共识，提出多项提案，或者根据经验重新审议这个问题，或者建立必要的机制，在议定书的整个生命周期内处理多种选择。然而，在其他情况下，工作组决定必须提出一项提案。
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.
本文件提出了一套用于此类情况的实验机制。为了评估使用这些机制的结果，向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].
协商一致进程的优势在于，由此产生的决定符合各方的利益，并且每个人都可以支持。缺点是制定这样一个决策可能是一个非常缓慢的过程，需要很多人长期参与。也有相对较高的失效概率。如果需要迅速作出决定，协商一致的办法可能行不通。共识规则过程也倾向于支持那些反对变革并希望保持现状的人。这些人所要做的就是拒绝支持任何协商一致的妥协，他们将赢得（至少只要他们能够推迟改变）[冲突]。
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.
建议的解决方案必须作为互联网草案提供，并且必须充分指定，以便主席相信它们可以作为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
在上文项目3.3中，注意到主席应明确呼吁就技术问题达成协商一致意见，并应在该呼吁没有取得任何进展后才进行。需要就是否使用替代决策方法进行不同的最后呼吁，并规定一段时间供工作组成员发表意见。这表明使用替代方法的决定应至少与在标准轨道上推进文件的决定一样认真对待。它还提供了一个明确的信号，即这是参与者重新考虑其立场的最后时刻。采用替代决策过程的决定需要主席确定的工作组的大致共识。可在最后一次通话中选择使用哪种程序，也可在工作组内单独讨论。如果团体来
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社区希望为特定的技术问题获得最佳决策的愿望与社区以粗略共识的形式接受决策的愿望之间存在着根本的紧张关系。这些机制无法解决这一根本紧张局势。然而，在某些情况下，它们可能会提供一条前进的道路，否则可能会导致僵局或停滞。
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.
在建立替代方法时，必须注意做出决定的过程保持开放性，并将重点放在整个互联网的最佳技术选择上。下面列出的步骤为四个这样的机制提供了一个初步建议。这些系统相对较重，部分是为了强调调用这些方法的重要性，部分是为了确保IETF社区作为一个整体对该过程保持警惕和了解。注意，过去曾使用过替代程序；请参阅[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社区，它打算通过在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]。在过去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执行主任。如果超过五名志愿者，则根据[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.
外部审查小组有一个月的时间进行审议。团队的任何成员都可以通过通知相关工作组主席需要延期的方式，将此分配延长两周。
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.
外部审查小组的每个成员都写一份简短的决策声明，仅限一页。该决策声明包含按优先顺序排列的提案列表。它还可能包含审查小组成员对问题和建议解决方案的分析摘要，但这不是必需的。这些决策声明将发送至存档邮件列表、相关工作组主席和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公告邮件列表上发布公告来组建一个混合审查小组。该公告应包括待决定问题的摘要和包含备选提案的互联网草案清单。还应包括存档邮件列表的名称和位置，供外部审查小组审议。
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.
混合审查小组由每个提案的一名指定代表（通常是互联网草案的主要作者）和六名外部成员组成。根据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.
审查小组有一个月的时间进行审议，小组的任何成员都可以通过通知审查小组主席将需要延长的时间延长两周。
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.
在这种方法中，选择一个工作组参与者进行决策。在工作组最后一次就技术问题（上文c.f.3.3）提出要求之前的十二个月内为工作组做出贡献的任何个人均可自愿担任决策者。个人可以通过在工作组邮件列表上发表公开声明、担任工作组正在审议的互联网草案的作者或在工作组公开会议上发表记录在案的评论来获得与会者资格。主席不得自愿参加。每位合格志愿者在向IETF公告邮寄名单发送公告后三周内，将其姓名发送给工作组主席和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,
在少数情况下，协商一致不是一种适当的决策方法，其中甚至有少数情况的决策根本不涉及任何技术要点，而且需要在备选方案中随机选择。以IDN工作组为例，
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前缀。由于该决定涉及尽早获得稀缺资源，因此需要进行随机选择。在这种情况下，工作组可要求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 37972004年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
[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
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.
作者要感谢审阅本文件的人员的贡献和富有挑战性的交流，其中包括John Klensin、Dave Crocker、Pete Resnick、Spencer Dawkins、Scott Bradner、Joel Halpern、Avri Dora、Melinda Shore、Harald Alvestrand、Alex Simonelis、Keith Moore、Brian Carpenter和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，加利福尼亚州坎贝尔市。
EMail: hardie@qualcomm.com
EMail: 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。