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

[Seun Ojedeji]

Hello Jordan,

Just incase you did not get my initial mail, I am resending and would be
good to get a response to my question.

I don't think any outcome of a PDP should be subject to community veto
unless a particular SO found that the board's implementation of the policy
does not reflect the true interpretation of the particular policy and such
petition should even the initiated/restricted to the affected SO. So as an
example, it will be wrong for GNSO to initiate a petition against a policy
implementation that emerged from the ccNSO. Even at that, the community
power should only be available as last resort to such SO; after exhausting
the reconsideration processes in their PDP.

There is a proverb in my local language which says "...Chicken does not eat
another chicken intestines" it is absurd to provide a means of weakening
respective PDPs instead of strengthening it and that's the reason why I
don't think the second requirement you indicated is appropriate.

Regards
Sent from my Asus Zenfone2
Kindly excuse brevity and typos.
On 17 Nov 2015 08:51, "Seun Ojedeji" <seun.ojedeji at gmail.com> wrote:

> 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/20151118/f5788d11/attachment.html>