PDP - Voting and Implementation - Updated 9 February 2010

PDP - Voting and Implementation - Updated 9 February 2010.doc

PDP-WT               Review of the Policy Development Process

Stage IV               Voting and Implementation                                                                                                                                                                         9 February 2010

 

In order to facilitate the discussion, this document aims to bring together the PDP Work Plan notes, questions from the staff paper and issues and ideas raised in previous debates. Please review this document to see if there is anything missing, especially in the concerns / questions section. Feel free to share your ideas and suggestions on the mailing list. The hope is that if the group can reach consensus on how these concerns / questions should be addressed, it will be easier to work towards a proposed solution.

 

Issue to be addressed

Current Practice / Rules

Concerns / Questions

Notes from WT calls / How to address concerns - questions

1. Working Group Recommendations

From the ICANN by-laws:

10. Council Deliberations

a. Upon receipt of a Final Report, whether as the result of a task force or otherwise, the Council chair will (i) distribute the Final Report to all Council members; and (ii) call for a Council meeting within ten (10) calendar days thereafter. The Council may commence its deliberation on the issue prior to the formal meeting, including via in-person meetings, conference calls, e-mail discussions or any other means the Council may choose. The deliberation process shall culminate in a formal Council meeting either in person or via teleconference, wherein the Council will work towards achieving a Successful GNSO Vote to present to the Board.

b. The Council may, if it so chooses, solicit the opinions of outside advisors at its final meeting. The opinions of these advisors, if relied upon by the Council, shall be (i) embodied in the Council's report to the Board, (ii) specifically identified as coming from an outside advisor; and (iii) be accompanied by a detailed statement of the advisor's (x) qualifications and relevant experience; and (y) potential conflicts of interest .

When a WG makes a recommendation, what is the role of the GNSO?

1a.  Does the GNSO have the discretion to pick and choose which recommendations, if any, to approve or is the GNSO required to adopt the entire recommendation or can it approve part of it?

1b. If the GNSO Council disagrees with a recommendation, should it have the right to modify or change individual recommendations?

1c.  If it does have the right to change recommendations or to pick and choose which recommendations to adopt, then what procedure should be followed? (ie., does it need to go back to the WG and/or out for public comment).

1d. Alternatively, should the GNSO Council have the option to send recommendations back to the WG if it feels further work needs to be undertaken?

1e. How should the GNSO Council deal with recommendations that are not consensus recommendations but that have strong support, majority support, etc.?

1f. What happens if the GNSO Council rejects the recommendations of a WG? Should the PDP be redone or has the process finished?

1g. Should there be an opportunity for the WG to meet with the Council to present its report and allow for a dialogue and a Q&A.

1h. What are the time periods in which the Council needs to complete its work?

1a. The question was raised whether there would be a risk to break interdependencies between recommendations if the Council can pick and choose? It was noted that it is therefore important for the WG to provide guidance to the Council if this is the case in its report, otherwise the Council should assume that all recommendations can be independently adopted.

It was noted that a minor change to the recommendations might not be a valid reason to reject all recommendations as a whole.

The question was raised whether all recommendations would have the same value, i.e. if a recommendation does not have consensus but strong support, should it have the same weight as a consensus recommendation? (Question sent to WG-WT) 

It was pointed out that the Council will need to make decisions as some point e.g. in cases where there is no consensus but strong support.

The WT discussed that currently there is no requirement for a WG to have representation from every constituency / stakeholder group or at least a balanced representation, which might result in recommendations that are not balanced or representative. (Question sent to WG-WT)

The WT discussed how to unite and balance the objective of the Council as a manager instead of a policy-maker with the likely desire of the Council to adapt or adjust recommendations.

The WT discussed whether the Council should have the following options at its disposal;

        Yes, accept all recommendations

        No, reject all recommendations

        Send it back to the WG or other WG / expert / process with concrete recommendations on how to change / improve the recommendations (e.g. obtain input from groups that were not represented in the WG)

Most agreed that the Council should not be able to rewrite the WG recommendations on its own. If it would want to make changes, it should ask the WG to do so or form a drafting team to look at these changes, providing clear instructions.

It was noted that in its role as manager of the policy process, it would be for the Council to come of with a process to ensure broader consensus or input, but it should not do the work itself.

1g. Most agreed that there should be an opportunity for the WG to meet with the Council, but recognized that the organisation of this logistically, especially from a time perspective, might be complicated. It was suggested that the Council should have the opportunity to present questions to the WG before taking a decision on the recommendations.

