*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