Re: Last calling draft-resnick-on-consensus

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A small comment in-line.


On Thu, Oct 10, 2013 at 1:25 PM, Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
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.  

In addition to the two you cite, RFC 3929  does, primarily in Section 2 but also 3.3 and a few other places.  As the author of that Experimental RFC, I will note that I am not aware of any case in which any of its proposals has been carried out, though it has been discussed as a possibility more than once.  

The first thing most readers note is that using one of its methods does not get you out of building consensus--it requires you to build consensus for an alternate approach when consensus on a technical matter cannot be reached by the baseline process (and it is clear that it is not trying to change the baseline).

regards,

Ted

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]