[CCWG-ACCT] PDP interaction with bylaws veto - proposed approach

Jordan Carter jordan at internetnz.net.nz
Tue Nov 17 07:32:14 UTC 2015


*Dear CCWG colleagues,*

*PDP Interaction with Bylaws Veto*

In developing accountability improvements for ICANN, the CCWG has been
careful to try not to change ICANN's core policy-making processes. The
tools it has proposed to improve accountability are generally aimed at
ICANN-wide issues, not policy development in the SOs.

An example has been raised where policymaking and the bylaws veto power
might clash. Here is the scenario:

*The outcome of a PDP within an SO could mean that some consequential
changes to the ICANN bylaws were needed to implement its recommendations.*

*PDP is core policy making and should not be subject to community veto.*

*If the PDP *did* require bylaws changes, and those changes *were* subject
to the veto, then in effect the community veto would apply to policymaking.*


This is a gap in our core proposal which can reasonably easily be closed.

*Here is the simplest way to close the gap and ensure policy-making is
protected from said veto:*

*1: put a requirement (in the bylaws) that any Bylaws changes that are
required to implement a PDP are clearly identified in this way, and are not
combined with other, non-PDP related bylaws changes.*

*2: put a requirement in the Standard Bylaws veto process that for these
two steps of the community escalation process:*
* -- decision to hold a community forum*
* -- decision to exercise the veto power*
*the SO which has performed the PDP giving rise to the Bylaws change MUST
express its SUPPORT for the exercise of the veto.*

This approach has the least possible interference with the scheme of our
community powers, does not reopen questions about relative weights between
SOs/ACs, does not ban a veto being considered, etc. The community can still
trigger a veto process and have the conference call, so issues causing
concern will be discussed in a community-wide forum.

If this exceptional treatment to a bylaws change means the community really
can't live with the outcome of a PDP and associated bylaws changes, they
have a number of remedies they could use:

- they can work with the Board to ensure that the bylaws change proposal
doesn't get the required (2/3?) majority in the Board to be approved (and
so would not be implemented)

- they can recall the ICANN Board and replace it with a different Board
that will follow the community's wishes in not implementing such a bylaws
change

In other words, this does not leave the possibility of rogue "ICANN
transformation by PDP" on the table.


Other options I considered were:

- a blanket rule that no standard bylaws veto could apply to a PDP bylaws
change (rejected because this seemed to change the community power more
than minimally)

- a rule that no standard bylaws veto could apply to a PDP bylaws change
unless it exceeded certain impacts - for instance a net financial impact of
$0.5m (rejected because it would be complex to decide the principles to
apply to what was in and what was out, and because boundary cases would
need adjudication)

- a rule that no standard bylaws veto could apply to a PDP bylaws change
that only affected the Bylaws that constitute that SO (rejected because
policy may properly go beyond the structure of the SO's bylaws)


I look forward to your feedback on this proposed way through, and I thank
those who have taken the time to discuss the issue with me in coming to
this recommendation.


cheers
Jordan


Jordan Carter
WP1 Rapporteur, CCWG

Chief Executive
*InternetNZ*

+64-4-495-2118 (office) | +64-21-442-649 (mob)
Email: jordan at internetnz.net.nz
Skype: jordancarter
Web: www.internetnz.nz

*A better world through a better Internet*



-- 
Jordan Carter
Chief Executive, InternetNZ

+64-21-442-649 | jordan at internetnz.net.nz

Sent on the run, apologies for brevity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151117/9537bad2/attachment.html>


More information about the Accountability-Cross-Community mailing list