From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3929.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc3929.txt (limited to 'doc/rfc/rfc3929.txt') 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] + -- cgit v1.2.3