1h. It was suggested that the same timeframe should be adopted as proposed for the decision on whether or not to initiate a PDP: the Council shall consider whether to adopt the recommendations or not at the meeting following receipt of Final Report; provided that receipt of the Final Report is at least seven (7) days prior to the meeting. In the event that receipt of the Final Report is less than seven (7) days prior to the meeting, then the Council shall consider the Final Report at the following meeting. At the written request of any Stakeholder Group or constituency, for any reason,

consideration of the Final Report may be postponed by no more than one (1) meeting, provided that such Stakeholder Group or constituency details the precise rationale for such

a postponement.

2. Public comments

No current practice or requirements

2a. Should there be a round of public comments on the final report prior to Council consideration?

2b. If yes to question 2a, how should these comments be incorporated?

2c. Should there be an opportunity for third parties to provide the Council with an opinion or view before it takes a decision on the recommendations?

2a. WG may recommend whether a public comment is needed, for example if the Final Report is substantially different from the Initial Report. It was noted that the WG could also run such a public comment period at its own initiative.

2b. It was suggested that the WG could be responsible for incorporating the comments before presenting the Final Report to the Council. Others suggested that staff could provide a summary and analysis of the public comments to the Council for its consideration in combination with the Final Report. The question was raised how proposals for substantive changes should be dealt with – should these be given back to the WG to consider or should a new WG be tasked to review those changes.

2c. It was noted that there was already an explicit invitation to other SO/ACs to comment / provide input in the earlier stages of the PDP. But how about third parties that are not SO/ACs? It was noted that there was also an opportunity to provide input during the public comment period that is held before the Board considers the GNSO recommendations.

3. Delivery of recommendations to the Board

From the ICANN by-laws:

11. Council Report to the Board

The Staff Manager will be present at the final meeting of the Council, and will have five (5) calendar days after the meeting to incorporate the views of the Council into a report to be submitted to the Board (the "Board Report"). The Board Report must contain at least the following:

a. A clear statement of any Successful GNSO Vote recommendation of the Council;

b. If a Successful GNSO Vote was not reached, a clear statement of all positions held by Council members. Each statement should clearly indicate (i) the reasons underlying each position and (ii) the constituency(ies) or Stakeholder Group(s) that held the position;

c. An analysis of how the issue would affect each constituency or Stakeholder Group, including any financial impact on the constituency or Stakeholder Group;

d. An analysis of the period of time that would likely be necessary to implement the policy;

e. The advice of any outside advisors relied upon, which should be accompanied by a detailed statement of the advisor's (i) qualifications and relevant experience; and (ii) potential conflicts of interest;

f. The Final Report submitted to the Council; and

g. A copy of the minutes of the Council deliberation on the policy issue, including the all opinions expressed during such deliberation, accompanied by a description of who expressed such opinions.

3a. Are the requirements in the current Bylaws ones that should be maintained?  If not, what changes should be made?

3b. Should the Council provide input to the Board Report? If yes, how / what?

 

3a. It was pointed out that in addition to the Council Report to the board, as prescribed in the by-laws, there is also a Staff report to the Board. On the request of the board, ICANN Staff provides in this report a summary of relevant information, including ICANN community positions and concerns, as well as its advice to the Board. The Board has deemed this staff report to the Board to be confidential. Most members of the WT agreed that the staff report should be made public, apart from any potential confidential/sensitive information that it might contain. Most agreed that staff should be able to provide advice to the board, but this should be part of the Council Report to the Board and should be made public. Recognizing that the staff report to the board is currently not a by-law or PDP-WT issue per se (it is not specific to a PDP), it was proposed to send a letter from the Work Team to the ICANN General Counsel (and possibly the Board Governance Committee) asking that they attend one of our next calls to discuss our issues with them and to possibly request access to some of the past confidential reports - to make recommendations on the use of these reports (if any) in the future.

In addition, the importance and need for enhanced dialogue between the Board and the GNSO Council before a Board vote was noted, which currently often seems to be lacking. The WT also discussed when/how concerns from staff should or could be raised, and a suggestion was made to develop a process in order to allow staff to take off its support hat and be able to provide its opinion.

Some suggested that the Council Report to the Board should also include an executive summary, which would highlight the main conclusions in order to facilitate review of the report by board members.

A suggestion was made to ask the ICANN Board / Board Participation Committee what information they would like to receive and in which format to facilitate their decision-making process.

