[WP1] board inaction stress tests

Thomas Rickert rickert at anwaelte.de
Thu Apr 9 16:13:49 UTC 2015


Jonathan, all,
I would like to share a few thoughts on this with you.

- I understand that the legal sub team is reaching out to the firms we use to get an answer to the question whether there is a possibility for the community to call the board to action. If there was an affirmative response to that, the stress tests would not fail.

- If there were no such possibility to call the board to action, there would still be the possibility to remove the board. I understand that not all issues with the Board should be resolved by using this nuclear option, I still think this is a way the board can be threatened to take action requested by the community. Thus, I am not sure the response to the stress test would inevitably be „inadequate“. Avri’s point is a very good one. By requesting the Board to provide information on progress made and action / inaction, the Board is forced to deal with recommendations and provide a rationale for their (in)activity. One of the concerns would certainly be around security, stability and resiliency of the DNS. If the Board chooses to ignore a recommendation by the SSAC and puts that in writing, inaction would likely be a violation of the bylaws we are working on and could lead to removing the Board. To me, Avri’s recommendation combined with the possibility to get the board removed, could be deemed a sufficient response to the stress test.

It is imperative that we closely collaborate with the CWG on this, so I guess it would be worthwhile to discuss with the CWG as to when they would deem a response adequate or inadequate so that we apply the same standards.

Best,
Thomas




> Am 09.04.2015 um 15:46 schrieb Jonathan Zuck <jzuck at actonline.org>:
> 
> Folks,
> We didn't end up with time for this on the Wenesday WP1 call but I, and others, continue to be concerned about scenarios where the board fails to act. 6 of the approved stress tests involve a failure to act on the part of the board (as opposed to a decision we can oppose) and, as such, will not evaluate well with what appears to be the current draft for public comment.  There's a proposed bylaw change from ATRT2 that should help, along with some minor language changes from WP2.
> 
> 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.
> 
> 6 stress tests anticipated a community power that may fail to make the cut for first public comment:  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).
> 
> The ST-WP notes 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.
> You might recall that Alan Greenberg originally brought up the notion of "compelling the board to take action” in Frankfurt and there are several of the existing stress tests that highlight the need for that capability on the part of the community. Specifically,
> 
> 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.   This stress test relies upon the community’s ability to “force ICANN to implement a recommendation arising from an AOC review, namely SSR"
> 
> 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 is dotless domains where there was very specific advice from SSAC as well as consensus concern and the board was slow to respond.  This stress test relies upon the community’s ability to "force ICANN to respond to recommendations from advisory committees such as SSAC."
> 
> There is a similar concern with stress tests 3,4, 20, and 22, since they rely upn community ability to “force ICANN to implement a consensus policy or recommendation of an AoC review”
> 
> 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.
> 
> I would really like to see if we could get these two changes into our draft before it goes to public comment. Thank you.
> 
> Jonathan
> 
> Jonathan Zuck
> President
> 202-331-2130 X 101 | jzuck at actonline.org <mailto:jzuck at actonline.org> | Skype: jvzuck
> 
> ACT | The App Association
>  <https://twitter.com/actonline>
>  <https://www.facebook.com/actonline.org>
>  <http://actonline.org/>
> 
> _______________________________________________
> WP1 mailing list
> WP1 at icann.org <mailto:WP1 at icann.org>
> https://mm.icann.org/mailman/listinfo/wp1 <https://mm.icann.org/mailman/listinfo/wp1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/wp1/attachments/20150409/06dba919/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/wp1/attachments/20150409/06dba919/signature-0001.asc>


More information about the WP1 mailing list