I wrote various things about rough consensus and the implementors and "those
with implementations" in reaction to draft-resnick-on-consensus-06.
After discussion and more thought, I wanted to retract what I said, and offer
some specific comments on the draft.
Retraction:
"Running code" means it's the implementations (not necessarily the
implementors) that should carry the weight. Yes, for protocols to be
implemented the implementors (eventually) have to agree, because otherwise the
protocol doesn't get implemented. But "running code" is really the code, and
not just the opinion of those who might write the code.
To those who agreed with me:
Decisions should be based on technical arguments (including deployment
considerations): "I implement X and I say Y" is not a technical argument, even
if the speaker is the author of a popular implementation.
Managers of implementors, product managers who specify future implementations,
consultants who advise implementors, those who install or deploy
implementations, academics who have analyzed implementations, ... those are
all roles that can represent implementations credibly.
In the end, my main complaint about draft-resnick-on-consensus is about the
introduction (and abstract), as the draft seems at times to redefine "rough
consensus" even as it says it doesn't.
I offer Pete some specific edits as well as some comments. Some of the edits
are minor editorial. The edits are offered just as examples, I've tried to
include a rationale for each. Some things I don't know how to fix yet.
=== OLD ===
... (current section 1 Introduction) ...
=== NEW ===
1. Introduction
[BCP 9] [BCP 11] and [BCP 25] ("The Internet Standards Process", "The
Organizations Involved in the IETF Standards Process" and
"Implementation Report Guidance", "IETF Working Group Guidelines and
Procedures") describe the overall standards process in the IETF.
[TAO] discusses some of the traditional operational procedures used in
IETF, including:
Sometimes consensus is determined by "humming" -- if you agree with
a proposal, you hum when prompted by the chair. Most "hum"
questions come in two parts: you hum to the first part if you
agree with the proposal, or you hum to the second part if you
disagree with the proposal. Newcomers find it quite peculiar, but
it works. It is up to the chair to decide when the Working Group
has reached rough consensus.
Others have also written about ways to achieve (rough) consensus in
IETF and other organizations, (e.g.,
http://www.w3.org/2005/10/Process-20051014/policies.html#Consensus,
http://www.w3.org/Guide/chair-roles, [dussealt]
http://tools.ietf.org/html/draft-dusseault-consensus-00 )
Unfortunately, it seems recently that more and more of our actions are
now indistinguishable from voting, and quite often we are letting the
majority win the day without consideration of minority concerns. This
document is a collection of thoughts how to get back to the core
values of the organization.
This document is quite consciously being put forward as Informational.
It does not propose to change any IETF processes and is therefore not
a BCP. It is simply a collection of principles, hopefully around which
the IETF can come to (at least rough) consensus.
2. Humming
As [TAO] notes:
One of the "founding beliefs" [of the IETF] is embodied in an early
quote about the IETF from David Clark: "We reject kings, presidents
and voting. We believe in rough consensus and running code".
That is, our credo is that we don't let a single individual dictate
decisions (kings and presidents), nor should decisions be made by a
simple vote of the majority, nor do we want decisions to be made in a
vacuum without practical experience. Instead, we strive to make our
decisions by the consent of all participants, though allowing for some
dissent (rough consensus), and to have the actual products of
engineering trump theoretical designs (running code).
==== END NEW ===
Why: It should be clear that this document doesn't override
existing BCPs, and that 'rough consensus' is already defined.
I like giving explicit reference to where it *is* defined, as well
as other guidelines and discussions of consensus.
I think the fact that this isn't a BCP should be in the document,
not just a note.
In many ways this is part of the "TAO for the Experienced",
since TAO claims to be for novices.
I don't think the document is harmed by removing the
definition of "rough consensus" and just pointing to where
it is already elaborated.
===== OLD =====
When, for example, the chair of the working group wants
to get a "sense of the room" during a face-to-face meeting, instead
of a show of hands, sometimes the chair will ask for each side to hum
for or against a question.
===== NEW ====
For example, when the chair of a working group wants
to get a "sense of the room" during a face-to-face meeting, instead
of a show of hands, the chair might ask for each side to hum
for or against a question.
===== END NEW =====
Why: just editorial. "when the chair" is part of the example.
==== OLD ===
This document attempts to explain some features of rough consensus,
explain what is not rough consensus, discuss some new ways to think
about rough consensus, and suggest ways that we might achieve rough
consensus and judge it in the IETF.
=== NEW ===
This document gives some additional thoughts on the meaning of
rough consensus, notes some situations where rough consensus hasn't
been reached, discusses some new ways to think about rough consensus,
and suggests ways that we might better achieve rough consensus
and judge it in the IETF.
=== END NEW ===
Why: editorial; "explaining" sounds more like "redefining".
=== OLD ==
These sorts of "capitulation" or "horse-trading" compromises have no
place in consensus decision making.
=== END OLD ==
comment: I don't know exactly how to fix this, but "log rolling" (
http://en.wikipedia.org/wiki/Logrolling ) is common in all standards
organizations, and is a common failure mode of standards groups
that vote ("A camel is a horse designed by a committee.") I think this
might need a whole other essay of why rough consensus is better
than voting.
=== OLD ===
It is important to recognize that this view of rough consensus is a
change from the way it has been traditionally characterized in the
IETF.
=== NEW ==
This view of rough consensus differs from how recently
it is often characterized in the IETF.
=== END NEW ===
Why: not redefining rough consensus but countering recent trends.
=== OLD ===
Any finding of rough consensus needs, at some level, to provide a
reasoned explanation to the person(s) raising the issue of why their
concern is not going to be accommodated.
=== NEW ===
Any finding of rough consensus needs, at some level, to provide,
for each technical objection raised, a reasoned explanation why the
concern is not going to be accommodated.
=== END NEW ===
Why: the explanation needs consensus too.
=== OLD ===
Remember, if the objector feels that the issue is so essential that
it must be attended to, they always have the option to file an
appeal.
=== END OLD ===
comment: I don't know how to fix this. Asking someone to file an appeal is a
cop-out. Technical objections need responses that have rough consensus
as well, that the response is adequate. You get this right later on,
but "they always have the option to file an appeal" may be true,
but more often lately "they always have the option to walk away saying
'the IETF is broken'.
=== OLD ===
4. Humming should be the start of a conversation, not the end
=== NEW ===
4. Humming is only one way of helping a group come to real consensus.
=== END NEW ===
Why: humming is neither the start nor the end.
=== OLD ===
... We've also decided that coming to
consensus (albeit sometimes rough consensus) is an important thing to
do.
=== NEW ==
The IETF's success in designing protocols that are effective, with
secure, efficient, reliable, interoperable implementations widely
deployed has rested on the reliance on rough consensus of the
entire community.
=== END NEW ==
Why: Editorial: I wanted to emphasize that "rough consensus" is
a crucial factor in the success of the IETF protocol.