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

Jordan Carter jordan at internetnz.net.nz
Wed Nov 18 21:09:05 UTC 2015


hi Seun

I think I understand your point of view, but the CCWG discussed and made a
decision on this matter at the call yesterday and so I think it's closed.
If the SOs can live with the way it's been set out, I think the rest of us
probably should too.

cheers,
Jordan


On 19 November 2015 at 04:09, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:

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


-- 
Jordan Carter

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 *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151119/bd4d3193/attachment.html>


More information about the Accountability-Cross-Community mailing list