ietf
[Top] [All Lists]

Re: Last calling draft-resnick-on-consensus

2013-10-10 19:04:57
A small comment in-line.


On Thu, Oct 10, 2013 at 1:25 PM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> 
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