< draft-hardie-alt-consensus-01.txt		draft-hardie-alt-consensus-02.txt >
	Network Working Group T. Hardie		Network Working Group T. Hardie
	Internet-Draft Qualcomm, Inc.		Internet-Draft Qualcomm, Inc.
	Category: Experimental April 2004		Category: Experimental April 2004
	Alternative Decision Making Processes		Alternative Decision Making Processes
	for Consensus-blocked Decisions in the IETF		for Consensus-blocked Decisions in the IETF
	draft-hardie-alt-consensus-01.txt		draft-hardie-alt-consensus-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance		and any of which I become aware will be disclosed, in accordance
	with RFC 3668.		with RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at line 46 ¶		skipping to change at line 46 ¶
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document proposes an experimental set of alternative		This document proposes an experimental set of alternative
	decision-making processes for use in IETF working groups. There		decision-making processes for use in IETF working groups. There
	are a small number of cases in IETF working groups in which the		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		group has come to consensus that a particular decision must be made
	but cannot come to consensus on the decision itself. This document		but cannot come to consensus on the decision itself. This document
	describes alternative mechanisms which can be used to come to a		describes alternative mechanisms which can be used to come to a
	decision in those cases.		decision in those cases. This is not meant to provide an exhaustive
			list, but to provide a known set of tools which can be used when
			required.
	1. Introduction.		1. Introduction.
	Dave Clark's much-quoted credo for the IETF cites "rough consensus		Dave Clark's much-quoted credo for the IETF cites "rough consensus
	and running code" as the key criteria for decision making in the		and running code" as the key criteria for decision making in the
	IETF. Aside from a pleasing alliteration, these two touchstones		IETF. Aside from a pleasing alliteration, these two touchstones
	provide a concise summary of the ideals which guide the IETF's		provide a concise summary of the ideals which guide the IETF's
	decision making. The first implies an open process in which any		decision making. The first implies an open process in which any
	technical opinion will be heard and any participant's concerns		technical opinion will be heard and any participant's concerns
	addressed; the second implies a recognition that any decision must		addressed; the second implies a recognition that any decision must
	skipping to change at line 68 ¶		skipping to change at line 70 ¶
	the network and its uses. The aim of the IETF is to make the best		the network and its uses. The aim of the IETF is to make the best
	possible engineering choices and protocol standards for the		possible engineering choices and protocol standards for the
	Internet as a whole, and these two statements guide it in making		Internet as a whole, and these two statements guide it in making
	its choices and standards.		its choices and standards.
	In a small number of cases, working groups within the IETF cannot		In a small number of cases, working groups within the IETF cannot
	reach consensus on a technical decision which must be made in order		reach consensus on a technical decision which must be made in order
	to ensure that an interoperable mechanism or set of standards is		to ensure that an interoperable mechanism or set of standards is
	available in some sphere. In most of these cases, there are two or		available in some sphere. In most of these cases, there are two or
	more competing proposals at approximately the same level of		more competing proposals at approximately the same level of
	technical maturity, deployment, and specification. Choosing among		technical maturity, deployment, and specification. In some cases,
			working groups can achieve consensus to advance multiple proposals
			and to either revisit the question when experienced has been gained 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
	these proposals can be especially difficult when each is optimized		these proposals can be especially difficult when each is optimized
	for slightly different use cases, as this implies that the working		for slightly different use cases, as this implies that the working
	group's best choice depends on the participants' views of likely		group's best choice depends on the participants' views of likely
	future use. Further problems arise when different proposals assign		future use. Further problems arise when different proposals assign
	costs in implementation, deployment, or use to different groups, as		costs in implementation, deployment, or use to different groups, as
	it is a normal human reaction to seek to prevent one's own ox		it is a normal human reaction to seek to prevent one's own ox
	beingored.		being gored.
	This document puts forward a set of experimental mechanisms which		This document puts forward a set of experimental mechanisms which
	for use in that small number of cases. In order to gauge the		for use in that small number of cases. In order to gauge the
	results of those cases where one of these mechanisms is used, it is		results of those cases where one of these mechanisms is used, it is
	suggested that the Last Call issued to the IETF community note that		suggested that the Last Call issued to the IETF community note that
	such a mechanism was used and which one of the set was chosen. If		such a mechanism was used and which one of the set was chosen. If
	and when the community becomes satisfied that one or more of these		and when the community becomes satisfied that one or more of these
	methods is useful, it should be documented in a BCP for that small		methods is useful, it should be documented in a BCP for that small
	number of cases.		number of cases.
	skipping to change at line 150 ¶		skipping to change at line 157 ¶
	guideline for determining that these conditions have been met is		guideline for determining that these conditions have been met is
	included below.		included below.
	3.1 There is a clear decision to be reached.		3.1 There is a clear decision to be reached.
	There must be a clear statement of the 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		This may be in the working group's charter, in requirements
	documents, or in other documents developed by the working group.		documents, or in other documents developed by the working group.
	Prior to any invocation of an alternate decision making process,		Prior to any invocation of an alternate decision making process,
	the Chair(s) should confirm with the working group that there is		the Chair(s) should confirm with the working group that there is
	general agreement on the decision to be reached.		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.
	3.2 Proposals are available in draft form.		3.2 Proposals are available in draft form.
	Proposed solutions must be available as Internet drafts and must be		Proposed solutions must be available as Internet drafts and must be
	sufficiently specified to cause the Chair(s) to believe that they		sufficiently specified to cause the Chair(s) to believe that they
	could be, possibly with further refinement, published as an IETF		could be, possibly with further refinement, published as an IETF
	specification. If the Chair indicates to those proposing a		specification. If the Chair indicates to those proposing a
	solution that it is insufficiently specified, concrete problems to		solution that it is insufficiently specified, concrete problems to
	be resolved must be identified and a reasonable amount of time		be resolved must be identified and a reasonable amount of time
	provided to resolve those problems. Note that if one of the		provided to resolve those problems. Note that if one of the
	skipping to change at line 191 ¶		skipping to change at line 201 ¶
	use an alternate decision making process.		use an alternate decision making process.
	3.4 There is an explicit working group last call to use an alternate		3.4 There is an explicit working group last call to use an alternate
	method.		method.
	In item 3.3 above, it is noted that the Chair(s) should make an		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		explicit call for consensus on the technical issues and should
	proceed only after that call has yielded no forward progress. A		proceed only after that call has yielded no forward progress. A
	different last call on the question of whether to use an alternate		different last call on the question of whether to use an alternate
	decision making method is required, with a stated period for		decision making method is required, with a stated period for
	comments by working group members. This is both to indicate that		comments by working group members. This is to indicate that
	the decision to use an alternate method should be taken at least as		the decision to use an alternate method should be taken at least as
	seriously as the decision to advance a document on the standards		seriously as the decision to advance a document on the standards
	track and to provide a clear signal that this is a last moment for		track. It also provides a clear signal that this is a last moment for
	participants to reconsider their positions. The decision to use an		participants to reconsider their positions. The decision to use an
	alternate decision requires the rough consensus of the working		alternate decision making process requires the rough consensus of
	group, as determined by the Chair(s). The choice of which		the working group, as determined by the Chair(s). The choice of which
	alternate decision to use may be made in the last call or may the		alternate decision to use may be made in the last call or may be the
	subject of separate discussions within the working group. If the		subject of separate discussions within the working group. If the
	group comes to consensus that an alternative method is required but		group comes to consensus that an alternative method is required but
	does not come to consensus on the method to use, an external review		does not come to consensus on the method to use, an external review
	team (c.f. section 4.1, below) will be formed.		team (c.f. section 4.1, below) will be formed.
			In discussions of this draft, several points have been raised about
			the viability of any mechanism that requires consensus to use
			an alternative to consensus-based decision making. Some of those
			concerns pointed out that groups having trouble achieving consensus
			on the technical matter may have similar problems achieving
			consensus on the procedural matter. Others have been concerned
			that this will be used as an attempt to end-run rough consensus.
			These are all valid concerns, and they point both to the need
			to retain rough consensus as the baseline mechanism and 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 see the need for
			compromise in a new way, to back away from entrenched technical
			positions by putting the technical choice in the hands of the
			broader community, and to highlight that the choice for each
			participant is now between achieving *a* decision and failure.
			There is a fundamental tension between the IETF community's
			desire to get the best decision for a particular technical
			problem and the IETF community's 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 which might
			otherwise end in deadlock or stagnation.
	4. Alternate methods.		4. Alternate methods.
	In setting up an alternate method, care must be given that the		In setting up an alternate method, care must be given that the
	process by which the decision is reached remains open and remains		process by which the decision is reached remains open and remains
	focused on making the best technical choice for the Internet as a		focused on making the best technical choice for the Internet as a
	whole. The steps set out below provide a straw proposal for four		whole. The steps set out below provide a straw proposal for four
	such mechanisms. These are relatively heavy weight systems,		such mechanisms. These are relatively heavy weight systems,
	partially to highlight the gravity of choosing to invoke these		partially to highlight the gravity of choosing to invoke these
	methods and partially to ensure that the IETF community as a whole		methods and partially to ensure that the IETF community as a whole
	is alerted to and kept informed of the process. Note that		is alerted to and kept informed of the process. Note that
	skipping to change at line 235 ¶		skipping to change at line 270 ¶
	form an external review team by making a public announcement on the		form an external review team by making a public announcement on the
	IETF-announce mailing list. That announcement should include a		IETF-announce mailing list. That announcement should include a
	summary of the issue to be decided and a list of the		summary of the issue to be decided and a list of the
	internet-drafts which contain the alternate proposals. It should		internet-drafts which contain the alternate proposals. It should
	also include the name and location of an archived mailing list for		also include the name and location of an archived mailing list for
	the external review team's deliberations.		the external review team's deliberations.
	4.1.1 External review team membership.		4.1.1 External review team membership.
	External review teams have five members who must meet the same		External review teams have five members who must meet the same
	eligibility requirements as those for a voting member of the		eligibility requirements as those set out a voting member of the
	NomCom. Explicitly excluded from membership in review teams are		NomCom (2727bis). Explicitly excluded from participation in
	all those who have contributed to the relevant working group		external review teams are all those who have contributed
	mailing list within the previous 12 months, the IESG, the IAB, and		to the relevant working group mailing list within the previous 12
	the sitting NomCom. Volunteers to serve on the review team send		months, the IESG, the IAB, and the sitting NomCom.
	their names to the IETF executive director. Should more than five
	volunteer, five are selected according to the process outlined in		Volunteers to serve on the review team send their names to the
	RFC2777(RFC2777). Participants in the working group may actively		IETF executive director. Should more than five volunteer, five
	solicit others to volunteer to serve on the review team but, as		are selected according to the process outlined in RFC2777(RFC2777)
	noted above, they may not serve themselves if they have commented		note that the same rules on affiliation apply here as to the NomCom,
	on the list within the previous 12 months.		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 12 months.
	4.1.2 External review team deliberation.		4.1.2 External review team deliberation.
	The external review team is alloted one month for deliberations and		The external review team is alloted one month for deliberations and
	any member of the team may extend that allotment by two weeks by		any member of the team may extend that allotment by two weeks by
	notifying the relevant working group Chair(s) that the extension		notifying the relevant working group Chair(s) that the extension
	will be required.		will be required.
	The team commits to reading the summary provided during the IETF		The team commits to reading the summary provided during the IETF
	announcement and all of the relevant Internet drafts. Members may		announcement and all of the relevant Internet drafts. Members may
	skipping to change at line 403 ¶		skipping to change at line 444 ¶
	Section 4.3 may require the IANA to make random selections among a		Section 4.3 may require the IANA to make random selections among a
	known set of alternates.		known set of alternates.
	8. Normative References		8. Normative References
	Eastlake, Donald 3rd. "Publicly Verifiable Nomcom Random Selection",		Eastlake, Donald 3rd. "Publicly Verifiable Nomcom Random Selection",
	RFC2777.		RFC2777.
	(RFC2727)		(RFC2727)
			J. Galvin, Ed. "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees".
			draft-ietf-nomcom-rfc2727bis-09.txt (2727bis).
	9. Non-Normative References		9. Non-Normative References
	Mitton, D. et al. "Authentication, Authorization, and Accounting:		Mitton, D. et al. "Authentication, Authorization, and Accounting:
	Protocol Evaluation", RFC3127. (RFC3127)		Protocol Evaluation", RFC3127. (RFC3127)
	Center for Democracy and Voting. "Frequently Asked Questions about		Center for Democracy and Voting. "Frequently Asked Questions about
	IRV", http://www.fairvote.org/irv/faq.htm . (VOTE)		IRV", http://www.fairvote.org/irv/faq.htm . (VOTE)
	International Online Training Program on Intractable		International Online Training Program on Intractable
	Conflict,"Consensus Rule Processes",		Conflict,"Consensus Rule Processes",
	Conflict Research Consortium, University of Colorado, USA.		Conflict Research Consortium, University of Colorado, USA.
	http://www.colorado.edu/conflict/peace/treatment/consenpr.htm		http://www.colorado.edu/conflict/peace/treatment/consenpr.htm
	(CONFLICT)		(CONFLICT)
	10. Author's Address		10. Acknowledgements
			The author would like to acknowledge the contributions and
			challenging exchanges of reviewers of this draft, 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		Ted Hardie
	Qualcomm, Inc.		Qualcomm, Inc.
	675 Campbell Technology Parkway		675 Campbell Technology Parkway
	Suite 200		Suite 200
	Campbell, CA U.S.A.		Campbell, CA U.S.A.
	EMail: hardie@qualcomm.com		EMail: hardie@qualcomm.com
	Full Copyright Statement		Full Copyright Statement
End of changes. 12 change blocks.
	22 lines changed or deleted		75 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/