[WP1] Homework from WP1 call on Fri 30-Oct

Mon Nov 2 15:54:33 UTC 2015

P. 50 of our 2nd draft report, where we describe the community mechanism stated the following about "split voting":
315  There is no requirement or expectation than a participating SO or AC cast all its votes identically for a given issue (meaning all 5 in support or all 5 against). Instead, CCWG-Accountability anticipates that the votes each SO and AC casts will be a reflection of the balance of views within that SO or AC (or where possible of that sub-division, where votes have been allocated to sub- divisions). That is, block voting (casting all votes in favor or against the use of a power, even where there are diverse views) is not encouraged.

There was not a mandate via the public comment process to change this important sub-division right.  A number of us in the GNSO have explained how a change to this would result in only "majority rule" of a very diverse, intentionally diverse, set of interests.  I have not heard any compelling reason why we should move away from a model that captures the diversity of views (which is a good thing) in favor of one in which the majority can impose itself on the minority views (which is a bad thing).

I also do not believe there was any agreement in Dublin to do this (and even if some subgroup recommended it, that doesn't change what has been in our report twice).  Once again people are rushing to conclude this and big mistakes are being made in the process.  There is no consensus to move us in this direction and away from what is in our report on the issue of split-voting and insisting on doing so is what is holding-up conclusion of the issue at this point.

Robin

On Nov 2, 2015, at 6:16 AM, Julia Katja Wolman wrote:

> Dear all,
> 
> I would like to support Jorge with regard to the escalation process and not establishing a split vote system. Most importantly the underlying purpose of the escalation process is that the community has an incentive to compromise and reach consensus, and gives the community an incentive for the community to actually resolve the issues before an eventual community decision to exercise a community power. Although, we still have more work to do regarding the details, I believe this approach, which was carefully drafted in Dublin, is balanced and a split voting system would not to the same extent support the community in reaching compromises and solutions. 
> 
> Best
> 
> Julia
> 
> 
> 
> Julia Katja Wolman
> 
> DANISH BUSINESS AUTHORITY
> 
> Dahlerups Pakhus
> Langelinie Allé 17
> DK-2100 København Ø
> Telephone: +45 3529 1000
> Direct: +45 35291308
> E-mail: jukacz at erst.dk
> www.erhvervsstyrelsen.dk
> 
> MINISTRY FOR BUSINESS AND GROWTH
> 
> -----Oprindelig meddelelse-----
> Fra: wp1-bounces at icann.org [mailto:wp1-bounces at icann.org] På vegne af Jorge.Cancio at bakom.admin.ch
> Sendt: 31. oktober 2015 06:18
> Til: sdelbianco at netchoice.org
> Cc: acct-staff at icann.org; wp1 at icann.org
> Emne: Re: [WP1] Homework from WP1 call on Fri 30-Oct
> 
> Dear all and dear Steve, and dear Jordan,
> 
> Establishing a split vote system at the end of the escalation process is not just a mathematical operation.
> 
> It radically changes the incentive structure for arriving at consensus. Both within each SO/AC and within the community as a whole.
> 
> Within each SO/AC it reduces the incentives for compromising and seeking consensus on a common position. Every minority view knows it can play up to the end game and does not need to compromise. And the majority positions have little incentive to convince the minority as they can -without much discussion- gather, say 3 or 4 of the "votes".
> 
> Minority views are much better served with a strong consensus requirement in each SO/AC. This forces factions to come together and agree on one position. And: minorities can voice their views (and try to convince other parts of the community) within the open and deliberative parts of the escalation mechanism (i.e. the community forum).
> 
> After all nowadays each SO/AC has to arrive at common positions in the processes which presently exist (who, at the end of a policy process, wants to hear 5 different opinions from the GAC or from the ccNSO...?).
> 
> Why should they not ne able to do the same at the very end of an escalation path which we designed in Dublin, whose objective is to strive for community-wide consensus on the exercise of community powers?
> 
> This also impacts the rest of the SO/AC. They may want to continue with consensus decisions. If this is a general feeling and only one or two SO/AC seriously want "split voting", split voting should not be imposed on the rest of SO/AC. If this scheme is nevertheless imposed, it will act as a constant incentive within "former consensus" SO-AC to also split votes in the future.
> 
> In addition, if no other SO/AC really wants "split voting" or only one or two SO/AC do, the whole exercise is meaningless. I mean: if the other five SO/AC stick to a "one position system", this should in any case be respected and no multiple votes assigned to that SO/AC. And in practical terms, that one or two of the SO/AC had in such an environment "split votes" would mean to add fractions (say 3/5 and 4/5, minus 2/5 and 1/5) at the end of the process to the "units" expressed by the SO/AC sticking to the "one voice system". Would that have any weight, apart from distorting the incentives for arriving at consensus?
> 
> This would only be divisive and act as an incentive for not compromising.
> 
> Please kindly consider these thoughts carefully, because we are not just doing some math. We would be altering the carefully crafted compromise of Dublin...
> 
> regards
> 
> Jorge
> 
> 
> 
> Von meinem iPhone gesendet
> 
> Am 30.10.2015 um 22:26 schrieb Steve DelBianco <sdelbianco at netchoice.org<mailto:sdelbianco at netchoice.org>>:
> 
> Attached is my "homework" assignment today - reflecting split voting option for each AC/SO to decide  whether to exercise a community power.   I updated just the Appendix that Jordan circulated for today's call, adding explanations and a new column on the decision table (also shown below).
> 
> <Screen Shot 2015-10-30 at 5.16.33 PM.png>
> 
> From: <wp1-bounces at icann.org<mailto:wp1-bounces at icann.org>> on behalf of Jordan Carter
> Date: Friday, October 30, 2015 at 12:06 AM
> To: "wp1 at icann.org<mailto:wp1 at icann.org>"
> Subject: [WP1] Pls Read - Agenda for Meeting - WP1 on Fri 30 October at 18h UTC
> 
> Hi all
> 
> Our call is on Friday from 18h UTC, and may last up to two hours.
> 
> The proposed agenda items are as follows. PLEASE READ THIS AGENDA CAREFULLY as it sets out how I propose we run the meeting and the questions I propose we aim to answer.
> 
> 1. Review of Agenda
> 
> 2. Decision-making in the Community Mechanism This agenda item should look at decision-making, and seeing where the WP sits with key issues raised in the "Dublin Approach".
> 
> To prepare for this item I suggest reading the following papers:
> - Community Decision-Making: The Dublin Approach Working Paper
> - Public Comment Analysis - Voting in the community mechanism
> 
> If you have time, also have a look at the staff analysis of public comments - the "Model" and "Voting-Forum" tabs in particular.
> 
> Papers attached or linked below. I have not updated the Dublin Approach paper, but kept the very valuable comments, and moved Robin's added issues into separate rows in the Issues Table.
> 
> My suggestion is that we deal with the following specific questions, as they are the key changes in the model compared with what we presented in the Second Draft Proposal. We should for each question identify whether we have a consensus on them or whether we don't -- so we can advise the full CCWG of WP1's views.
> 
> a) Do we support the decision-making model (by consensus) replacing the voting approach?
> 
> b) Do we support only one view being expressed by each SO or AC?
> 
> c) Do we support an equal say for each participating SO or AC?
> 
> 
> We also need to address the following:
> 
> d) In our Third Draft Proposal, which SOs and ACs do we propose should be participating? that is, do we respect the SSAC's desire not to, and do we take a view re RSSAC?
> 
> e) Based on our answer to d), do we need to make any changes to the numbers in the decision-making framework?
> 
> 
> 
> 3. Other Work Required by WP1
> I do not have a current list of work we need to do in the next fortnight but believe this will be clearer following next week's CCWG. I welcome staff or co-chairs' input on this at this point of the WP1 agenda, and of course suggestions from WP1 participants.
> 
> 4. Any Other Business
> 
> 
> 
> Papers
> 
> I attach PDFs of the Dublin Approach paper and of the Public Comment report section on voting.
> 
> The Dublin paper Google Doc is at: <https://docs.google.com/document/d/1zHZl_NvQ1WChatX8NT2Q1rQi4zQZgbrbAxrQSsH3tZQ/edit>
> 
> The full WP1 Public Comment is at: <https://community.icann.org/download/attachments/56142506/2015-10-12-CCWG-WP1-SecondPC-FullAnalysis.pdf?version=1&modificationDate=1444644438000&api=v2>
> 
> You may also find the staff analysis of Public Comments useful, which deals with voting specifically in a couple of the tabs (Model and Voting-Forum): <https://community.icann.org/download/attachments/54693137/PC2%20tool%20-%2024%20SeptBTv2.xlsx?version=1&modificationDate=1443208173000&api=v2>
> 
> cheers
> Jordan
> 
> --
> Jordan Carter
> 
> Chief Executive
> InternetNZ
> 
> +64-4-495-2118 (office) | +64-21-442-649 (mob)
> Email: jordan at internetnz.net.nz<mailto:jordan at internetnz.net.nz>
> Skype: jordancarter
> Web: www.internetnz.nz<http://www.internetnz.nz>
> 
> A better world through a better Internet
> 
> <Screen Shot 2015-10-30 at 5.16.33 PM.png> <Dublin breakout on Community Decision - split votes v1.pdf> <Dublin breakout on Community Decision - split votes v1.docx> _______________________________________________
> WP1 mailing list
> WP1 at icann.org<mailto:WP1 at icann.org>
> https://mm.icann.org/mailman/listinfo/wp1
> _______________________________________________
> WP1 mailing list
> WP1 at icann.org
> https://mm.icann.org/mailman/listinfo/wp1
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/wp1/attachments/20151102/dcec7b2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/wp1/attachments/20151102/dcec7b2e/signature.asc>