[CCWG-ACCT] Voting weights in community mechanism

[Greg Shatan]

I would just like to copy into this thread a response that Keith Drazek
gave in another thread, which is a far more succinct (and perhaps more
constructive) response to Ed's message than mine:


I acknowledge there is more work to be done around the vote balance issue
> (as I said in an earlier email), but I'm confident we can resolve the issue
> satisfactorily following the receipt of additional community feedback.


On Thu, Jul 30, 2015 at 2:22 AM, Greg Shatan <gregshatanipc at gmail.com>
wrote:

> This is really quite a baffling last-second attempt to throw together a
> bunch of half-truths and outright misstatements, casting unwarranted
> aspersions on the careful work that this group with an objective that is
> entirely unclear.  Any examination of these statements causes them to fall
> like a house of cards.
>
> It was pretty obvious once you examined the proposal as is the political
>> reality that giving any voting power to the United States military, through
>> it's 3/12 member representation at RSSAC, is going to cause problems.
>
>
> The membership of RSSAC is public knowledge and has been for the duration
> of this CCWG.  A voting role for the RSSAC has been a possibility for
> months, and no one raised this "issue."  I'm always skeptical when somebody
> says something is "obvious" -- it usually means it's BS.  This attempt to
> trump up problems is so slapdash that the (readily available) facts aren't
> even accurate.  There are 3 root servers under the US government, but only
> two are associated with the US military -- the third is controlled by NASA,
> a civilian agency.  These have been around pretty much since the dawn of
> Internet time, so claiming this is suddenly a problem is really quite
> absurd. Are there any issues from the history of ICANN that can be cited as
> arising from the control of these root servers, or the membership of their
> (civilian) administrators in RSSAC.  This just seems like FUD.  Calling it
> a "mistake" doesn't make it one.
>
> As far as "illusion" busting, whether one participant decides to oppose
> for a series of manufactured reasons that don't hold water does not "bust"
> consensus.  Going back to those reasons, for a little "myth-busting":
>
> 1) inclusion of the U.S. military as a voting member through RSSAC,
>
>
> Answered above
>
> 2) an unwarranted change of the power balance and functions of the
>> respective SOAC's when compared to current voting arrangements, which
>> violates the CCWG policy published in the legal scoping document of 19
>> March 2015 , a consensus policy whose reversal has not been discussed or
>> approved by the group,
>
>
> There are no "current voting arrangements,"  unless one is referring to
> the ICANN Board, which is quite a different thing than this community
> mechanism; it's completely unclear and unexplained what "CCWG policy" is
> being "violated" -- misusing the term "consensus policy" to give this
> unsupported claim a sense of gravitas is really quite amusing...
>
>   3) the lack of safeguard against capture through coordinated
>> manipulation taking advantage of the possibility of parties to
>> simultaneously belong to multiple SO's and AC's,
>
>
> This is another summary "issue" that's never been raised before and
> magically appears now without any explanation or clarification.  What
> possibility is being referred to?  There has been some discussion of the
> possibility of parties being members of different constituencies or SGs in
> the GNSO, but that's been dealt with already (such parties can only vote in
> one such organization) and is clearly not what's being referred to here.
> There's a lot of scary, FUD-y words being thrown around but absolutely no
> substance -- no explanation, no detail, no credibility.  The fact that a
> root server operator may also be a registry operator (among hundreds of
> registry operator), or that a GAC member may also be a ccNSO operator
> (among a couple hundred ccNSO registry operators) does not somehow become a
> concern due to vague imprecations in a rushed email, which won't even be
> defended by its author.
>
>  4) problems of double dipping per number 3 which violate the principle of
>> one person / one party one vote which is customary international law and
>> required by ICANN through it's Bylaws commitment to adhere to international
>> law
>
>
> ​
> ​This is just a restatement of number 3, and fails along with it
> .  Trying to inflate some unstated minor occurrence (which I assume to be
> the overlaps stated above) into some self-styled "double dipping" problem
> just doesn't hold water. Being a member of two different bodies or
> committees does not violate "one party/one vote" and claiming this somehow
> be a violation of international law is just hysterical (in both senses of
> the word).
> ​
>
>
> ...plus likely a number of other problems that neither of us have thought
>> of given the rushed nature of things.
>
>
> This basically translates as "I can't think of any problems, but there
> must be some."  That is hardly the kind of objection that even merits a
> response.
>
> Finally, I disagree with the characterization of the 5/2 proposal, and
> think that the suggested statement would be neither truthful nor
> transparent -- rather, it would by false and hyperbolic.
>
> I must give my esteemed colleague points for inventiveness, but none for
> substance.  This is the virtual equivalent of throwing a stink-bomb into
> the middle of a meeting and then running away.  Thankfully, we don't need
> to clear the room to get rid of the odor.
>
> If this an attempt to buy more time for some colleagues who are still
> working on minority statements, I can also give points for loyalty.  But
> the schedule for publication of this document has been well-known for
> weeks.  It's unfortunate that some could not plan ahead to meet that
> timeframe.  I hardly think it's prejudicial if these are published or
> notified to the public comment page a couple of days after the Report --
> appropriate notice can be made that minority reports are expected. Using a
> loaded term like "separate but equal" (harkening back to the dark days of
> racial segregation in the US) to describe this strays into demagoguery.
> Claiming "we all know" things is no more convincing than saying something
> is "obvious"  -- everyone's entitled to their opinion, but not to claim
> that it is "known" by anyone other than themselves.  We should not let the
> perfect be the enemy of the good, in this instance or in the instance of
> our proposal in general.
>
> It would be helpful if there were some indication of the real goal and
> concern behind this, rather than a bunch of baseless accusations.  As it
> is, I remain baffled at what is hoped to be accomplished other than an
> attempt at delay.
>
> Greg
>
>
>
>
> On Wed, Jul 29, 2015 at 9:04 PM, Edward Morris <egmorris1 at toast.net>
> wrote:
>
>> Hi all,
>>
>> Thanks for responding to our concerns about the ability of Board
>> appointees to block the communities ability to remove Board members. It was
>> pretty obvious once you examined the proposal as is the political reality
>> that giving any voting power to the United States military, through it's
>> 3/12 member representation at RSSAC, is going to cause problems. You guys
>> are under such time pressure mistakes are going to happen and the
>> consequences of actions may not always be readily apparent. I don't blame
>> you: there is no Dummies guide to restructuring a major international
>> corporation in 7 months or less. Writing such a book just might be a wise
>> career choice once you wrap up this project.
>>
>> I hope you in good faith are not going to try to claim that there is
>> consensus for the 5 X2 model. Just so that illusion is busted I oppose that
>> model for the 1) inclusion of the U.S. military as a voting member through
>> RSSAC, 2) an unwarranted change of the power balance and functions of the
>> respective SOAC's when compared to current voting arrangements, which
>> violates the CCWG policy published in the legal scoping document of 19
>> March 2015 , a consensus policy whose reversal has not been discussed or
>> approved by the group,  3) the lack of safeguard against capture through
>> coordinated manipulation taking advantage of the possibility of parties to
>> simultaneously belong to multiple SO's and AC's, 4) problems of
>> double dipping per number 3 which violate the principle of one person / one
>> party one vote which is customary international law and required by ICANN
>> through it's Bylaws commitment to adhere to international law...plus likely
>> a number of other problems that neither of us have thought of given the
>> rushed nature of things.
>>
>> I sadly will not be on the calls later today due to pre-existing work
>> commitments and the last minute scheduling of the calls.
>>
>> I would respectfully request that if you are going to go ahead with
>> putting the 5 X 2 proposal in the public comment materials you truthfully
>> and transparency note that this proposal was a last minute substitute for a
>> proposal that was deemed inadequate. I understand that this was our
>> previous proposal but we don't know what the response would have been had
>> we not ditched it. I agree with Keith that we will need to discuss all of
>> this again once the public comments are received.
>>
>> With regards to the minority reports I appreciate the situation you are
>> in. I do not, however, accept the explanation offered by Thomas that
>> minority reports will be accepted later but just won't make the
>> publication. I'm not a big fan of separate but equal. Minority views not in
>> the initial published report  are at a distinct disadvantage  in terms of
>> public receipt and review. We all know this. Let's stop pretending. You are
>> good guys but you're starting to act like those we want to hold
>> accountable. I know you really don't want to set the precedent of shorting
>> minority rights. Thomas, as our GNSO representative I am informing you that
>> there are at least two groups of GNSO members who are preparing minority
>> reports but do not believe they can get it done by noon tomorrow. If you
>> can't do anything, fine, but be please be prepared to explain it to them at
>> the next Council meeting. I've tried but they are not accepting my
>> explanations and, frankly, I don't blame them.
>>
>> Thanks for considering, thanks for your hard work and good luck on the
>> calls later today.
>>
>> Best,
>>
>> Edward Morris
>>
>>
>>
>> ------------------------------
>> *From*: "Drazek, Keith" <kdrazek at verisign.com>
>> *Sent*: Thursday, July 30, 2015 12:11 AM
>> *To*: "Mathieu.Weill at afnic.fr" <Mathieu.Weill at afnic.fr>, "
>> accountability-cross-community at icann.org" <
>> accountability-cross-community at icann.org>
>> *Subject*: Re: [CCWG-ACCT] Voting weights in community mechanism
>>
>> Thanks to the Co-Chairs for this message.
>>
>> I agree that the best approach at this time is to revert to the 5x5 and
>> 2X2 reference model included in our first proposal. It received support and
>> we obviously don't have consensus on a replacement model. We'll continue to
>> discuss and debate the issue of vote distribution, but I suggest we'd be
>> better off doing so AFTER we receive community feedback from the upcoming
>> public comment period.
>>
>> Regards,
>> Keith
>>
>> -----Original Message-----
>> From: accountability-cross-community-bounces at icann.org [mailto:
>> accountability-cross-community-bounces at icann.org] On Behalf Of Mathieu
>> Weill
>> Sent: Wednesday, July 29, 2015 9:37 PM
>> To: accountability-cross-community at icann.org
>> Subject: [CCWG-ACCT] Voting weights in community mechanism
>>
>> Dear Colleagues,
>>
>> You will remember that our Initial Report Reference Model on voting
>> weights was 5 votes for ccNSO, gNSO, ASO, ALAC and GAC, 2 for SSAC and
>> RSSAC. During the public comment period, we have received some comments
>> (largely debated since on the list) with regards to the respective number
>> of votes of gNSO and ALAC, and these are well noted.
>>
>> During our call on Tuesday we discussed the voting weight section of the
>> community mechanism proposal and asked for WP1 to refine its proposal
>> accordingly. The topic was then discussed again during the WP1 call that
>> followed a few hours later. WP1 agreed to submit to our group a proposal
>> with 5 votes for each SO or AC, pending intentions from GAC, SSAC and RSSAC
>> to joint the mechanism as voting members. (see latest doc here :
>>
>> https://community.icann.org/download/attachments/52888421/5A2-Community-Mechanism-Voting-PenultimateDraft.pdf?version=1&modificationDate=1438079125000&api=v2
>> )
>>
>> A concern has come to our attention with this latest, new, proposal. If
>> SSAC and RSSAC have 10 votes out of 35, they could jointly block a Board
>> recall (75% votes required, 27 votes). Since they are both composed of
>> individuals appointed by the Board, some may question their independence in
>> case such a power is triggered. This could raise concerns of conflicts of
>> interest.
>>
>> We discussed this between co-chairs and with Jordan as WP1 rapporteurs,
>> and as a consequence would like to suggest we go back to the initial
>> Reference model (5x5 and 2x2 votes) as a basis for our public comment
>> document.
>>
>> This proposal will be on our agenda for Thursday's calls but we wanted to
>> provide this heads-up in advance in order to facilitate an informed
>> discussion.
>>
>> Best regards,
>> Thomas, Leon & Mathieu
>> Co-chairs
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150730/d8c965d7/attachment.html>