summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3929.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3929.txt')
-rw-r--r--doc/rfc/rfc3929.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3929.txt b/doc/rfc/rfc3929.txt
new file mode 100644
index 0000000..688d46a
--- /dev/null
+++ b/doc/rfc/rfc3929.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group T. Hardie
+Request for Comments: 3929 Qualcomm, Inc.
+Category: Experimental October 2004
+
+
+ Alternative Decision Making Processes
+ for Consensus-Blocked Decisions in the IETF
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (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.
+
+1. Introduction
+
+ 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.
+
+ 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
+
+
+
+Hardie Experimental [Page 1]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+ 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.
+
+ 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.
+
+2. Rough Consensus as a baseline approach
+
+ 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].
+
+
+
+
+
+
+
+Hardie Experimental [Page 2]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+ 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.
+
+ 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.
+
+3. Conditions for use
+
+ 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
+
+ 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
+
+
+3.2. Proposals are available in Draft form
+
+ 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.
+
+3.3. The working group has discussed the issue without reaching
+ resolution
+
+ 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
+
+ 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
+
+
+
+
+Hardie Experimental [Page 4]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+ 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.
+
+ 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.
+
+
+4. Alternate Methods
+
+ 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.
+
+
+
+
+
+
+Hardie Experimental [Page 5]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+4.1. Alternate Method One: External Review Team Formation
+
+ 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.
+
+4.1.1. External Review Team Membership
+
+ 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.
+
+ 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.
+
+ 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.
+
+4.1.2. External Review Team Deliberation
+
+ 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.
+
+
+
+Hardie Experimental [Page 6]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+4.1.3. Decision Statements
+
+ 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.
+
+4.1.4. Decision Statement Processing
+
+ The decision statements will be tallied according to "instant-runoff
+ voting" rules, also known as "preference voting" rules [VOTE].
+
+4.2. Alternate Method Two: Mixed Review Team
+
+ This mechanism allows the working group to designate a review team
+ that involves those outside the working group and those who have been
+ involved in the process within the working group. Although it may
+ appear that having a single representative of each proposal will have
+ a null effect on the outcome, this is unlikely, except when there is
+ a binary choice, because of the rules for decision-statement
+ processing (c.f. 4.1.4.). As in 4.1, the working group notifies the
+ IETF community that it intends to form a mixed review team by making
+ a public announcement on the IETF-announce mailing list. That
+ announcement should include a summary of the issue to be decided and
+ a list of the Internet-Drafts containing the alternate proposals. It
+ should also include the name and location of an archived mailing list
+ for the external review team's deliberations.
+
+4.2.1. Mixed Review Team Membership
+
+ 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.2.2. Mixed Review Team Deliberation
+
+ 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.
+
+
+
+
+
+Hardie Experimental [Page 7]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+ 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.
+
+4.2.3. Decision Statements
+
+ As in 4.1.3, above.
+
+4.2.4. Decision Statement Processing
+
+ As in 4.1.4, above.
+
+4.3. Alternate Method Three: Qualified Short-Straw Selection
+
+ 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.
+
+ 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.
+
+4.4. Alternate Method Four: Random Assignment
+
+ 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,
+
+
+
+Hardie Experimental [Page 8]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+ 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.
+
+5. Appeals
+
+ 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
+
+ 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.
+
+7. IANA Considerations
+
+ Section 4.3 may require the IANA to make random selections among a
+ known set of alternates.
+
+8. References
+
+8.1. Normative References
+
+ [RFC3797] Eastlake, D., "Publicly Verifiable Nomination Committee
+ (NomCom) Random Selection", RFC 3797, June 2004.
+
+ [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.
+
+8.2. Informative References
+
+ [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.
+
+
+
+Hardie Experimental [Page 9]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+ [VOTE] Center for Democracy and Voting. "Frequently Asked
+ Questions about 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
+
+10. Acknowledgements
+
+ 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.
+
+11. Author's Address
+
+ Ted Hardie
+ Qualcomm, Inc.
+ 675 Campbell Technology Parkway
+ Suite 200
+ Campbell, CA U.S.A.
+
+ EMail: hardie@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie Experimental [Page 10]
+
+RFC 3929 Consensus-Blocked Decisions in the IETF October 2004
+
+
+Full Copyright Statement
+
+ Copyright (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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Hardie Experimental [Page 11]
+