PDP interaction with bylaws veto - proposed approach
*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 Web: www.internetnz.nz *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
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 Web: www.internetnz.nz
*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
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 Web: www.internetnz.nz
*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
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@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@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 Web: www.internetnz.nz
*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
-- Jordan Carter Chief Executive *InternetNZ* +64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz *A better world through a better Internet *
Hello Jordan, Actually I had made my point prior to yesterday and I just followed up when I did not get your response. So I hope it was reported during the call yesterday. That said, may I know what the group's decision is on this (came in late on the call yesterday and only heard where you said you will be sharing a document in few hours?) Regards Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 18 Nov 2015 22:09, "Jordan Carter" <jordan@internetnz.net.nz> wrote:
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@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@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 Web: www.internetnz.nz
*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
-- Jordan Carter
Chief Executive *InternetNZ*
+64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz
*A better world through a better Internet *
hi Seun That document mentioned is the one I sent today, about ~1 hour ago. cheers! Jordan On 19 November 2015 at 11:00, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hello Jordan,
Actually I had made my point prior to yesterday and I just followed up when I did not get your response. So I hope it was reported during the call yesterday.
That said, may I know what the group's decision is on this (came in late on the call yesterday and only heard where you said you will be sharing a document in few hours?)
Regards
Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 18 Nov 2015 22:09, "Jordan Carter" <jordan@internetnz.net.nz> wrote:
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@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@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 Web: www.internetnz.nz
*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
-- Jordan Carter
Chief Executive *InternetNZ*
+64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz
*A better world through a better Internet *
-- Jordan Carter Chief Executive *InternetNZ* +64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz *A better world through a better Internet *
Hello Jordan, Just filtered and the only document I saw was the one on threshold? Regards Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 18 Nov 2015 23:09, "Jordan Carter" <jordan@internetnz.net.nz> wrote:
hi Seun
That document mentioned is the one I sent today, about ~1 hour ago.
cheers! Jordan
On 19 November 2015 at 11:00, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hello Jordan,
Actually I had made my point prior to yesterday and I just followed up when I did not get your response. So I hope it was reported during the call yesterday.
That said, may I know what the group's decision is on this (came in late on the call yesterday and only heard where you said you will be sharing a document in few hours?)
Regards
Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 18 Nov 2015 22:09, "Jordan Carter" <jordan@internetnz.net.nz> wrote:
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@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@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 Web: www.internetnz.nz
*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
-- Jordan Carter
Chief Executive *InternetNZ*
+64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz
*A better world through a better Internet *
-- Jordan Carter
Chief Executive *InternetNZ*
+64-4-495-2118 (office) | +64-21-442-649 (mob) Email: jordan@internetnz.net.nz Skype: jordancarter Web: www.internetnz.nz
*A better world through a better Internet *
Dear Jordan I wonder whether it is possible to objectively separate PDPs from other bylaw changes. How and who would be the arbiter in these cases? PDPs may result in structural changes, which may affect other parts of the community. By giving the starting organization a veto over the exercise of the community power, aren’t we privileging that organization? As far as I know when a PDP resulting in a bylaws change comes to the Board, there is no priviledged position for the Board members coming from the starting organization. The Board just decides with the well-being of the organization and the global public interest in their mind, right? Just some thoughts and sorry for chiming in so belatedly, but as you know there are many parallel tracks ongoing Regards Jorge Von: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] Im Auftrag von Jordan Carter Gesendet: Dienstag, 17. November 2015 08:32 An: Accountability Cross Community <accountability-cross-community@icann.org> Betreff: [CCWG-ACCT] PDP interaction with bylaws veto - proposed approach 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<tel:%2B64-4-495-2118> (office) | +64-21-442-649<tel:%2B64-21-442-649> (mob) Email: jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Skype: jordancarter Web: www.internetnz.nz<http://www.internetnz.nz/> A better world through a better Internet [https://mail.google.com/mail/u/0/photos/me?at=AF6bupOucTjwCs9wZukdGAKPf5VnWt...] -- Jordan Carter Chief Executive, InternetNZ +64-21-442-649 | jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Sent on the run, apologies for brevity
I don't care really much about the other SO's, but the ccNSO is different, at least in this context. el On 2015-11-18 12:35, Jorge.Cancio@bakom.admin.ch wrote:
Dear Jordan
I wonder whether it is possible to objectively separate PDPs from other bylaw changes. How and who would be the arbiter in these cases?
PDPs may result in structural changes, which may affect other parts of the community. By giving the starting organization a veto over the exercise of the community power, aren’t we privileging that organization?
As far as I know when a PDP resulting in a bylaws change comes to the Board, there is no priviledged position for the Board members coming from the starting organization. The Board just decides with the well-being of the organization and the global public interest in their mind, right?
Just some thoughts and sorry for chiming in so belatedly, but as you know there are many parallel tracks ongoing
Regards
Jorge
*Von:*accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] *Im Auftrag von *Jordan Carter *Gesendet:* Dienstag, 17. November 2015 08:32 *An:* Accountability Cross Community <accountability-cross-community@icann.org> *Betreff:* [CCWG-ACCT] PDP interaction with bylaws veto - proposed approach
*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 <tel:%2B64-4-495-2118> (office) | +64-21-442-649 <tel:%2B64-21-442-649> (mob) Email: jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz> Skype: jordancarter
Web: www.internetnz.nz <http://www.internetnz.nz/>
/A better world through a better Internet/
-- Jordan Carter Chief Executive, InternetNZ
+64-21-442-649 | jordan@internetnz.net.nz <mailto: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
-- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/
On 18/11/15 11:06, Dr Eberhard W Lisse wrote:
I don't care really much about the other SO's, but the ccNSO is different, at least in this context.
On 18/11/15 11:06, Dr Eberhard W Lisse wrote:> I don't care really much about the other SO's, but the ccNSO is different, at least in this context.
Eberhard is right, but anyone who was not involved in ICANN before 2005 it's worth pointing out some background to the reasons the ccNSO is so different. It will help understand not only why no change to the 2003 settlement in the guise of increasing accountability, will be acceptable to a significant number of ccTLD managers, and thus the entire package will not get consensus. There are two important concepts, one borrowed from the European Union, and the other is a concept well known to GAC members, although it has a slightly different construction used in this context. Those are "subsidiarity" and "sovereignty". SUBSIDIARITY ============ Many, many ccTLD operators could not have become members of the ccNSO without this building block of repairing the relationship between ccTLDs and ICANN which had, in 2003, broken down at a fundamental level. There are in fact many different reasons. However, if membership of the ccNSO implied that the ccNSO majority set ccTLD policy for its members (as the gNSO appears to do), the organisations concerned simply could not be members, and the legitimacy of the ccNSO would be threatened due to non-participation. This including knotty legal issues for those ccTLDs who are considered to be public authorities (i.e. government controlled, owned or directed). Other, private sector ccTLDs, take the view similarly choose not to concede power over their internal policies to a Johnnie-come-After private body without statutory authority over them, and there are still holdouts for this reason too. The principle of subsidiarity is this. No policy or policy decision should be taken at the overall level (c.f. the Union) where such policy was not absolutely necessary to achieve the purpose of the organisation. The expectation is that policy and decisions about how a ccTLD is run, operated etc. is a local matter in the country or territory that the two letter code represents, subject to the rule of law (self-evidently both in California and the place of establishment of the ccTLD operator). And this is echoed in the current version of the GAC principles (2005). SOVEREIGNTY ============ This is one those words which has multiple different, but similar meanings. We could probably coin a better, but for the time being this will have to do. Clearly Prof. Muelller's recent insightful article tells us that traditional views of national sovereignty (e.g. the UK having sovereignty over the Turks and Caicos Islands) cannot apply to 2-letter codes. However, if we use the word sovereignty to highlight the "right of each country or territory ccTLD manager to self-determination in matters relating to its own ccTLD", then it's may be helpful to say that ccTLDs are sovereign unless their Designated Manager misbehaves substantially (See RFC1591, and the interpretation work). Ultimately the test, that I, and I know several other ccNSO Council Members will use when the matter is finally considered is this. "Does the proposal significantly affect the subsidiarity principle and the right of ccTLDs individually and collectively to regulate their own affairs without the involvement or interference of third parties?" Any proposal which does not answer that question in the negative will not receive the necessary support, in my view. On 18/11/15 11:06, Dr Eberhard W Lisse wrote:
I don't care really much about the other SO's, but the ccNSO is different, at least in this context.
Jorge, I'm not sure I agree with your statement: "PDPs may result in structural changes, which may affect other parts of the community." There are limitations on what PDPs can consider and achieve, and I'm struggling to think of a way that a PDP could result in structural changes. I can't think of a past PDP that has had such a result. I'm primarily familiar with GNSO PDPs, but I expect the same is true of ccNSO PDPs. If this is to be a basis for objection to Jordan's proposal, I think this would need to be a significant possibility. If you could "put some meat on the bones,' so to speak, that would be helpful in understanding your concern. Thanks! Greg On Wed, Nov 18, 2015 at 5:35 AM, <Jorge.Cancio@bakom.admin.ch> wrote:
Dear Jordan
I wonder whether it is possible to objectively separate PDPs from other bylaw changes. How and who would be the arbiter in these cases?
PDPs may result in structural changes, which may affect other parts of the community. By giving the starting organization a veto over the exercise of the community power, aren’t we privileging that organization?
As far as I know when a PDP resulting in a bylaws change comes to the Board, there is no priviledged position for the Board members coming from the starting organization. The Board just decides with the well-being of the organization and the global public interest in their mind, right?
Just some thoughts and sorry for chiming in so belatedly, but as you know there are many parallel tracks ongoing
Regards
Jorge
*Von:* accountability-cross-community-bounces@icann.org [mailto: accountability-cross-community-bounces@icann.org] *Im Auftrag von *Jordan Carter *Gesendet:* Dienstag, 17. November 2015 08:32 *An:* Accountability Cross Community < accountability-cross-community@icann.org> *Betreff:* [CCWG-ACCT] PDP interaction with bylaws veto - proposed approach
*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
Web: www.internetnz.nz
*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
Well I’m not very sure either, but I imagine that a PDP on new gTLD could potentially impact significantly other SO/AC than the GNSO for instance. Regards Jorge Von: Greg Shatan [mailto:gregshatanipc@gmail.com] Gesendet: Mittwoch, 18. November 2015 15:13 An: Cancio Jorge BAKOM <Jorge.Cancio@bakom.admin.ch> Cc: Jordan Carter <jordan@internetnz.net.nz>; accountability-cross-community@icann.org Betreff: Re: [CCWG-ACCT] PDP interaction with bylaws veto - proposed approach Jorge, I'm not sure I agree with your statement: "PDPs may result in structural changes, which may affect other parts of the community." There are limitations on what PDPs can consider and achieve, and I'm struggling to think of a way that a PDP could result in structural changes. I can't think of a past PDP that has had such a result. I'm primarily familiar with GNSO PDPs, but I expect the same is true of ccNSO PDPs. If this is to be a basis for objection to Jordan's proposal, I think this would need to be a significant possibility. If you could "put some meat on the bones,' so to speak, that would be helpful in understanding your concern. Thanks! Greg On Wed, Nov 18, 2015 at 5:35 AM, <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>> wrote: Dear Jordan I wonder whether it is possible to objectively separate PDPs from other bylaw changes. How and who would be the arbiter in these cases? PDPs may result in structural changes, which may affect other parts of the community. By giving the starting organization a veto over the exercise of the community power, aren’t we privileging that organization? As far as I know when a PDP resulting in a bylaws change comes to the Board, there is no priviledged position for the Board members coming from the starting organization. The Board just decides with the well-being of the organization and the global public interest in their mind, right? Just some thoughts and sorry for chiming in so belatedly, but as you know there are many parallel tracks ongoing Regards Jorge Von: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>] Im Auftrag von Jordan Carter Gesendet: Dienstag, 17. November 2015 08:32 An: Accountability Cross Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Betreff: [CCWG-ACCT] PDP interaction with bylaws veto - proposed approach 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<tel:%2B64-4-495-2118> (office) | +64-21-442-649<tel:%2B64-21-442-649> (mob) Email: jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Skype: jordancarter Web: www.internetnz.nz<http://www.internetnz.nz/> A better world through a better Internet [https://mail.google.com/mail/u/0/photos/me?at=AF6bupOucTjwCs9wZukdGAKPf5VnWt...] -- Jordan Carter Chief Executive, InternetNZ +64-21-442-649<tel:%2B64-21-442-649> | jordan@internetnz.net.nz<mailto:jordan@internetnz.net.nz> Sent on the run, apologies for brevity _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
participants (6)
-
Dr Eberhard W Lisse -
Greg Shatan -
Jordan Carter -
Jorge.Cancio＠bakom.admin.ch -
Nigel Roberts -
Seun Ojedeji