[ST-WP] Spurring Board Action

Wed Apr 8 20:41:52 UTC 2015

I'm not sure what you mean by "general community veto" being struck by the stress tests group.  There isn't really such a thing that has been proposed.

The Community veto proposal that I made has always been for very specific purposes: budget, bylaws revision, strat plan.  

According the template posted to the website on 11 March:

"This challenge mechanism would only apply to a narrow set of predetermined high impact board decisions such as the adoption of the organization’s strategic plan, approval of the budget, approval of bylaws, etc."

So I'm also not sure what is meant by a conversation in Istanbul to narrow the veto proposal down only these things - since it has always been about these specific things.

I remain in opposition to the stress tests group singling this proposal out for "strikethrough" at this stage.  That is not an appropriate role for the stress tests group - nor within its authority.  And it seems to be based on misinformation and or misunderstandings.

Thanks,
Robin

On Apr 8, 2015, at 1:27 PM, Cheryl Langdon-Orr wrote:

> To be clear Robin the ST-WP is NOT removing anything we have however noted that neither WP1 or 2  has (as yet proposed a general Community Veto) unlike specific veto for Budget etc.,  that is why the text is strike through in the doc at this stage  and not removed, and it will allow us to show it as a mechanism if an when like any others it is actually proposed and agreed to...   However what IS important from our running through these various exercises is that should the general Community Veto not end up as a proposed mechanism  the ST's it is applied to currently will still not be critically effected...
> 
> I am sure Steve will have more to say on this issue as well to help you better understand what the ST-WP role is and what it does... This run and re run through process is important to help us refine the St's as well as recognise any obvious gaps that the other WO's may need to address, particularly with the very little time after the mechanisms and powers of the community etc., are agreed to that will be available for the ST-WP to complete its work in a timely manner pre publication of documentation...
> 
> 
> Cheryl Langdon-Orr ...  (CLO)
> 
> about.me/cheryl.LangdonOrr
> 
>  
>  
> 
> On 9 April 2015 at 06:17, Robin Gross <robin at ipjustice.org> wrote:
> There is no authority for removing the community veto proposal at this stage.   I'm not sure how the stress tests group is proposing to eliminate proposals like this.  It seems to be an over-reach of this group - this sub-group is not a gate-keeper to shut-down proposals that show to have no problems in operation.   The memos coming back from the legal advisors all say vetos are possible and probably desirable in some fashion.
> 
> Robin
> 
> 
> On Apr 8, 2015, at 10:34 AM, Steve DelBianco wrote:
> 
>> Thanks, Jonathan. 
>> 
>> Per our discussion today’s stress test WP call, we want to inform the rest of CCWG about this.  Here’s a draft for your consideration:
>> 
>> When ST-WP applies the stress tests to proposed mechanisms, we look at all proposed measures that are under active consideration in the CCWG.   (Those are the measures cited in the right column of each stress test). 
>> 
>> When the CCWG and CWG package their proposals for public comment, the ST-WP can then re-apply the stress tests to what is actually proposed.
>> 
>> Until then, the ST-WP is monitoring discussions in WP1 and WP2 and wanted to flag two proposed measures that have implications for stress testing. 
>> 
>> First, we note that the ‘Community Veto’ measure first proposed in Singapore seems not to be under active consideration in WP1, and is unlikely to make the cut for our first public comment document.   
>> 
>> As initially proposed, a community veto would enable a supermajority of the community representatives to veto a board decision, putting it back in the hands of the board.  At the Sunday Istanbul meeting, a sub-team proposed limiting the community veto only to a list of specified board decisions. Further discussion revealed reservations about allowing community veto to block decisions of the board without citing standards or principles, and attention turned to enhancing other community challenge powers, such as Reconsideration and IRP.
>> 
>> In our latest draft of Applying Stress Tests, we applied a strike-thru to the community veto mechanism in the 8 stress tests that had cited the measure.  On today’s call, we concluded that the absence of a community veto would not in itself flip any stress tests from ‘Adequate’ to ‘Inadequate’, since the reconsideration and IRP measures are available to the community.   
>> 
>> So we are alerting the CCWG to this situation, although we do not believe stress testing reveals that community veto must be further developed as long as other challenge mechanisms are available. 
>> 
>> Second, we note that 6 stress tests anticipated another community power that may also fail to make the cut for first public comment. As explained in the email below from Jonathan Zuck, a proposal from the Frankfurt meeting would allow the community to force ICANN to implement a previously-approved Review Team Recommendation or consensus policy.  Another suggested power would allow the community to force ICANN to respond to formal advice from an Advisory Committee (SSAC, ALAC, GAC, RSSAC).
>> 
>> We note that several stress tests would likely flip from ’Adequate’ to ‘Inadequate’ if the community lacked any new powers to force ICANN to consider and respond to formal advice from an Advisory Committee.  
>> 
>> It’s possible that WP1 could address this concern by developing a power for the community to force ICANN board to acknowledge and respond to AC advice, since that board response could trigger community challenge mechanisms such as Reconsideration or IRP.    This possibility requires some advice from legal experts, as described in Jonathan’s note below. 
>> 
>> In conclusion, we believe that CCWG WP1 could adopt the ATRT2 recommendation for a bylaws change along these lines:
>> 9.1. ICANN Bylaws Article XI should be amended to include the following language to mandate Board Response to Advisory Committee Formal Advice:  The ICANN Board will respond in a timely manner to formal advice from all Advisory Committees, explaining what action it took and the rationale for doing so.
>> 
>> 
>> 
>> —
>> Steve DelBianco
>> Executive Director
>> NetChoice
>> http://www.NetChoice.org and http://blog.netchoice.org
>> +1.703.615.6206
>> 
>> 
>> 
>> From: Jonathan Zuck
>> Date: Wednesday, April 8, 2015 at 9:05 AM
>> To: "ccwg-accountability4 at icann.org"
>> Subject: [ST-WP] Spurring Board Action
>> 
>> Greetings!
>> On the call this morning, we had a discussion of some stress tests that risk falling through the cracks. Cheryl asked me to briefly summarize the portion of the discussion dealing with stress tests which involved board inaction. You might recall that Alan Greenberg originally brought up the notion of "compelling the board to take action" and there are several of the existing stress tests that highlight the need for that capability on the part of the community. Specifically, 
>> 
>> ST 11: “force ICANN to implement a recommendation arising from an AOC review, namely SSR"
>> 
>> ST 17:  "force ICANN to respond to recommendations from advisory committees such as SSAC."
>> 
>> ST 3,4, 20, 22:  “force ICANN to implement a consensus policy or recommendation of an AoC review” 
>> 
>> Cheryl brought up the fact that 11 and 17 had piqued the interest of the CWG so we focused on those two. Stress test 11 was inspired by the recent breach at ICANN and the inability of the community to extract information about the breach. Without the ability to spur action, that stress test would fail.
>> 
>> Stress test 17 was about recommendations that are ignored by the board. One example we have used for some time is on the issue of Name Collisions and certs where a fairly large outcry on the part of the community was required to spur action a year ago. Another example, near and dear to the ALAC is dotless domains where there was very specific advice from SSAC as well as consensus concern and the board was slow to respond.
>> 
>> Avri brought up recommendation 9 of the ATRT with respect to advice which dictates the board respond to advice in a timely manner:
>> 
>> 9.1. ICANN Bylaws Article XI should be amended to include the following language to mandate Board Response to Advisory Committee Formal Advice: 
>> The ICANN Board will respond in a timely manner to formal advice from all Advisory Committees, explaining what action it took and the rationale for doing so.
>> 
>> The question then arose whether a board "response" would be sufficient to trigger the other review mechanisms currently under consideration  by WP2 so it was resolved to discuss that with Becky and her team. Perhaps it would be enough to dictate that the trigger mechanism for a review is a decision or response from the board. If not, we might need revisit a specific community power to induce the board to vote on a recommendation so that the vote can act as a trigger for further review if necessary.
>> 
>> Cheryl, I hope I have sufficiently stressed everyone out with the possibility of board inaction. Feel free to ask questions or raise issues I have forgotten. I'll clip the mp3 for the topic if that's helpful to folks.
>> Jonathan
>> 
>> 
>> Jonathan Zuck
>> President
>> 202-331-2130 X 101 | jzuck at actonline.org | Skype: jvzuck
>>  
>> ACT | The App Association
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Ccwg-accountability4 mailing list
>> Ccwg-accountability4 at icann.org
>> https://mm.icann.org/mailman/listinfo/ccwg-accountability4
> 
> 
> _______________________________________________
> Ccwg-accountability4 mailing list
> Ccwg-accountability4 at icann.org
> https://mm.icann.org/mailman/listinfo/ccwg-accountability4
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ccwg-accountability4/attachments/20150408/b6acca52/attachment-0001.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/ccwg-accountability4/attachments/20150408/b6acca52/signature-0001.asc>