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

[Seun Ojedeji]

Hello Jordan,

Thanks for the share, just curious on your statement below:

"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)"

Do you mean this has been proposed on the list and already rejected? As it
seem to be ideal way to go. So after ensuring what you've suggested in item
1, I think it will be good for what you stated above to follow suite.
Although will suggest further modification as thus:

"A blanket rule that no standard bylaws veto could apply to a PDP bylaws
change, so long as the change reflects true interpretation of the PDP
policy"

Regards

Sent from my Asus Zenfone2
Kindly excuse brevity and typos.
On 17 Nov 2015 08:32, "Jordan Carter" <jordan at internetnz.net.nz> wrote:

> *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
>
> _______________________________________________
> 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/20151117/fa2d7575/attachment-0001.html>