3b. The WT discussed whether the Council should produce this report as manager of the process. Some noted that measuring the financial impact should go beyond the impact on constituencies or stakeholder groups and should include other groups such as users or broader community. Some pointed out that the WG report to the Council should already discuss the potential impact of the proposed recommendations. The Council Report to the Board could then summarize this information and reference it.

4. Agreement of the Council

From the ICANN by-laws:

12. Agreement of the Council

A. Successful GNSO Vote of the Council members will be deemed to reflect the view of the Council, and may be conveyed to the Board as the Council's recommendation. In the event a GNSO Supermajority Vote is not achieved, approval of the recommendations contained in the Final Report requires a majority of both houses and further requires that one representative of at least 3 of the 4 Stakeholder Groups supports the recommendations. Abstentions shall not be permitted; thus all Council members must cast a vote unless they identify a financial interest in the outcome of the policy issue. Notwithstanding the foregoing, as set forth above, all viewpoints expressed by Council members during the PDP must be included in the Board Report.

4 a. Are these provisions still relevant or are any updates required?

4 a. In relation to abstentions, the OSC Operations WT is currently reviewing the issue of abstentions and is expected to put forward a proposal for review shortly.

5. Board vote

From the ICANN by-laws:

13. Board Vote

a. The Board will meet to discuss the GNSO Council recommendation as soon as feasible after receipt of the Board Report from the Staff Manager.

b. In the event that the Council reached a GNSO Supermajority Vote, the Board shall adopt the policy according to the GNSO Supermajority Vote recommendation unless by a vote of more than sixty-six (66%) percent of the Board determines that such policy is not in the best interests of the ICANN community or ICANN.

c. In the event that the Board determines not to act in accordance with the GNSO Supermajority Vote recommendation, the Board shall (i) articulate the reasons for its determination in a report to the Council (the "Board Statement"); and (ii) submit the Board Statement to the Council.

d. The Council shall review the Board Statement for discussion with the Board within twenty (20) calendar days after the Council's receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board will discuss the Board Statement.

e. At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation, and communicate that conclusion (the "Supplemental Recommendation") to the Board, including an explanation for its current recommendation. In the event that the Council is able to reach a GNSO Supermajority Vote on the Supplemental Recommendation, the Board shall adopt the recommendation unless more than sixty-six (66%) percent of the Board determines that such policy is not in the interests of the ICANN community or ICANN.

f. In any case in which the Council is not able to reach GNSO Supermajority vote, a majority vote of the Board will be sufficient to act.

g. When a final decision on a GNSO Council Recommendation or Supplemental Recommendation is timely, the Board shall take a preliminary vote and, where practicable, will publish a tentative decision that allows for a ten (10) day period of public comment prior to a final decision by the Board.

5a. Are these provisions still relevant and up to date?

5b. There is a current practice by the board to have a public comment period before taking a decision. Should this be incorporated in the by-laws?

5c. Should the Board have the discretion to pick and choose which recommendations, if any, to approve or is the Board required to adopt the entire recommendation or can it approve part of it?

5d. Should there be additional means / procedures for Board / GNSO interaction which might be useful to resolve any issues that may exist either within the Council or between the Council and the Board?

5e.  Currently, there is “staff report” that is sent to the Board on each issues to outline the substance and process.  Should this practice continue or should the WG or the Council have the right to draft/review the report sent to the Board? Should the part that goes to the Board just be the executive summary of the Final Report?

5f. What does ‘sufficient to act’ mean (see provision 13f)?

5b. Some suggested that there should be at least one public comment period following adoption of the final report by the GNSO Council and before the Board takes a vote – whether such a public comment period should be held by the Board or GNSO Council should not matter. Some noted that it should be left to the discretion of the Board to hold a public comment period or not, but that the Board should be encouraged to take into account whether any substantive changes had been made to the document / recommendations following the last public comment period, when making a decision. In addition, it was suggested that the Board should take into account when deciding on whether to have a public comment period or not the level of participation in the process from others in the community, also from outside the GNSO.

5c. Most agreed that this should be left to the discretion of the Board as long as dependencies between recommendations would be maintained. Some argued that a similar approach should be followed as suggested for the Council in issue 1. The question was raised ‘what should happen with recommendations that are not adopted’. Should these be sent back with Board instructions to be reviewed / addressed by the GNSO and/or WG? It was also noted that the Board should be able to ask questions or send back clarifying questions to the GNSO, even after adoption.

