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

[Greg Shatan]

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 at 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 at icann.org [mailto:
> accountability-cross-community-bounces at icann.org] *Im Auftrag von *Jordan
> Carter
> *Gesendet:* Dienstag, 17. November 2015 08:32
> *An:* Accountability Cross Community <
> accountability-cross-community at 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 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/f9b4770d/attachment-0001.html>