[Internal-cg] Consensus building process

[Jari Arkko]

I’m back from my vacation, thank you all for working hard on the ICG in the last couple of weeks.

And I wanted to make a couple of observations on this thread.

First, Russ was right in saying that we have one deliverable, and it is one that needs to be broadly supported by the global multistakeholder community. No such support implies no proposal and no transition*. But we want that transition to happen. So. We need to work towards some form of broad support, and being able to show that. It is the only thing we need to do, and it is very important.

Second, I wanted to emphasise what Lynn said: 

> At the same time, it seems we might be slipping into thinking that we will have major autonomous decisions to make.   Given our task is to coordinate/assimilate proposals from 3 different communities (for largely administrative work that is being done very well today), the main work of reaching agreement should be in the communities.  If there are substantial differences, they will have to sort them out at the source.  

Third, I would not like us to get confused by words. Milton has correctly reminded us of the dangers of loose terminology. The IETF term is rough consensus, not consensus, and rough consensus is also the term that we used in the charter. We should of course strive for full consensus, but I think the group has so far been consistent in stating that full consensus (unanimity) is too high bar. In my personal opinion unanimity requirement would prevent the completion of the transition, as there is likely to be someone who disagrees. But we do need nevertheless a truly broad support for the proposal, as well as support of the IANA customers. We can choose to show that broad support in different ways. I have been calling to use the rough consensus model and term. There are other possible terms and other possible decision mechanisms, and I have no strong opinion on which one we should do. But for information, I wanted to explain the difference between (super)majority voting and IETF rough consensus. In the IETF context, as explained in RFC 7282, rough consensus means a process where all concerns are understood and addressed to the extent seen as necessary by the group, rather than merely voting minority opinions away. That is, the emphasis is on understanding all issues and deciding how important they are, rather than specific voting numbers. I’d like some aspect of that to remain in the ICG process as well.

Fourth, I agree with Alissa’s concern that we need a process that terminates and that can be practically executed. And I don’t know how to interpret substantial vs. non-substantial, serious, firm, strong, etc.

My current thinking is that we are too focused on the ICG’s role and its voting procedures. We are not the centre of the universe, the communities are. If the names, numbers, and protocols communities think the proposal is good and majority of us agrees after a discussion and revision, we have a go. Otherwise we do not. And documenting minority view is in my view natural, and it does not take weight away from a broadly supported proposal.

Personally, I wonder if we could condense the principles to the following:

·       The aim of the discussion should be to try to find a solution where no member of the ICG maintains an opposition to the outcome. Reasons for objections should be given, allowing the communities and the ICG wherever possible to try to address those concerns. All objections need to be understood and discussed to determine their validity and the possible remedies.
·       After this process, the ICG can recommend a solution if at most a small minority disagrees, but most agree and no IANA customer group is opposed.

Jari

*) At least not different from the status quo… some of us feel fairly transitioned already :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/internal-cg/attachments/20140818/55885a1c/signature.asc>