On 10/7/2013 10:03 AM, Jari Arkko wrote:
The abstract says:
The IETF has had a long tradition of doing its technical work
through a consensus process, taking into account the different views
among IETF participants and coming to (at least rough) consensus on
technical matters. In particular, the IETF is supposed not to be
run by a "majority rule" philosophy. This is why we engage in
rituals
As I noted in my review of the draft, the document has a core flaw in
its sense of history. It has invented an interpretation of "rough
consensus" that was not part of its original formulation.
I consider the current focus on reconciling minority views to be quite
an excellent enhancement to that original interpretation, but it really
is an addition. In classic IETF fashion, documenting that enhancement
flows from common -- though not universal -- IETF practice that has
emerged, and it likely to produce better consistency to the current, ad
hoc behavior. But we need to stop asserting the meaning of "rough
consensus" to have always or obviously included this.
Part of the confusion about the history is over-interpreting the context
the phrase was used. Dave Clark drew a contrast against 'voting'.
Voting is a mechanical counting process, with formal lines of
distinction, whether a simple model like 51% or 67%, or the like, or
something more complex. But it's based on a strict counting of votes
and a strict model for using them.
By contrast, the phrase "rough consensus" simply meant that there is
massive support, and leaves the determination of 'massive' to subjective
processes. If something has massive support, it is likely to get
implemented, deployed and used. If it doesn't, the formalities of a
voting mechanism won't help it succeed in the marketplace. The idea
that voting will suffice for this concern by simply moving the thresh
hold to some sort of super-majority imposes an artificial precision; the
idea behind rough consensus is the subject sense that there is obviously
'enough' support.
I believe the IETF has only two documents that talk about the meaning of
rough consensus. The first is Working Group Guidelines and Procedures
that was originally written by Erik Huizer and myself; Scott Bradner's
update to the document didn't change this part of it. And the relevant
text was something I wrote rather carefully, since the construct was new
and quite unusual for a standards group:
http://tools.ietf.org/html/rfc1603#section-3.2
3.3. Session management
Working groups make decisions through a "rough consensus" process.
IETF consensus does not require that all participants agree although
this is, of course, preferred. In general the dominant view of the
working group shall prevail. (However, it must be noted that
"dominance" is not to be determined on the basis of volume or
persistence, but rather a more general sense of agreement.) Consensus
can be determined by balloting, humming, or any other means on which
the WG agrees (by rough consensus, of course).
The other document is recent versions of the Tao of the IETF. It did not
originally discuss the issue but Sue Harris added discussion of
it in 2001, and the latest text on the Tao web page seems to have the
same text.[*]
http://tools.ietf.org/html/rfc3160
3.2 Getting Things Done in a Working Group
...
Another aspect of Working Groups that confounds many people is the
fact that there is no formal voting. The general rule on disputed
topics is that the Working Group has to come to "rough consensus,"
meaning that a very large majority of those who care must agree.
And the simple focus on a strongly dominant group preference was what
was presented in the original Working Group Chair training I initiated
also in the early 90s:
http://bbiw.net/presentations/ietf-stds-4.pdf
So, folks, please do press for Pete's document to move towards readiness
to be published. But let's not invent history and thereby fail to
understand the difference between 'clarifying' and 'enhancing'.
d/
[*] Small observation about the current fashion of moving things to web
pages rather than RFCs: We completely lose version tracking, and being
able to review the history of the document. While one might add a
mechanism to remedy this, note that we don't do that now.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net