[rpd] An review of consensus process.

[Andrew Alston]

Two things spring out at me from this email - firstly:

nor do we want decisions to be made in a vacuum without practical experience.

I would say that the majority of opponents of this policy that I have seen are people who are actively running ISPs and the petitioners against it are executives with real practical experience. The proponents on the other hand are largely not involved in the business side of real networks - hence - lack the experience.  This is not an insult to anyone - we each have our areas - but in this case - the ISPs are saying no - maybe we should listen.

The second thing is in the IETF they talk about running code - I would argue that the analogy here is real networks - with real reliance on the addresses.  The opponents of this policy without exception are running real networks - with real users - and real clients - it is not theory. They are almost all also invested in those networks in some form or another - so they have an intricate understanding of the harm this policy would do.

Do not get me wrong and twist my words - I believe that every single person should have a say - and I believe that consensus should rule the day - I do not however believe that there can be consensus with such different ideological viewpoints as driven by different perspectives that stem from different experience and different working backgrounds.

Consensus was never there - and will never be there on this issue - because the ideology is simply to far apart.  I really hope that the co chairs are prepared to do what is right - acknowledge that to err is human - and withdraw the decision to put this into last call - because any other decision is an appeal - irrespective of if this is declared lacking consensus in last call or not - that does not render the appeal moot - and do we really need to go on record as the RIR that has PDP decisions overturned on appeal because we can’t understand consensus?

Andrew

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Lu Heng <h.lu at anytimechinese.com>
Sent: Tuesday, December 5, 2017 4:57:41 PM
To: rpd
Subject: [rpd] An review of consensus process.


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<https://en.wikipedia.org/wiki/Consensus_decision-making>

RFC 7282:https://tools.ietf.org/html/rfc7282<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/229e1567/attachment-0001.html>