5d. Most agreed that more dialogue is needed between the Board and the GNSO Council. Should the Council or someone designated by the GNSO Council meet with the Board to present the recommendations. It was also noted that such a meeting would be an opportunity for the GNSO Council to present its report to the board.

5e. This has been addressed in issue 4.

5f. The question was raised what ‘sufficient to act’ means in provision 13f of Annex A. Can recommendations that are ‘acted upon’ instead of adopted by the Board under this provision still be considered ‘consensus policy’? Some suggested that it could be considered consensus policy as the act was to conclude a PDP which is the process that defines / develops consensus policies, others disagreed with this interpretation. It was agreed that further discussion might be required to address this issue.

6. Implementation

From the ICANN by-laws:

14. Implementation of the Policy

Upon a final decision of the Board, the Board shall, as appropriate, give authorization or direction to the ICANN staff to take all necessary steps to implement the policy.

 

6a. Should the role of ICANN staff in developing the implementation of the approved policy be further defined? If yes, how?

6b. Should there be a mechanism to verify / check the proposed implementation plan with the GNSO Council and/or WG, in addition to the regular public comment period on the implementation plan?

6c. Should there be a procedure for the GNSO Council to challenge / object to certain parts or the whole implementation plan if it is deemed not in line with the proposed recommendations? If yes, how should such a procedure look?

6d. Can the implementation process change recommendations of the GNSO i.e. if deemed not implementable? If yes, what kind of procedure should accompany such changes?

6a. Most agreed that this should be clarified. Some suggested that a mechanism should be developed by which, if a number of different implementation options are identified, staff needs to come back to the GNSO Council / WG for a review or assessment to determine whether it is consistent with the policy recommendations or whether additional policy development work needs to be undertaken to provide further guidance / clarity. It was pointed out that there are different views as where the dividing line is between policy and implementation. It was noted that often unanticipated questions / issues arise during the implementation phase – in those cases it would be important for staff to reaffirm that the proposed implementation is in line with the policy recommendations. At the same time, it was suggested that staff shouldn’t be unnecessarily constrained in developing the implementation plans.

The question was raised who staff should involve when questions arise during the implementation process? Most agreed that as the manager of the process, the GNSO Council should be responsible for addressing the issue either by reviewing it itself or delegating it to the WG or other ad-hoc group. In such cases, the GNSO Council should decide whether the proposed implementation plans are in line with the policy recommendations or whether further work needs to be undertaken by the WG or other entity. It was suggested that at the end of the process, the WG would be asked to designate a few individuals to remain as an ‘implementation review team’ that could be consulted or tasked by the GNSO Council should implementation questions arise.

6c. The WT debated whether a process was needed, and if so, how to make sure it would not be too prescriptive but also not too vague. All agreed that any questions in relation to policy would need to go back to the GNSO Council or WG Implementation Review Team for feedback. The WT agreed that an implementation review could be initiated by ICANN staff, Board or GNSO Council.

6d. All agreed that if there are policy issues or significant changes to the policy recommendations, it would need to go back to the GNSO Council or WG Implementation Review Team.

It was pointed out that in certain instances it might be a conscious decision of a WG or the GNSO Council to leave certain details to be worked out as part of the implementation process.

The WT also noted that during such a review of potential policy issues, the implementation might need to stop or not, depending on the circumstances. The WT agreed that it would not be possible to create one blanket rule for these kinds of circumstances and that each situation would need to be assessed on its own merits.

7. Timing (Overarching Issue)

a. Upon receipt of a Final Report, whether as the result of a task force or otherwise, the Council chair will (i) distribute the Final Report to all Council members; and (ii) call for a Council meeting within ten (10) calendar days thereafter.

[…]

The Staff Manager will be present at the final meeting of the Council, and will have five (5) calendar days after the meeting to incorporate the views of the Council into a report to be submitted to the Board (the "Board Report").

[…]

d. The Council shall review the Board Statement for discussion with the Board within twenty (20) calendar days after the Council's receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board will discuss the Board Statement.

[…]

a GNSO Council Recommendation or Supplemental Recommendation is timely, the Board shall take a preliminary vote and, where practicable, will publish a tentative decision that allows for a ten (10) day period of public comment prior to a final decision by the Board.

7a. What are more realistic timelines in relation to voting and implementation provisions?

7a. To be discussed as part of ‘overarching’ issues

 

  • No labels