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@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@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@internetnz.net.nz 
Skype: jordancarter

A better world through a better Internet



--
Jordan Carter
Chief Executive, InternetNZ

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

Sent on the run, apologies for brevity


_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community