[rpd] An review of consensus process.

[Lu Heng]

Dear colleagues:

In light of the recent appeal and policy discussion event, I would like to
kindly remind the community of the very fundamental of the
consensus process.

So what is “consensus”?

In RFC7282, consensus is defined as follows:

*"Having full consensus, or unanimity, would be ideal, but we don't require
it: Requiring full consensus allows a single intransigent person who simply
keeps saying "No!" to stop the process cold.  We only require rough
consensus: If the chair of a working group determines that a technical
issue brought forward by an objector has been truly considered by the
working group, and the working group has made an informed decision that the
objection has been answered or is not enough of a technical problem to
prevent moving forward, the chair can declare that there is rough consensus
to go forward, the objection notwithstanding."*

It might not be very clear, which is the case for most other discussions in
the AFRINIC policy list. There is not much about the technical issue, so I
think it is fair to follow the definition stated on Wikipedia:

According to Wikipedia,

*"Consensus decision-making is a group decision-making process in which
group members develop, and agree to support a decision in the best interest
of the whole. Consensus may be defined professionally as an acceptable
resolution, one that can be supported, even if not the "favorite" of each
individual."*

In both definitions, *consensus refers to "an acceptable resolution" to all
parties *to a problem of any kind, political or technical.

PDP process also requires chairs to consider the comments from the mailing
list before declaring consensus.

Let's take the example of "Internet Number Resources review by AFRINIC":

The supporters of this policy believe that Internet resource is a public
resource. Thus, if one no longer uses it, they have to return it back to
AFRINIC for re-distribution.

On the contrary, people who oppose to this policy think that since internet
resource’s usage right is not a public resource, re-distribution should be
done through a free market economy rather than center-planning
redistribution hub.

Another example is "IPv4 Soft Landing BIS".

While supporters believe that IPv4 supply should be limited for the current
stage in order to satisfy future newcomer’s need to help them to have an
affordable way of entering the internet of IPv4,

Opponents argue that current member’s need should be satisfied as much as
possible IPv4 supply will be running out naturally.

>From the above summaries of the two main policy discussions, it is clear
that what matters is not a mirror objection, but an ideology difference.
With ideology difference between the two parties, it is impossible for both
sides to find an acceptable solution that pleases all.

In this sense, there is an ideological difference between these two
policies. With ideology difference, objections cannot be regarded as
“mirror objection”. *Thus, with the existence of major objection, consensus
cannot be reached in the above two cases. However, ironically, both of them
have been declared as consensus in the floor and went into the last call.*

So what is the reason? I think everyone already has an answer: one side has
better and more organized meeting plans that bring more people to the floor.

A policy proposal may have full support on the floor of face-to-face meeting,
but as long as the major objection arguments in the mailing list are not
addressed, the proposal should not enter the last call. The only exception
is that the arguments are declared as “mirror objections” when everyone
votes for a yes in the floor.

*However, in no way can we identify the ideological difference in the above
as “mirror objections”.*

As long as an acceptable resolution cannot be found in the community,* the
status quo should continue, we don't have to be so desperate for a new
solution that many ideologically disagree.*

I truly hope that the Chairs can understand the consensus process better
and make a better judgment accordingly in the coming discussion.

We should not turn our PDP into a vote; rather, we should let all sides be
heard, whether it is those in the meeting room or on the mailing list. I
end this email with the following citation from RFC 7282, which, I believe,
is the building block of the internet:

 *“ 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 (a king or president), nor should decisions be made by a*

*   vote, 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*

*   (running code) trump theoretical designs."*

Links:

Wekipedia: https://en.wikipedia.org/wiki/Consensus_decision-making

RFC 7282:https://tools.ietf.org/html/rfc7282
-- 
--
Kind regards.
Lu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20171205/8b6d72a5/attachment-0001.html>