Policy Development Process Work Team

Initial Report & Draft Recommendations

STATUS OF THIS DOCUMENT

This document represents some of the initial thinking and recommendations of the members of the Policy Development Process Work Team concerning the development of, and transition to, a new policy development process . A Final Report will be prepared following public comment on this subject and shall be referred to the Policy Process Steering Committee for review and ultimately to the GNSO Council for approval.

Table of Contents

1 Executive Summary................................................................................................. 3

2 Approach taken..................................................................................................... 25

3 Stage I - Planning and Request for an Issues Report................................ 27

4 Stage II – GNSO Council Review of the Issues Report and Initiation of the Policy Development Process................................................................................................ 49

5 Stage III – Working Group................................................................................... 70

6 Stage IV – Voting and Implementation.......................................................... 92

7 Stage V – Policy Effectiveness and Compliance......................................... 109

8 Overarching Issues............................................................................................. 115

9 New PDP Flow Chart – Basis for new Annex A........................................... 128

ANNEX I - Background.............................................................................................. 135

ANNEX II - Working Group Charter....................................................................... 137

ANNEX III - The Working Group............................................................................... 139

Annex IV - List of Recommendations................................................................... 140

1 Executive Summary

Introduction

§ The Policy Development Process Work Team (PDP-WT) was tasked by the Policy Process Steering Committee (PPSC) to be ‘responsible for developing a new policy development process that incorporates a working group approach and makes it more effective and responsive to ICANN’s policy development needs’. The primary tasks of the PDP-WT were to develop:

1 Appropriate operating principles, rules and procedures applicable to a new policy development process; and

2 An implementation/transition plan.

§ This Initial Report presents the PDP-WT’s views and draft recommendations in relation to task 1. In spite of the complex nature of the policy development process and the discussions by the members of the PDP-WT, the PDP-WT has been able to make substantial progress but has not yet been able to complete task 2 nor all of the items that are part of task 1. However, in order provide the opportunity for community input on the discussions and draft recommendations to date, the PDP-WT has decided to release this report for community consideration and discussion in time for the ICANN meeting in Brussels. The PDP-WT cautions that this report should still be considered a ‘work in progress’, and as such, may contain a number of inconsistencies or incomplete recommendations.

§ For purposes of its discussions, the PDP-WT agreed to divide the policy development process into the following separate stages and consider each of these stages consecutively:

Stage 1 – Planning and Request for an Issues Report (see section 3)
Stage 2 – GNSO Council Review of the Issues Report and Initiation of the Policy Development Process (see section 4)
Stage 3 – Working Group (see section 5)
Stage 4 – Voting and Implementation (see section 6)
Stage 5 – Policy Effectiveness and Compliance (see section 7)

In addition, a number of overarching issues that are present in multiple stages of the policy development process, including timing, translation, development of definitions, voting thresholds and decision-making methodology, were also discussed following the review of the five different stages (see section 8).

§ Based on these discussions, e-mail and surveys on the subject matter, the PDP-WT has developed a flow chart that attempts to reflect in a visual representation,the main elements of the new proposed PDP, currently found in Annex A to the ICANN Bylaws, , as well as those elements that the PDP envisions would be incorporated into a PDP-specific rules of procedure (see section 9).

§ Hereunder you will find a summary of the draft recommendations of the PDP-WT, which are intended to form the basis for the proposed modifications to Annex A. You are strongly encouraged to review the complete report in order to appreciate the deliberations of the PDP-WT that form the basis for these recommendations.

Disclaimer: All these recommendations are provisional and subject to change following the public comment period and subsequent deliberations of the PDP-WT.

Stage 1 – Planning and Request for an Issues Report

1. Who has the right to initiate a request for an issues report?

Recommendation 1.

§ Although a request for an Issues Report has never been issued directly by the ICANN Board, or any Advisory Committee (other than the At-Large Advisory Committee), the PDP-WT recommends that the current three mechanisms for initiating a request for an Issues Report should be maintained.

Recommendation 2.

§ The current language in Annex A of the by-laws continuous several references to the PDP which over the years have been the source of confusion. It not only refers to the PDP in terms of initiating an issues report, for example, but also in terms of formally establishing Task Forces or working groups. Therefore, the PDP-WT has divided the two concepts (1) Raising an Issue and (2) Initiation of a PDP and has recommended clarification of this language in the Bylaws (see section 3).

2. Procedures for Requesting an Issues Report

2 Approach taken

The PDP WT agreed to divide the policy development process into the following separate stages and consider each of these stages consecutively:

Stage 1 – Planning and Request for an Issues Report
Stage 2 – GNSO Council Review of the Issues Report and Initiation of the Policy Development Process
Stage 3 – Working Group
Stage 4 – Voting and Implementation
Stage 5 – Policy Effectiveness and Compliance

Each of these stages were then broken down into related issues areas that were discussed by the PDP-WT. The following sections provide an overview of these deliberations, including proposed recommendations to address issues identified. To encourage input from the members of the WT, a number of surveys were conducted to solicit feedback. For further details on the surveys and interim notes, please visit the PDP-WT Workspace: https://st.icann.org/icann-ppsc/index.cgi?pdp_team.

In addition, a number of overarching issues were identified which were deemed to have an impact on the overall policy development process or related to various stages of the new PDP and therefore needed to be considered once an initial outline of the new PDP would have been completed. These overarching issues consist of:

Timing
Translation
Development of definitions
Voting thresholds
Decision-making methodology
Transition / Implementation of the new PDP

The PDP-WT has not completed its work on all these overarching issues, but has noted in section 8 its initial thoughts on these issues for public input and consideration. It is the intention of the PDP-WT to finalize its recommendations on these issues following the review and analysis of public comments on this initial report.

Based on the discussions and deliberations to date, a flow chart which outlines the main elements of the new Annex A – GNSO Policy Development Process of the ICANN By-Laws can be found in section 9.

In order to encourage input from the ICANN community on the PDP-WTs recommendations and deliberations to date, the PDP-WT has put forward this Initial Report for consideration and public comment. Following review and analysis of the public comments received, the PDP-WT is expected to update, where appropriate, its report and finalize its recommendations for submission to the Policy Process Steering Committee (PPSC).

3 Stage I - Planning and Request for an Issues Report

In discussing this stage, the PDP WT addressed the following general issues:

Who has the right to initiate a request for an issues report?
Procedures for requesting an issues report
Issues Scoping
Creation of the Issues Report
What are the possible end results of a PDP
The role of ICANN staff
Community input / How to incorporate public comments
Role of Workshops / Information Gathering events
Efficiency and flexibility during planning / initiation phase
Economic Impact Analysis
Resources and Prioritization

1. Who has the right to initiate a request for an issues report?

Current By-law Provisions

The current ICANN by-laws provide for three possible mechanisms for the initiation of an “Issues Report”: Board Initiation, GNSO Council Initiation and Advisory Committee Initiation (see ICANN By-Laws). It is worth noting that to date, only the latter two (Council Initiation and Advisory Committee Initiation) have been utilized.

Concerns / Questions

1.a Should other parties be allowed to raise an issue? If so, under which conditions and procedures?

1.b Current language in Annex A of the by-laws refers to the initiation of a PDP twice, first, when an Issues Report is requested (1. Raising an Issue) and again when the Issues Report is complete (3. Initiation of a PDP) . This has proven to be confusing.

PDP WT Response

Although a request for an Issues Report has never been issued directly by the ICANN Board, the WT recommends that the current three mechanisms for initiating a request for an Issues Report should be maintained. The WT discussed the possibility of having additional mechanisms to allow future communities to initiate a request for an Issues Report. These could include groups like the Anti-phishing Working Group, ISOC, members of the public, etc. However, the WT believes that such groups should have access to participate in Stakeholder Groups or an Advisory Committee and if the issue truly merits attention from the GNSO Council, such attention will be received. That said, the WT does believe that for those not familiar or active in the ICANN Process, there should be information available to these individuals and entities on the policy process and how to raise an issue.

1.a Recommendation to adopt same criteria from Current PDP and not expand the list of persons or groups that could “raise an issue.” Consider whether the GNSO and the Advisory Committees should develop and announce a formal mechanism to allow other parties who may or may not be members of a formal constituency, stakeholder group or advisory committee to make suggestions to the GNSO/AC on topics for an issues report

Some entities such as APWG/ISOC might have reason to make suggestions

Concern that might encourage random/unqualified submissions from public that just creates unnecessary, out-of-scope, or duplicative work for Council and the GNSO.

Some stated that it is incumbent on these organizations to raise the issues through their stakeholder groups or constituencies, and for constituencies to inform their members of this procedure.

1.b Most agreed that this needed to be clarified.

Recommendated Changes

Recommendation 1.

§ Although a request for an Issues Report has never been issued directly by the ICANN Board, or any Advisory Committee (other than the At-Large Advisory Committee), the PDP-WT recommends that the current three mechanisms for initiating a request for an Issues Report should be maintained.

Recommendation 2.

§ The current language in Annex A of the by-laws continuous several references to the PDP which over the years have been the source of confusion. It not only refers to the PDP in terms of initiating an issues report, for example, but also in terms of formally establishing Task Forces or working groups. Therefore, the PDP-WT has divided the two concepts (1) Raising an Issue and (2) Initiation of a PDP and has recommended clarification of this language in the Bylaws (see below).

Original Text
ICANN By-Laws

Proposed Text

1. Raising an Issue</Article>

An issue may be raised for consideration as part of the PDP by any of the following:
a. Board Initiation. The Board may initiate the PDP by instructing the GNSO Council ("Council") to begin the process outlined in this Annex.
b. Council Initiation. The GNSO Council may initiate the PDP by a vote of at least twenty-five percent (25%) of the members of the Council of each House or a majority of one House.
c. Advisory Committee Initiation. An Advisory Committee may raise an issue for policy development by action of such committee to commence the PDP, and transmission of that request to the GNSO Council.

An issue may be raised for consideration as part of the PDP by any of the following:
a. Board Initiation. The Board initiate the PDP by instructing the GNSO Council ("Council") to begin the process outlined in this Annex.
b. Council Initiation. The GNSO Council may raise an issue by a vote of at least twenty-five percent (25%) of the members of the Council of each house or a majority of one house
c. Advisory Committee Initiation. An Advisory Committee may raise an issue for policy development by action of such committee to raise an issue, and transmission of that request to the GNSO Council.

Justification

There was broad agreement that the status quo should be maintained with regard to who should be able to raise an issue and that the language should be clarified so that the term “policy development process” or “PDP” refer to the formal process initiated by the GNSO Council after the completion and delivery of an Issues Report to the GNSO Council. The same changes should be made to the GNSO Rules of Procedure.

2. Procedures for Requesting an Issues Report

</Amend>

Current Practice

From the ICANN by-laws:
a. Board Initiation. The Board may initiate the PDP by instructing the GNSO Council ("Council") to begin the process outlined in this Annex.
b. Council Initiation. The GNSO Council may initiate the PDP by a vote of at least twenty-five percent (25%) of the members of the Council present at any meeting in which a motion to initiate the PDP is made. [In the new GNSO structure, the voting threshold is as follows: Create an Issues Report – either greater than 25% vote of both houses or simple majority of one house]

c. Advisory Committee Initiation. An Advisory Committee may raise an issue for policy development by action of such committee to commence the PDP, and transmission of that request to the GNSO Council.

Concerns / Questions

2.a Are the procedures outlined in Annex A of the by-laws still relevant and efficient?

2.b There are no requirements as to what information a request should contain. Would a template be helpful including items such as definition of issue, identification of problems, supporting evidence, why should the issue be considered for policy development? Should use of a template be encouraged or required?

2.c Is requesting an issues report the same as initiating a PDP? If not, should the Board and/or Advisory Committees be allowed to initiate a PDP (without first requesting an issues report)?

2.d Should more details be provided on how an Advisory Committee can request an issues report?

PDP WT Response

2.a Will the ‘members present’ also apply to new voting threshold? This should be clarified in the voting rules. Another option would be to leave it up to each house to define their voting rules. Proposal would be to strike the words of members present. [Will need to be aligned with discussion on this issue in Phase II]

2.b An optional request for an issues report template was discussed which could include different sources of information or background on the issue proposed. Such a template was deemed helpful as long as it would not be an obligation to complete the whole template before a request would be considered.

Could a “Bird of a Feather (“BOF”) approach, like that currently used by the Internet Engineering Task Force (“IETF”) help frame the issue and ensure that sufficient information is available to make an informed decision and facilitate the creation of an issues report? This should be presented to the GNSO Council as an optional tool to assist in the development of an issue and the ultimate Issues Report, but the Work Team did not believe that this should be made a requirement for the requesting of an Issues Report.

Should constituencies have the opportunity to provide their position on the issue and/or provide supporting information? Would these positions be considered when determining whether an issues report becomes or initiates a PDP?

There was agreement that guidelines should be developed that suggest information that could be provided to facilitate the preparatory phase. The contents of these guidelines should be further discussed.

2.c Advisory Committees should be allowed to request an issues report, but they should not be allowed to initiate a PDP without the required Council support for the initiation of a PDP. Currently the GNSO does vote on the initiation of a PDP when an issues report is requested by an advisory committee. The Board can initiate a PDP directly without Council intervention.

Recommendations

See Recommendation 2 above.

Recommendation 3.

§ The PDP-WT recommends the development of a Policy Development Process manual or guidebook, which will constitute an integral part of the GNSO Rules of Procedure, intended to provide guidance and suggestions to the GNSO and ICANN communities on the overall PDP process, including those steps that could assist the community, working group members, and Councillors in gathering evidence and providing sufficient information to facilitate the overall policy development process.

Recommendation 4.

§ The PDP-WT recommends that a ‘request for an issues report’ template should be developed including items such as definition of issue, identification of problems, supporting evidence, and rationale for policy development. Further consideration would need to be given as to whether some of these elements should be required before a request is considered by the GNSO Council. Such a template should become part of the above mentioned Policy Development Process Manual or Guidebook.

3. Issues Scoping

Current rules and practice

No current rules or practice.

Concerns / Questions

3.a In theory, there is currently no limit on the issues that can be raised as there is no requirement for the issue to be ‘within scope’ (i.e. either within the “picket fence” of the gTLD Registry and Registrar agreements or within the parameters of ICANN’s mission as it relates to the GNSO in general). This assessment is carried out as part of the issues report. Should an initial assessment take place when an issue is raised?

3.b Should the requestor identify the desired goal/outcome of a PDP?

3.c What actions are needed in order to ensure a precise and narrow definition of an issue?

3.d Should an initial assessment be foreseen whether GNSO policy development is the appropriate response to the issue raised or whether other alternatives are deemed more efficient to achieve the desired outcome?

PDP WT Response

3.a It was suggested that ICANN staff should be willing to do an initial assessment of scope if requested by the body that is planning to raise an issue. ICANN staff has expressed a concern that assessing whether an issue is in scope may be difficult, but at the very least would require that issues are narrow and defined in order for this determination to be made.

3.b It was suggested that those requesting the issues report should be encouraged to identify potential outcomes, if possible, as long as this would not bias or restrict the Working Group in its activities and recommendations.

3.c Suggestions made include: workshops, templates, birds of a feather, community discussion, option to ask clarifying questions, early and frequent consultation between affected parties, better understanding of appropriate role of ICANN organizations within the ICANN community affected by the issue, require inclusion of supporting information when an issue is raised. A suggestion was made that there should be a mechanism by which if there is not sufficient information available an issue does not pass to the next stage.

3.d Some suggested this could be part of the staff response, if requested, but it should not affect the ability to raise an issue. It was also noted that a policy development process can cover a broad range of issues and have a variety of outcomes.

Recommendations

Recommendation 5.

§ The PDP-WT recommends developing a Policy Development Process Manual or Guidebook, which could be an integral part of the GNSO Rules of Procedure, that provides guidance and suggestions to those parties raising an issue on which steps could be considered helpful in gathering evidence and providing sufficient information to facilitate the overall policy development process.

4. Creation of the Issues Report

Current rules and practices

Within fifteen (15) calendar days after receiving either (i) an instruction from the Board; (ii) a properly supported motion from a Council member; or (iii) a properly supported motion from an Advisory Committee, the Staff Manager will create a report (an "Issue Report"). Each Issue Report shall contain at least the following:

a. The proposed issue raised for consideration;

b. The identity of the party submitting the issue;

c. How that party is affected by the issue;

d. Support for the issue to initiate the PDP;

e. A recommendation from the Staff Manager as to whether the Council should initiate the PDP for this issue (the "Staff Recommendation"). Each Staff Recommendation shall include the opinion of the ICANN General Counsel regarding whether the issue proposed to initiate the PDP is properly within the scope of the ICANN policy process and within the scope of the GNSO. In determining whether the issue is properly within the scope of the ICANN policy process, the General Counsel shall examine whether such issue:
1. is within the scope of ICANN's mission statement;
2. is broadly applicable to multiple situations or organizations;
3. is likely to have lasting value or applicability, albeit with the need for occasional updates;
4. will establish a guide or framework for future decision-making; or
5. implicates or affects an existing ICANN policy

Concerns / Questions

4.a Current requirements for content of an Issues Report are pre-defined in the by-laws. Are they still relevant?

4.b Is an Issues Report still the desired outcome of the planning / initiation phase or would a more robust pre-PDP Preparation Report be more appropriate?

4.c Should, where available, positions of stakeholders be included?

PDP WT Response

The PDP WT discussed and reviewed the IETF’s “Bird of a Feather” (BOF)[1|#_ftn1] concept as a possible precursor to raising an issue and/or the development of an issues report. BOF processes typically focus on garnering support for a specific charter and the specific work items in a charter. The focus of this initial activity is on the issue, not on finding a solution to the issue. In an ICANN context, an initial BOF-like process could also focus on the desired or required policy approach to address the issue.

4.a Some indicated that they felt these requirements were still valid, but these should not unnecessarily limit the content of an Issues Report. Some would prefer to see two documents created by staff, a short initial issues paper and, at the appropriate time, staff-produced recommendations, but they also noted that the content of these documents may call for too precise a level of detail to be specified in the by-laws. Others suggested that a new template could be developed that should be populated with relevant information and a checklist for completion, including a proposed timeline.

4.b A number of suggestions were made such as:

o The use of the following three steps:
1. Light Issues Brief (3 or so pages) that highlights the following:
• the proposed issue raised for consideration
• the identity of the party submitting the issue and the reasons invoked for doing it
• the main dimensions of the issue
2. Recommendation on whether a PDP should be initiated:
• General Counsel comments
• the degree of support for launching a PDP on that issue
• the expected outcome of the PDP (including whether it should be "consensus policy", "general policy" or "recommendations / best practices" for instance)
• the main issues to address in the PDP
3. Issues Report

o The use a Briefing/Scoping White Paper similar to that used by the OECD that provides an executive summary of research, information obtained through educational workshops prior to creating an Issues Report. This early paper could cover a, b and c in the current PDP; Council could then make a “go/no-go decision for more in depth Issues Paper which should be put out for public comment (this includes also d and e from current PDP).

o Third party researchers could be used to gather the appropriate information

§ May delay process of initiating a PDP but may result in a better understanding of the issues and a more efficient use of the PDP process

§ Could be used to educate the GAC/other ACs on topics under consideration

§ After comment period, Council should then make a decision about going into a PDP.

o Some noted that the creation of a drafting team or BOF should be optional and at the Council’s discretion.

o Consider whether there should be a possibility to ask for other policy work other than a PDP

There was, however, overall agreement that a report of some kind, whether called an Issues Report or not, should be the desired outcome of the planning and initiation phase. In addition, there was overall agreement that consideration should be given to the fact that some issues might require more information or more research than others.

4.c Some suggested that opposition should be factored into any decision to proceed with policy work. Others suggested that this should be considered but in a concise manner and with neutral reporting.

Recommendations

Recommendation 6.

§ No changes to the By-laws are recommended in relation to the creation of the Issues Report by the PDP Work Team . The PDP-WT recommends including in the Policy Development Process Manual or Guidebook a recommendation for the entity requesting the issues report to indicate whether there are any specific items they would like to see addressed in the issues report, which could then be taken into consideration by the Council when reviewing the request. In addition, guidance could be provided in the Policy Development Process Manual or Guidebook that the Council and/or Staff could provide advice ahead of a vote on the request for an issues report whether they feel additional research, discussion, or outreach should be conducted as part of the development of the issues report, in order to ensure a balanced and informed Issues Report.

5. What can the end result of a PDP be

Current rules and practices

None

Concerns / Questions

5.a Current perception is that the only outcome of a PDP is a recommendation for policy changes. How should this be addressed?

PDP WT Response

5.a Other outcomes can be recommendations (e.g. for clarification of an existing policy, breaking up work in sub-PDPs, contract changes), best practices, technical specifications, code of conduct, review of an existing policy. A tentative typology of PDP outcomes could be:

- Guidelines/Best practices (non-binding recommendations)

- Consensus Policies (binding provisions within the framework of existing agreements - picket fence - to be implemented by the contracted parties)

- General Decisions (formal enforceable decisions on a specific topic beyond the existing agreements)

- Policy frameworks (general orientations charting the course for a broad range of activities, such as in the introduction of new gTLDs)

The purpose of clarifying such a typology (not limitative and exploratory at that stage) would be to clarify processes and establish some form of hierarchy of norms and rules, currently absent from the exclusively contract-based environment.

Recommendations

Recommendation 7.

§ The PDP-WT recommends better information and communication with Working Group members on the potential outcomes of a policy development process. Contrary to the belief of a number of members of the community, there are more potential outcomes of the PDP process than just the formation of “consensus policies” as defined under the applicable gTLD Registry and Registrar agreements. Acceptable outcomes include the development of best practices, recommendations to other supporting organizations, recommendations for future policy development, etc. This information could be included in the Charter of a Working Group or in the instructions to a WG. It is also an element that should be included in the Policy Development Process Manual or Guidebook.

6. The role of ICANN staff

Current rules and practices

From the ICANN by-laws:
Each Staff Recommendation shall include the opinion of the ICANN General Counsel regarding whether the issue proposed to initiate the PDP is properly within the scope of the ICANN policy process and within the scope of the GNSO. In determining whether the issue is properly within the scope of the ICANN policy process, the General Counsel shall examine whether such issue:
1. is within the scope of ICANN's mission statement;
2. is broadly applicable to multiple situations or organizations;
3. is likely to have lasting value or applicability, albeit with the need for occasional updates;
4. will establish a guide or framework for future decision-making; or
5. implicates or affects an existing ICANN policy.

Questions / Concerns

6.a On paper, the role of ICANN’s General Counsel is limited to providing input for the staff recommendation which is part of the Issues Report. Should other consultations be foreseen e.g. at the request stage?

6.b Should there be a possibility to request a 'second opinion' if there is disagreement with the opinion of the General Counsel's office?

6.c Should the role of ICANN staff in the planning and initiation phase be clarified?

PDP WT Response

6.a The PDP WT discussed who and how the initial determination on GNSO scope should be delivered. Two alternatives were suggested:

1. Policy Staff to solicit input from the Office of the General Counsel and produce for the GNSO the initial determination on whether policy work is within GNSO scope; or
2. Formal Opinion of the Office of the General Counsel on GNSO Scope to be required at the commencement of a PDP inquiry.

It was also proposed that legal input should be solicited later in the PDP when specific policy determinations are to be explored for the purpose of: 1) confirming that the policy work is within GNSO scope and 2) if the policy is expected to be binding on contracted parties, whether such policy can be binding on such parties as a Consensus Policy or through other contract terms.

6.b Some suggested that there is a need to build in a procedure to get a second opinion if the GNSO disagrees with the Staff/OGC opinion on scope, but no further suggestions where provided as to whom could deliver such a second opinion or how such a procedure would work.

6.c Discussions have identified at least four different roles for ICANN Staff:

Expertise (can be technical, legal, economic, etc... and can also make use of external resources such as consultants)
Secretariat (fundamentally a support function, covering both logistics and drafting assistance in a totally neutral manner reflecting faithfully the work of working groups)
Operational / implementation (day-to-day operations in the framework of existing policies and rules)
Gate-keeping / Scoping (internal role of the General Counsel, but possibly distinct, guaranteeing respect of the procedures and competences of the different structures)

It was suggested that the PDP reform could lead to justify corresponding improvements in the structure of the ICANN staff. A clearer distinction by function could also correspond to specific rights and responsibilities, as the neutrality of the staff in decision-shaping was mentioned by some as a concern.

Recommendations

Recommendation 8.

§ The PDP-WT recommends retaining the requirement for obtaining the opinion of the ICANN General Counsel in the Issues Report as whether a proposed PDP is within the scope of the GNSO. Further details regarding the opinion of counsel are expected to be included in the PDP rules of procedure as opposed to the Bylaws.

Recommendation 9.

§ The PDP-WT recommends that additional guidance on the different roles ICANN staff can perform, as outlined in the GNSO Working Group Guidelines, is to be included in the Policy Development Process Manual or Guidebook.

7. Community input / How to incorporate public comments

Current rules and practices

None

Concerns / Questions

7.a Should there be a requirement to obtain public input at the stage of the request?

7.b Should there be a need to build in flexibility for public consultation in the preparation of an issues report there where further information is desirable to complete the report?

7.c Should constituencies be consulted at this stage e.g. their definition of the issue is and if/how it affects them?

7.d How to incorporate community input at the planning / initiation phase?

PDP-WT Response

7.a Some suggested that this could be optional, as a way to gather further input or information if this is deemed lacking. Others suggested that public comments should be invited once the Issues Report has been prepared, but before the GNSO Council decides on the initiation of a PDP. It was also suggested that stakeholders identified in the request for an issues report should be allowed to submit comments.

7.b Some suggested that this should only happen on the request of the Council. Others added that the current timeline for an Issues Report is completely unrealistic; staff must have adequate time to consult with Community experts, advocates and opponents to develop a well-informed and balanced report. It was also suggested that public consultations and/or additional research should be possible in between the initial ‘issue paper’ and the recommendations, depending on the complexity of the topic. Again, it was emphasized that this should happen upon the instructions of the GNSO Council. In addition, it was proposed that community opinion should be sought after the issues report has been released, but before a decision is taken on the initiation of a PDP.

7.c It was suggested that the party raising the issue could elect to do so if desired. Others suggested that with more time, constituencies could contribute to the Issues Report, but this should not be a requirement as it could delay the process. It was also noted that the important aspect is to make sure a diversity of viewpoints is represented in the Issues Report. Others noted that constituencies should be consulted after the publication of the Issues Report.

7.d Some suggested that community input could be incorporated via workshops, birds of a feather or a public comment period and that all relevant information stemming from these activities should be incorporated in the Issues Report. Others suggested that a public consultation following the publication of the Issues Report should be considered to inform the GNSO Council of community views before deciding on the initiation of a PDP. There were also numerous discussions in Sydney about applying a higher degree of organization to comments. This included a way to “sign on” to an existing comment, rather than “spam” the comment forum with duplicate submissions. Did we capture these recommendations?)

Recommendations

Recommendation 10.

§ The PDP-WT recommends the modification of timeframes included in clause 1 – Creation of an Issues Report in Annex A in relation to the development and delivery of an issues report. The following options are being explored:

c) Setting a maximum timeframe (e.g. 30-45 days) in the By-Laws which can be modified on the request of ICANN Staff with the agreement of the GNSO Council or the Issues Report requestor (if requested by an Advisory Committee or the ICANN Board); or

d) Request that ICANN staff provide the GNSO Council with an estimate of time it would take for the ICANN Staff to complete an issues report taking into account the complexity of the issue and the ICANN staff workload.

Recommendation 11.

§ The PDP-WT recommends that that there should be a public comment period that follows the publication of an Issues Report and before the GNSO Council is asked to consider the initiation of a PDP. Such a Public Comments period would, among other things, allow for additional information that may be missing from the Issues Report, or the correction or updating of any information in the Issues Report. In addition, this would allow for the ICANN Community to express their views to the Council on whether to initiate a PDP or not.

8. Role of Workshops / Information Gathering events

Current rules and practices

None

Concerns / Questions

8.a Is there a role for workshops / information gathering events at the planning / initiation phase? If so, how can this be build in?

PDP WT Response

8.a Many agreed that there could be a role for workshops and information gathering events at the planning and initiation stage. Some noted, however, that this should not be a requirement. Others added that it might be more appropriate for such events to take place after the publication of the issues report. Several people expressed concern that such events would have the potential to slow down the overall process as such meetings would likely be organized in conjunction with ICANN meetings.

Recommendations

Recommendation 12.

§ The PDP-WT recognizes the value of workshops on substantive issues prior to the initiation of a PDP. It is therefore recommending that information on the potential role of workshops and information gathering events be provided in the Policy Development Process Manual or Guidebook. In addition, the PDP-WT recommends that the GNSO Council should consider requiring such a workshop during the planning and initiation phase for a specific issue.

9. Efficiency and flexibility during planning / initiation phase

Current rules and practice

From ICANN by-laws:
Within fifteen (15) calendar days after receiving either (i) an instruction from the Board; (ii) a properly supported motion from a Council member; or (iii) a properly supported motion from an Advisory Committee, the Staff Manager will create a report (an "Issue Report")

Concerns / Questions

9.a Current deadline of 15 days after receipt of a request is unworkable. How to build in sufficient flexibility to allow for additional research and consultation when needed, while being able to move forward quickly in those cases where additional work is not deemed necessary? Would a flexible timetable be an option i.e. in the request the submitting party with staff support develops a draft timeline which can consist of a number of phases that are pre-determined with a set timeframe?

9.b What flexibility should be foreseen for additional research or study at the initiation phase?

PDP WT Response

9.a It was suggested that a drafting team that is tasked with developing a charter for a WG should also be in a good position to develop a realistic timeline for delivery of the milestones. Some suggested a maximum deadline of 30 days or 45 days that could be extended but only with the agreement of the requester. Others suggested to include target dates in the by-laws based on the current experience with PDP timelines, but with the flexibility for modification by the GNSO Council if it is deemed necessary to allow for extra time for research or consultation. It as also suggested that guidance could be provided on how much additional time should be needed for certain additional elements such as a workshop or public comment period during the planning and initiation phase. Some noted that this should be left to the Council to decide on a case-by-case basis, with input from Staff as to their current workload and estimate of time to complete each project. Others noted that the timeline should be driven by the complexity of the issue but within a certain date boundary set out. Some suggested that there should be two types of requests, one standard request, which would be queued behind exiting requests / reports, and a second expedited / urgent request which would move up to the queue if it has broad support of multiple SO/ACs and/or the Board or GNSO Council.

9.b Some suggested that flexibility should be retained, but that research or study can occur after the initiation phase. Some indicated that research / study at this stage should be minimized. Others suggested that there should be flexibility at all stages.

Recommendations

See recommendation 11

10. Impact Analyses

Current rules and practices

None

Concerns / Questions

10.a Whether to conduct preliminary economic analysis, such as to evaluate market demands, impact to Community, ICANN staff costs, and other resources needed from ICANN

PDP WT Response

10.a Some wondered whether it would be feasible to do an economic impact analysis at this stage of the process? It might be appropriate for some issues, but not others. Others noted that it might prejudge the outcome. It was noted that an option could be left to leave this to the discretion of the GNSO Council, possibly on the recommendation of ICANN staff, to decide, but that this should not delay the overall process.

Recommendations

Recommendation 13.

§ The PDP-WT recommends that the Policy Development Process Manual or Guidebook describe the option for the GNSO Council to require that an impact analysis be conducted if appropriate or necessary prior to the vote for the initiation of a PDP. Such an impact analysis could include the assessment of the economic impact, the impact on competition, the impact on consumer choice and/or protection, etc.

11. Resources and Prioritization

Current Rules and Practice

None

Concerns / Questions

11.a Should there be a maximum of issues that can be taken into consideration at the same time taking into account ICANN staff time but also volunteer workload?

11.b Should there be a fast-track procedure for ‘emergency’ issues?

PDP WT Response

11.a There was overall agreement that there should be a mechanism for prioritizing and planning PDPs over time. Ideas discussed included: consideration of a similar role / function as the IETF area director; should constituencies be asked to provide names of volunteers for participating in a WG at the time of a vote for the initiation of a PDP; how to deal with issues that are only of interest to one or two constituencies. The group noted that it would be worth checking with the WG-WT whether they have considered these last two ideas in their deliberations. Most agreed that it should be the role of the GNSO Council to prioritize, but no clear solution was proposed as to how to do this.

11.b Some agreed that such a procedure could be developed, but more time would be required in order to do so. Issues to be considered would include how to demonstrate a higher need and how to avoid gaming the system. Some criteria suggested include: the community clearly considers it so and expresses it in an explicit manner; the issue is clearly outlined and the common goal clearly identified (including the expected outcome); the ICANN Board and GNSO Council agree about the urgency.

Recommendations

Recommendation 14.

§ The PDP-WT believes that the GNSO Council should prioritize PDPs and ensure that the resources exist (both staff and volunteer) upon the initiation of a PDP. In light of the upcoming GNSO Council Prioritization activity, the PDP-WT is deferring the specifics of how such prioritization can be achieved pending the outcome of such activity.

Recommendation 15.

§ The PDP-WT is considering the notion of having a fast-track procedure that would allow for a more timely PDP in cases where such urgent action is deemed to be necessary while at the same time ensuring broad participation and avoiding gaming. The PDP-WT hopes to receive further input from the community on which elements such a procedure should contain and how it would work in practice, during the public comment period.

.

4 Stage II – GNSO Council Review of the Issues Report and Initiation of the Policy Development Process

In discussing this stage, the PDP WT addressed the following general issues:

Flexibility when launching a policy development process
Appeals mechanism in case the GNSO votes against initiating a PDP requested by an AC or SO
Application of the Voting thresholds
Charter development
Need for an Expedited procedure in extraordinary circumstances
Advice from other ACs or SOs, and input from the Board
Evaluation of the ICANN Staff costs and resources
Resources available to GNSO to take informed decision
Public Comment Period after the Initiation of a PDP
Clarification of ‘in scope of ICANN policy process or the GNSO’

1. Maintaining flexibility when launching a Policy Development Process

Current By-Law Provisions

The Council shall initiate the PDP as follows:

a) Issue Raised by the Board. If the Board directs the Council to initiate the PDP, then the Council shall meet and do so within fifteen (15) calendar days after receipt of the Issue Report, with no intermediate vote of the Council.

b) Issue Raised by Other than by the Board. If a policy issue is presented to the Council for consideration via an Issue Report, then the Council shall meet within fifteen (15) calendar days after receipt of such Report to vote on whether to initiate the PDP. Such meeting may be convened in any manner deemed appropriate by the Council, including in person, via conference call or via electronic mail.

Concerns / Questions

1.a Within which timeframe should the Council decide whether to initiate a PDP or not? Should the same timeframe apply to an issue raised by the Board?

1.b What other flexibility would be desired when launching a policy development process?

PDP-WT Response

1.a In relation to an issue raised by the Board, the WT discussed that the actual initiation of the PDP in practice is the adoption of the WG charter as there is no vote by the Council in this situation to formally “initiate a PDP.” In other words, currently the Bylaws state that if the Board desires the GNSO to conduct a PDP, then that will happen. It was noted, however, that if the Council must vote to approve a WG charter related to an issue raised by the Board, that this would be one mechanism in which the Council could potentially block the initiation of a PDP if the Council would decide not to adopt the Charter. However, some in the group expressed the belief that this was an appropriate “check and balance” of Board action.

The WT proposes to use the same voting thresholds currently found in the Bylaws with respect to the initiation of a PDP to adopt a WG charter (see also issue 4). In addition, the WT discussed the timeline for the delivery of the charter and consideration by the GNSO Council. Some suggested that the charter should be voted upon on the next meeting after delivery by the drafting team, others pointed out this might be difficult in case the Council discussion would result in changes to the charter or a constituency would like to defer a vote on the charter to be able to discuss it with their respective constituency.

It was suggested, that the requirement could be for the council to ‘take action’ on the initiation of a PDP which could have a number of different meanings (vote, deferral, additional work, etc.). The question was raised whether a specific deadline should be included to ensure that a vote would be taken in a timely manner. A suggestion was made to include a timeframe for decision in the by-laws, but to allow for the Council to decide, following a vote, to defer it to a later date. It was suggested that any such deferral should be accompanied by a reason or explanation for such deferral and the possibility of establishing a maximum number of deferrals. The question was raised how long after a ‘no’ vote on the initiation of a PDP, could the same request be tabled again or would this only be allowed if new information became available? Currently there is no mechanism to appeal a ‘no’ vote and the WT does not recommend that one should be included. The WT, however, does believe that if the Council decides It was also suggested that any ‘no’ vote should be accompanied by the reasons for the ‘no’ vote as currently is the requirement for rejecting the final report of a Working Group.

It was noted that the timeframe should be reviewed in the context of the overall timeline for the policy development process.

As part of the survey undertaken to gather input from the WT members, a number of suggestions were made ranging from a 45 to 90 day timeframe to decide whether to initiate a PDP or not. Some suggested that a timeframe should be given in number of Council meetings (i.e. a decision should be taken at the latest at the second meeting following the receipt of the Issues Report). Many noted that there should be flexibility for the Council to deliberate, especially in relation to complex issues, but it was also noted that there should be transparency and predictability as to when an issue can be expected to be voted upon.

1.b Some suggested that it might be helpful to foresee some flexibility for prioritization and scheduling reasons (e.g. be able to put the initiation of a PDP on hold if there are already too many going on). Other suggestions made include: categorization of reasons for the initiation of a PDP, request for additional data, or emergency procedure. It was noted that any requests for more information or additional time for discussion, should be accompanied by a timeline so that there is a reasonable expectation as to when an issue will be voted upon.

Recommendations

Recommendation 16.

§ The PDP-WT recommends modifying the timeframes included in clause 3 – Initiation of a PDP to reflect current practice and experience. In addition, it proposed to add language to codify the current practice that any Stakeholder Group and/or Constituency can request the deferral of the consideration of an initiation of a PDP for one Council meeting (see below for proposed new language).

Recommendation 17.

§ The PDP-WT recommends that further guidance be included in the Policy Development Process Manual or Guidebook on how to deal with situations where further flexibility is required e.g. additional research, ensuring that the Council provides clear indications on expected timing of next steps.

Original Text
ICANN By-Laws

Proposed Text

3. Initiation of a PDP</Article>

The Council shall initiate the PDP as follows:

a) Issue Raised by the Board. If the Board directs the Council to initiate the PDP, then the Council shall meet and do so within fifteen (15) calendar days after receipt of the Issue Report, with no intermediate vote of the Council.

b) Issue Raised by Other than by the Board. If a policy issue is presented to the Council for consideration via an Issue Report, then the Council shall meet within fifteen (15) calendar days after receipt of such Report to vote on whether to initiate the PDP. Such meeting may be convened in any manner deemed appropriate by the Council, including in person, via conference call or via electronic mail.

The Council shall initiate the PDP as follows:

a) Issue Raised by the Board. If the Board directs the Council to initiate the PDP, then the Council shall meet and do so at the first meeting following receipt of the Issue Report, with no intermediate vote of the Council; provided that such meeting is at least eight (8) calendar days from the date of receipt of the Issues report. If receipt of the Issues Report is received within eight (8) calendar days of a meeting, then the Council shall meet and initiate the PDP at the following meeting.
b) Issue Raised by Other than by the Board. If a policy issue is presented to the Council for consideration via an Issues Report, then the Council shall consider whether to initiate the PDP at the meeting following receipt of such Issues Report; provided that receipt of the Issues Report is at least eight (8) days prior to the meeting. In the event that receipt of the Issues Report is less than eight (8) days prior to the meeting, then the Council shall consider whether to initiate a PDP at the following meeting. At the written request of any Stakeholder Group or constituency, for any reason, consideration of the Issues 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. Report to vote on whether to initiate the PDP. Such meeting may be convened in any manner deemed appropriate by the Council, including in person, via conference call or via electronic mail.

Justification

For section A, instead of ‘the Council shall meet and do so within fifteen (15) calendar days after receipt of the Issue Report’, it might be more realistic to note ‘the Council shall meet and do so at the first meeting following receipt of the Issue Report’.

[Further discussion will be required to come to consensus on what timeline, if any, should be included in the by-laws for section B, as the current deadline of fifteen calendar days after receipt of the Issue Report is not realistic.]

2. Consider an appeals mechanism in case the GNSO votes against initiating a PDP requested by an AC

Current Practice

Currently the Council votes on whether or not to initiate a PDP on an issue raised by an AC. There is no formal appeal mechanism for the AC that initially raised the issue.

Concerns / Questions

2.a Should an appal mechanism be developed in case the GNSO decides not to initiate a PDP on an issue raised by another AC? If yes, how should such an appeal mechanism work?

PDP-WT Response

2.a During its discussions on this issue, the WT did not believe a formal appeals process is needed. The WT noted that any party aggrieved by a decision of the GNSO Council had other mechanisms to vet its complaint and could even ask the ICANN Board to raise the issue. In addition, it was also noted that the thresholds to initiate a PDP are fairly low; thus, failure to convince the GNSO Council to Initiate a PDP was a clear signal that the GNSO was not interested in working on the issue. However, it should be noted that in the survey that was conducted of WT members, 36% of respondents did respond that they would support the development of an appeals mechanism. Specific suggestions on how such an appeal mechanism should work included having discussions with the specific SO or AC that initially raised the decision, requesting a formal reconsideration by the Council or ICANN Board; or an appeal to the ombudsman or committee of the board. Some Members of the WT believe that if the Council does elect to not initiate a PDP, it should provide detailed information to the requestor of the Issue as to why it decided not to move forward with the PDP. This could either serve as guidance on how to revise an Issues Report to re-submit for consideration.

Recommendations

Recommendation 18.

§ The PDP-WT recommends that no special formal appeals mechanism be developed. However, the PDP-WT recommends that the GNSO Council be required to state its reasons for denying to Initiate a PDP after receipt of an Issues Report.

3. Should the approved voting thresholds apply to the entire GNSO Council or just members present (as is current practice)?

Current By-Law Provisions

Vote of the Council. A vote of more than 33% of the Council members of each House or more than 66% vote of one House in favor of initiating the PDP within scope will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a GSNO Super Majority Vote as set forth in Article X, Section 3, paragraph 9(c) in favor of initiating the PDP will be required to initiate the PDP.

Concerns / Questions

3.a What would be the advantages and/or downsides of changing the voting thresholds to apply to the entire GNSO Council and not only members present?

PDP-WT Response

3.a As it is expected that a recommendation for absentee voting / ballot will be included in the GNSO Council operating rules, this question is no longer valid as all Councilors will have the opportunity to vote whether they are present or not at the meeting. It should be noted though, that a quorum is required at the start of a meeting, before a vote can be initiated to ensure that sufficient Councilors are present to discuss an issue and vote on it.

Recommendations

§ As it is expected that a recommendation for absentee voting / ballot will be included in the GNSO Council operating rules, the PDP-WT considers this question no longer valid as all Councilors will have the opportunity to vote whether they are present or not at the meeting, therefore no recommendation is made in relation to this issue.

4. Where in the process is chartering done?

Current By-Law Provisions

b. Task Force Charter or Terms of Reference. The Council, with the assistance of the Staff Manager, shall develop a charter or terms of reference for the task force (the "Charter") within ten (10) calendar days after initiation of the PDP. Such Charter will include:

1. the issue to be addressed by the task force, as such issue was articulated for the vote before the Council that commenced the PDP;

2. the specific timeline that the task force must adhere to, as set forth below, unless the Board determines that there is a compelling reason to extend the timeline; and

3. any specific instructions from the Council for the task force, including whether or not the task force should solicit the advice of outside advisors on the issue.

Concerns / Questions

4.a At what point in the process should the charter be developed? And by whom?

4.b Are the elements outlined in the ICANN by-laws relating to the Charter still relevant? If not, what other elements should be added or changed?

PDP-WT Response

4.a The WT discussed the current practice related to questions such as who serves on charter committees, what is the expected timeline for developing a charter, who is responsible for the initial draft of the charter, how is the charter approved by the Council and who is tasked with renegotiating the charter.

The WT agreed that this issue should be dealt with in the GNSO Council operating rules as opposed to the Bylaws. In addition, the WT recognized that responsibility for the drafting of a Charter should not rest with ICANN staff, but rather with those interested in the particular issue(s) raised. ICANN staff should make itself available to participate in the process of the charter development. It was noted that the Working Group Work Team (WG-WT) is in the process of developing a template for this purpose, with predetermined information to be completed. The WT supported the current informal process of having the Council solicit volunteers to form a drafting committee to develop a charter. The Council should encourage participation from each constituency/Stakeholder Group, but such drafting teams should be open and not comprised solely of GNSO Council members (although they would be free to volunteer). The WT supported the practice of appointing a Council liaison to oversee the process and to serve as the initial chair of the drafting committee until such time that a chair can be elected by the drafting committee. In any event, the role of the Council liaison shall be to oversee the drafting team process and to report back to the Council on the drafting team’s progress, timeline and any issues encountered.

The WT agreed that any changes to the charter requested by a PDP Working Group following its adoption by the Council, should be communicated by the Council Liaison to the Council. The WT agreed that one of the first items for a formal WG to consider is evaluating its charter and seeking any clarification or revisions.

The WT supports the current practice that an initial charter must be approved before the formation of a Working Group. In addition, the WT believes that the same voting thresholds for approving the initiation of a PDP should be used to approve a WG charter. This means that to approve a charter for a WG with respect to an “in scope” PDP, it would also require either a 33% vote of both houses or more than 66% vote of one house. Alternatively, to initiate the charter for a PDP ‘not within scope’ it requires more than 75% of one house and a majority of the other house. The WT did consider the alternative, namely requiring a majority of both houses to approve the charter, but it was thought that having a higher threshold to approve the charter could result in the approval of creating a working group, but failure to ever approve a charter (which would hold up the process) and could lead to a gaming of the process by those not initially supporting the Initiation of the PDP. For example, if there was a PDP in scope that the council voted to initiate with more than 66% of one house, the other house could effectively hold up all of the work of the working group by never voting in favor of a charter. The WT also discussed potentially having a default rule of a majority vote of both houses to approve any changes or modifications to the charter, but no agreement was reached yet.

The WT also noted that it was important that a charter not restrict potential outcomes of a PDP, examples of potential outcomes could be provided, but these should not limit the discussions of the WG. In other words, the charter should not state that the output of the group is to require contracted parties to do X, Y or Z, as an appropriate outcome may be a best practices or voluntary approach as opposed to a “consensus policy” as defined in the registry and/or registrar agreements.

In the survey undertaken to gather input from the WT members, one person expressed support for developing the charter prior to the launch of a PDP and make it part of the motion on the initiation of a PDP, but this was not the general opinion of the WT.

4.b A majority of respondents to the survey felt that the elements outlined in the ICANN by-laws related to the Charter are still relevant (64% - yes, 27% - no strong view, 9% - no). The ‘no’ response seemed to be directly related to the timeframe proposed for adoption of the charter.

Recommendations

Recommendation 19.

§ The PDP-WT recommends to update clause 7 of Annex A of the ICANN by-laws to reflect that a charter is required for Working Groups and to include the voting threshold that should apply to the adoption of the working group charter which is identical to the one that applies to the initiation of the PDP (see below for proposed new language).

Recommendation 20.

§ The PDP-WT recommends to working with the WG-WT/PPSC to provide input for the GNSO Working Group Guidelines section or annex that will be dedicated to a PDP WG concerning best practices for developing the charter for a PDP WG.

Original Text
ICANN By-Laws

Proposed Text

7. Taskforces (Working Groups)</Article>

b. Task Force Charter or Terms of Reference. The Council, with the assistance of the Staff Manager, shall develop a charter or terms of reference for the task force (the "Charter") within ten (10) calendar days after initiation of the PDP. Such Charter will include:

1. the issue to be addressed by the task force, as such issue was articulated for the vote before the Council that commenced the PDP;
2. the specific timeline that the task force must adhere to, as set forth below, unless the Board determines that there is a compelling reason to extend the timeline; and
3. any specific instructions from the Council for the task force, including whether or not the task force should solicit the advice of outside advisors on the issue.

b. Working Group Charter or Terms of Reference. The Council or a drafting team, with the assistance of the Staff Manager, shall develop a charter or terms of reference for the working group (the "Charter") within a reasonable period after the Initiation of a PDP within the time frame set forth by the Council in accordance with its operating procedures. Such Charter will include, at a minimum:
1. the issue to be addressed by the working group, as such issue was articulated for the vote before the Council that commenced the PDP;
2. the specific timeline that the working group should adhere to, as set forth below, unless the Board determines that there is a compelling reason to extend the timeline; and
3. any specific instructions from the Council for the working group, including whether or not the working group should solicit the advice of outside advisors on the issue.

The Council shall decide on the adoption of the Working Group Charter using the same voting thresholds as were applicable to the original initiation of the PDP.

5. Should expedited procedures be available in case of urgency?

Current practice

There are no provisions in the ICANN by-laws regarding expedited policy development procedures, but the Registrar Accreditation Agreement as well as each of the current registry agreements do allow for the establishment of a temporary policy by the Board if this policy is deemed necessary to maintain the stability of the Internet: ‘A specification or policy established by the ICANN Board of Directors on a temporary basis, without a prior recommendation by the council of an ICANN Supporting Organization, shall also be considered to be a Consensus Policy if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, so long as the Board reasonably determines that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the operational stability of Registrar Services, Registry Services, the DNS, or the Internet, and that the proposed specification or policy is as narrowly tailored as feasible to achieve those objectives’.

Concerns / Questions

5.a Should an expedited procedure be developed for issues deemed urgent? If yes, how should such a procedure look and who should make the determination whether an issue is ‘urgent’?

PDP-WT Response

5.a There is no consensus within the WT that expedited procedures can be developed that will both ensure an informed policy development process and provide the appropriate procedural safeguards. Some proposed that in order to have an expedited process, higher voting thresholds, e.g. supermajority would be required. Some questioned whether an emergency procedure would impede on the bottom up process. It was suggested that an emergency procedure could follow the model the board has at its disposure to impose a certain measure for a limited amount of time following which it would need to be confirmed / adapted through a proper policy development process in order to stay in place. The question was asked how to deal with issues that would go through an expedited process that would invalidate or make other ongoing policy work obsolete. In addition, it was noted that consideration should be given to how emergency issues might be incorporated into already ongoing PDPs.

The question was then asked whether the board should have increased powers in case of a ‘GNSO emergency’?

Some suggested that an emergency procedure could be put in place that mirrored the full policy development process, but had shorter deadlines. Others pointed out that perhaps certain elements of the policy process could be removed in exigent circumstances. Those circumstances could include an immediate likelihood of harm.

It was proposed that an ‘emergency order’ could be considered in cases where there is evidence of imminent harm, following which a normal PDP procedure would need to be followed to confirm or adapt the emergency order. It was also suggested that there should be a built-in commitment for a sunset timeframe i.e. if you were to execute on an expedited issue A, you would also simultaneously launch a PDP on that issue that would determine whether or not that emergency action was warranted or not.

In response to the WT survey, 55% of respondents supported the development of an expedited procedure, 27% had no strong view either way, 9% did not support the development of an expedited procedure and 9% had mixed feelings on the issue. On the question of who should make the determination whether an issue is urgent, several noted that this should be the responsibility of the GNSO Council, possibly in co-ordination with other SOs/ACs and ICANN staff. It was suggested that in case it was an issue initiated by the Board, the Board could specify in its request that it was deemed a matter of urgency. It was suggested that higher voting thresholds should apply to such a process and consideration could be given to eliminating or running in parallel certain parts of the PDP process in order to reduce the overall timeline. Most agreed that further discussion would be required to flesh out such a process and determine which, if any, changes to the by-laws should be proposed.

Recommendations

See recommendation 15

6. How to involve advice from other ACs or SOs, and obtain consistent input from the Board?

Current practice

No current practice of soliciting feedback from other ACs or SOs apart from gathering such information as part of the drafting of the Issue Report e.g. SSAC advisories.

Concerns / Questions

6.a Should ACs, SOs and the Board be invited to share their view on whether the GNSO Council should initiate a PDP or not? If yes, how should these views be presented to and evaluated by the GNSO Council?

PDP-WT response

6.a The WT is of the opinion that as a courtesy to other ACs and SOs, the Issues Report, once finalized, but prior to the work of a WG should circulate the Issues Report to all ACs / SOs with an express invitation to comment on any issues with the Initiation of a PDP. It was noted, however, that sufficient time should be allotted for ACs/SOs to provide feedback, while at the same time not unnecessarily delaying the process. The suggestion was made that such feedback could also be obtained as part of a workshop or webinar on the Issues Report, or a public comment period on the Issues Report. In addition, an AC or SO might decide to adopt a resolution on the issue.

Recommendations

Recommendation 21.

§ The PDP-WT recommends that further guidance on how to involve Advisory Committees or Supporting Organisations are to be included as part of the Policy Development Process Manual or Guidebook.

7. Evaluate the ICANN Staff costs and resources needed to conduct the PDP and prioritize existing policy work and revisit their existing deadlines and deliverables.

Current Practice

None

Concerns / Questions

7.a How should the GNSO Council prioritize its work with respect to the Initiation of new PDPs?

PDP-WT Response

7.a The WT noted that some issues that would need to be taken into account if/when discussing a system of prioritization include:

o Should there be a maximum of PDPs that can run simultaneously

o Role of identification of resources at the start of a PDP

o Development of a template to assess costs / burden

o Role of staff in making assessment or decisions on prioritization of PDPs

o Possibility to vote on initiation of a PDP but put on hold creation of a WG or set for later data to allow for a balanced PDP workload

o Should Council have flexibility and discretion to adjust timelines or decide when to start a WG? Or provide Council with maximum timelines within which they need to act?

o Multiple mechanisms to raise or lower the priority of a PDP without it dominating all activities or being pushed to the back burner

o Expected workload for staff

It was pointed out that there might be a need for further community input on the question whether a PDP should have fixed, flexible or target timelines. In addition, while it was important to consider ICANN staff and its resources, the GNSO Council should also consider the availability and interest of GNSO volunteers and related resources. A suggestion, made as part of the survey, was to develop an annual work plan based on longer term strategic planning using established norms / best practice for project planning that would include resource allocation management tools that would be used to create a community viewable master plan for PDPs and the changes that occur to this plan due to changes in need and priority.

Recommendations

See recommendation 14

8. What options should the GNSO Council have at its disposal to ensure that it can take an informed decision on whether to initiate a PDP or not subject to the time frames set forth in Question 4 above?

Current Practice

No current practice. The by-laws only foresee that the Council should meet to vote on the initiation.

Concerns / Questions

8.a Should the Council be allowed to invite experts and/or interested parties to provide additional information and/or answer questions on the issue?

8.b Should the Council be allowed to defer a vote if it feels that there are still questions that need to be answered before it can take an informed decision on whether to initiate a PDP or not?

PDP-WT Response

8.a The WT agreed that experts can inform Council deliberations. The WT also noted that by having a public comment period on the Issues Report, there would already be an opportunity for experts and community members to share their views, also on whether or not to initiate a PDP. In response to the survey, everyone (100%) of respondents agreed that the Council should be allowed to invite experts and/or interested parties to provide additional information and/or answer questions on the issue.

8.b A large majority of respondents to the survey (91%), agreed that the Council should be allowed to defer a vote if it feels that there are still questions that need to be answered before it can take an informed decision on whether to initiate a PDP or not, although someone pointed out that the possibility to defer a vote should be restricted by a threshold.

Recommendations

Recommendation 22.

§ The PDP-WT recommends that further guidance on the options the GNSO Council has at its disposal to take an informed decision to be included as part of the Policy Development Process Manual or Guidebook.

9. Public Comment Period after the Initiation of a PDP

Current By-law Provisions

After initiation of the PDP, ICANN shall post a notification of such action to the Website. A public comment period shall be commenced for the issue for a period of twenty (20) calendar days after initiation of the PDP. The Staff Manager, or some other designated representative of ICANN shall review the public comments and incorporate them into a report (the "Public Comment Report") to be included in either the Preliminary Task Force Report or the Initial Report, as applicable.

Current Practice

Currently, a number of Working Groups often wait until after its first few meetings to decide how the required public comment period should be used. In addition to the notification of the initiation of a PDP, this public comment period has been used by Working Groups to obtain input from the community on specific questions or issues raised in the Issues Report or in the charter itself to inform the deliberations of the Working Group at the start of the process.

Concerns / Questions

9.a Are these provisions still relevant?

PDP-WT Response

9.a The WT noted that if there is a public comment period following the Issues Report, as has been recommended for stage I that might already cover public input at the start of the process. At the same time, however, the WT acknowledged that WGs may want to continue the current practice of asking specific questions to the community at the start of the WG process in order to inform the WG’s deliberations. The WT suggested that it should be left as an option for the WG to consider at the start of its activities, but it may not need to be mandated by the by-laws. In response to the survey, 64% of respondents agreed that the provisions are still relevant, 27% disagreed, and 9% had no strong view either way.

Recommendations

Recommendation 23.

§ The PDP-WT recommends modifying clause 6 – public notification of initiation of the PDP to reflect current practice whereby a public comment period is initiated once a Working Group has been formed, not when the PDP is initiated to allow the WG to put out specific issues for public comment that might help inform its deliberations. The PDP-WT is considering whether this should be a mandatory or optional public comment period and hopes to receive further input on this issue during the public comment period.

6. Public Notification of Initiation of the PDP

10. Clarification of ‘in scope of ICANN policy process or the GNSO’

Current By-law Provisions

Vote of the Council. A vote of more than 33% of the Council members of each House or more than 66% vote of one House in favor of initiating the PDP within scope will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a GSNO Super Majority Vote as set forth in Article X, Section 3, paragraph 9(c) in favor of initiating the PDP will be required to initiate the PDP.

Concerns / Questions

10.a What does ‘in scope’ mean? Does that relate to whether something is within the scope of the GNSO, or does it relate to ‘consensus policies’ as defined in the registry and registrar agreements? How should this be clarified?

PDP-WT Response

10.a The WT noted that for purposes of conducting a policy development process, “in scope” should be defined to mean “within the scope of the GNSO” and that whether a topic is within the scope of the registry or registrar agreements is not something that must be considered upon the initiation of a PDP. Although knowing whether something is within the scope of the contracted party agreements may inform the process with respect to possible outcomes, it should not affect whether a PDP is initiated or not. The WT recognizes that there is a lack of understanding of this issue within the ICANN community and this will be important to clarify in the future. In addition, each WG (and its members) should understand that just because a PDP is initiated and is within the scope of the GNSO, that does not necessarily mean that the outcomes of the WG are necessarily within the scope of a Consensus Policy as defined in the contracted parties’ agreements and therefore contracted parties may not be forced to adopt the recommendations.

Recommendations

Recommendation 24.

§ The PDP-WT recommends modifying clause 3 – Initiation of a PDP to clarify that within scope means ‘within scope of ICANN’s mission and more specifically the role of the GNSO’ as opposed to within scope of the contracted parties’ definition of “consensus policies”.

Original Text
ICANN By-Laws

Proposed Text

3. Initiation of a PDP

Vote of the Council. A vote of more than 33% of the Council members of each House or more than 66% vote of one House in favor of initiating the PDP within scope will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a GSNO Super Majority Vote as set forth in Article X, Section 3, paragraph 9(c) in favor of initiating the PDP will be required to initiate the PDP.

Vote of the Council. A vote of more than 33% of the Council members of each House or more than 66% vote of one House in favor of initiating the PDP within scope of ICANN’s mission and more specifically the role of the GNSO (as defined in Article I, Section I and Article X, Section 1 of the Bylaws), will suffice to initiate the PDP; unless the Staff Recommendation stated that the issue is not properly within the scope of the ICANN policy process or the GNSO, in which case a GSNO Super Majority Vote as set forth in Article X, Section 3, paragraph 9(c) in favor of initiating the PDP will be required to initiate the PDP.

5 Stage III – Working Group

In discussing this stage, the PDP WT addressed the following general issues:

How to maximize the effectiveness of Working Groups
Communication with different ICANN Departments
Linking policy development with ICANN’s strategic planning and budgeting
Timing
Public comment periods
Implementation, impact and feasibility
ICANN staff resources
Constituency statements
Translation
Working Group output

1. How to maximize the effectiveness of Working Groups

Current Practice / Rules

None

Concerns / Questions

1.a What should be the role of face-to-face meetings for working groups, if any?

1.b Should there be a mechanism external to the Working Group to report issues observed about the activities of the Working Group e.g. failure to meet deadlines, inactivity of the Chair or Council Liaison? If yes, how should such a mechanism look?

PDP-WT Response

1.a The WT discussed that face-to-face meetings in conjunction with ICANN meetings can be an important recruitment tool and opportunity to solicit input from the broader ICANN community on a certain issue. In addition, it was noted that face-to-face meetings could also serve as a mechanism to drive completion of the activities of a WG. The WT agreed that Working Groups should be encouraged to consider organizing a face-to-face meeting at ICANN meetings, taking into account that such a meeting can be used in a variety of ways, in addition to being a ‘normal’ WG meeting, but that there would be no need to mandate the organization of such a meeting.

The WT noted that face-to-face meetings outside of ICANN meetings could be desirable in certain circumstances, such as satisfying a short deadline, but it was also pointed out that a face-to-face meeting outside of an ICANN meeting does require a large time commitment from WG members in addition to the obvious budget implication (travel funding, etc.). It was suggested that if a face-to-face meeting outside of an ICANN meeting would be deemed appropriate, linking it to another event or conference to which ICANN community members would already be travelling could be a way to reduce the costs.

Further, the WT felt that any face-to-face meeting should have remote participation facilities available in order to allow for participation by those that are not able to attend the meeting in person.

1.b The WT noted that such a process, if any, should address issues perceived by the GNSO Council, as the WG-WT is tasked to develop a procedure that will address process failure within a Working Group. It was suggested that issues such as what if the WG Chair resigns, should be raised with the WG-WT for possible inclusion in the procedure it is developing. In response to the survey, 50% agreed that there should be a mechanism to report process failure, 17% disagreed and 33% of respondents did not have a strong view either way. It should be noted that in response to the question ‘how should such a mechanism to report process failure look’, most provided examples that are within the WG-WT’s remit to consider such as role of the WG Chair and liaison, regular status updates and the need for clear timetables / objectives as part of the WG Charter. It was pointed out that apart from the normal mechanisms to communicate with the Council via the WG Chair and/or liaison and the WG-WT developed procedure for addressing process failure, members of the WG should feel empowered to raise any issues or concerns to the GNSO Councils via their respective constituency or stakeholder group representatives on the Council.

Recommendations

Recommendation 25.

§ The PDP-WT recommends that each PDP WG will be strongly encouraged to review the GNSO Working Group Guidelines that include further information and guidance on the functioning of GNSO Working Groups.

2. Communication with different ICANN Departments (e.g. Legal, Compliance, Services)

Current rules / practice

None

Concerns / Questions

2.a Should there be a mechanism to communicate with the Office of the General Counsel or other ICANN departments, if there are questions that may be relevant to the deliberations of the Working Group, e.g. related to scope, implementation or compliance?

PDP-WT Response

2.a The WT agreed that there should be some procedures in place, especially with regard to how communication is initiated and who is the gatekeeper. Most agreed that ICANN Staff should serve as the intermediate, some suggested that communications should go via the Chair or Council liaison.

Recommendation

Recommendation 26.

§ The PDP-WT recommends that further guidance is to be provided on which mechanisms are available to a WG to communicate with different ICANN departments in the Policy Development Process Manual or Guidebook. Suggested approach would be for ICANN policy staff to serve as the intermediate between a WG and the various ICANN departments (finance, legal, compliance, etc.), provided that a procedure is in place which allows for escalation via the WG Chair if the WG is of the opinion that communication is hindered through the involvement of ICANN policy staff.

3. Linking policy development with ICANN’s strategic planning and budgeting

Current rules / practice

None

Concerns / Questions

3.a How can the activities of the Working Group provide input to ICANN’s strategic planning and budgeting process?

3.b Should there be a process to defer policy development activities that are expected to result in significant financial costs i.e. requiring expert analysis and/or research?

PDP-WT Response

3.a The WT noted that policy development is often problem driven, which is not necessarily the focus of the strategic plan. There was agreement that alignment with the strategic plan might be appropriate for ‘big’ projects, but probably not for ‘ordinary’ policy issues. It was suggested that a WG could dedicate a section in its report for discussing considerations relevant to strategic planning or budget similar to the IANA and security considerations in IETF documents. At the same time, several members pointed out that this task is the responsibility of the GNSO Council and not the Working Group.

3.b It was noted that currently there is no insight into how the Council or WGs operate against the budget allocated for its operations and activities, and how decisions are taken on what gets funded and what does not. Responses to this question in the survey were equally divided between ‘yes’ (33%), ‘no’ (33%) and ‘other’ (33%). Someone noted that good policy should not be impeded by financial considerations, but at the same time policy can not be developed in a vacuum, oblivious to the impact on budget, resources and volunteer availability. A number of respondents to the survey also pointed out the link with the need for prioritization, noting that resources should be made available relative to the deemed importance of a policy.

Recommendations

Recommendation 27.

§ The PDP-WT has not arrived at a possible recommendation in relation to this issue yet and hopes to receive further input on this issue during the public comment period.

4. Public Comment

Current by-law provisions

Public Comments to the Task Force Report or Initial Report

a. The public comment period will last for twenty (20) calendar days after posting of the Task Force Report or Initial Report. Any individual or organization may submit comments during the public comment period, including any Constituency or Stakeholder Group that did not participate in the task force. All comments shall be accompanied by the name of the author of the comments, the author's relevant experience, and the author's interest in the issue.

b. At the end of the twenty (20) day period, the Staff Manager will be responsible for reviewing the comments received and adding those deemed appropriate for inclusion in the Staff Manager's reasonable discretion to the Task Force Report or Initial Report (collectively, the "Final Report"). The Staff Manager shall not be obligated to include all comments made during the comment period, including each comment made by any one individual or organization.

c. The Staff Manager shall prepare the Final Report and submit it to the Council chair within ten (10) calendar days after the end of the public comment period.

Concerns / Questions

4.a Should there be requirements or guidelines for public comment periods? If so, what should be included in these guidelines / requirements, and should these be mandatory or optional?

4.b Should a Working Group be required to conduct a public workshop during a public comment period to provide an update on the status of the work and solicit public input?

4.c How should a Working Group obtain public comments from persons and/or entities that do not participate in ICANN or other SOs/ACs?

4.d What should a Working Group do to obtain additional information related to a PDP that may exist outside of ICANN, the SOs and/or ACs?

4.e How can public comments be handled in a more transparent manner?

4.f Which public comment periods should be mandated by ICANN by-laws?

4.g Should any guidance be provided to Working Groups on how to review and incorporate public comments received?

4.h How long should public comment periods be? Should there be a difference between the length of a public comment period and the submission of constituency statements?

4.i Should those submitting public comments be requested to provide their name and affiliation? If yes, should providing such details be optional or mandatory?

PDP-WT Response

4.a The WT noted that there should be a balance between providing guidelines so that comments received are relevant and useful, but also leave the door open for ‘new’ issues or topics to be raised that might have been overlooked. Any guidelines should not restrict what comments can be submitted, but should contain information on terms of reference, duration, how comments will be used, etc. Someone noted that guidelines should help insure that the questions asked or issues raised are sufficiently clear to make the comments received useful.

4.b The WT discussed whether a webinar or workshop should be part of a public comment period to solicit input. The WT agreed that this option should be available for a WG to consider, but it should not be mandatory. It was suggested that a webinar / workshop could also take place at the start of a public comment period as a way to inform the community what the PDP is about and what issues / questions the WG is looking for input on and also as a outreach/recruitment tool for the WG itself. Many of those commenting on this section believed that the use of a webinar / workshop, although not mandatory, should be considered a best practice and if the WG decides not to take advantage of having at least one webinar or workshop, it should provide a justification for failing to do so.

4.c The WT agreed that, at a minimum, the public comment notice should be posted on the ICANN web-site, GNSO website and circulated to the liaison mailing list for distribution to the relevant stakeholder groups, constituency groups and advisory committees. Some noted that the WG through personal contacts and active communications would be in a position to reach out to those that they felt would be interested to provide input. Someone also pointed out that the OSC Communications WT might have some input that could be relevant to this point.

4.d It was suggested that a webinar at the start of a public comment period could be considered which would provide an overview of what input is requested and how this input will be considered as part of the process. Other suggestions made included the development of a brochure describing the mission of the WG and the encouragement of WG members to spread the word, especially targeting subject matter experts. It was noted that broad awareness of a PDP is the key issues and specific activities that would highlight a PDP would need to be further thought through.

4.e The WT reviewed the Affirmation of Commitments (AoC) and the references made there to public input, especially article 7[2|#_ftn2] related to fact-based policy making. It was pointed out that the summary and analysis provided by staff of the public comments received is open for review and modification by the WG if it was deemed that comments were not accurately reflected or ignored.

4.f Responses to this question varied in the survey; several respondents agreed that the current provisions should be maintained, some noted that a comment period should also be mandated after the (draft) final report and some suggested that one at the start of the process should also be mandated.

4.g The WT agreed that some guidance might be helpful, but debated whether such guidance should be mandatory or optional. Most agreed that a WG should provide a detailed explanation as to why or why not comments were considered and incorporated in general. However, it was also recognized that responding to each and every comment could be quite burdensome for the volunteers on the WG and this activity could be greatly aided by utilizing ICANN policy staff to the extent that they are able to do so. Some on the WT suggested that the WG should be advised, consistent with the AoC, that all comments must be reviwed by the WG and determined if they are relevant to the work of the PDP. If so, then the WG must either (a) identify the area of the report that addresses the content of the comment, or (b) modify the report to capture the comment’s ideas or concerns.

4.h It was suggested that public comment periods should typically run for a minimum of 30 days, which should be extended if the comment period falls during ICANN meetings. It was also suggested that if there is a request from a material portion of the ICANN community for one extension, this should be strongly considered. As a general rule, comment periods should not be opened or closed during an ICANN meeting. It was proposed that the duration of 30 days should also apply to all comments received, regardless of whether those comments are from individuals, businesses, organizations, constituencies, stakeholder groups and/or Advisory Committees and/or other SOs/ It was noted that the Governmental Advisory Committee might require more time due to its internal procedures, but all agreed that the work of a WG should not stop to wait for comments from the GAC, but that these should be considered when received.

4.i The WT agreed that those submitting public comments should be requested to provide their name affiliation, most (64%) were of the opinion that this should be mandatory, some (36%) supported that this should be optional.

Recommendations

Recommendation 28.

§ The PDP-WT recommends modifying clause 9 of Annex A of the ICANN by-laws to change the duration of the public comment period on the Initial Report from twenty to a minimum of thirty calendar days (see below for proposed new language).

Recommendation 29.

§ The PDP-WT recommends modifying clause 9 of Annex A of the ICANN by-laws to reflect the current practice that a summary and analysis of the public comments received is to be provided by the staff manager to the Working Group who will be responsible for reviewing the public comments received (see below for proposed new language).

Recommendation 30.

§ The PDP-WT recommends providing further guidance on how to conduct public comment periods and review public comments received as part of the Policy Development Process Manual or Guidebook.

Original Text
ICANN By-Laws

Proposed Text

9. Public Comments to the Task Force Report or Initial Report
a. The public comment period will last for twenty (20) calendar days after posting of the Task Force Report or Initial Report. Any individual or organization may submit comments during the public comment period, including any Constituency or Stakeholder Group that did not participate in the task force. All comments shall be accompanied by the name of the author of the comments, the author's relevant experience, and the author's interest in the issue.
b. At the end of the twenty (20) day period, the Staff Manager will be responsible for reviewing the comments received and adding those deemed appropriate for inclusion in the Staff Manager's reasonable discretion to the Task Force Report or Initial Report (collectively, the "Final Report"). The Staff Manager shall not be obligated to include all comments made during the comment period, including each comment made by any one individual or organization.
c. The Staff Manager shall prepare the Final Report and submit it to the Council chair within ten (10) calendar days after the end of the public comment period.

9. Public Comments to the Task Force Report or Initial Report
a. The public comment period will last for thirty (30) calendar days after posting of the Task Force Report or Initial Report; provided that is the closing of the comment period coincides with, or is within seven days after the end of an ICANN public meeting, such period should be extended so as to close no earlier than fourteen (14) days after the closing of the applicable ICANN public meeting. Any individual or organization may submit comments during the public comment period, including any Constituency or Stakeholder Group that did not participate in the Working Group. All comments shall be accompanied by the name of the author of the comments, the author's relevant experience, and the author's interest in the issue.
b. At the end of the thirty (30) day period, the Staff Manager will be responsible for reviewing the comments received and adding those deemed appropriate to the summary and analysis that will be provided to the Working Group to facilitate its review of the public comments received. The Staff Manager shall not be obligated to include all comments made during the comment period, including each comment made by any one individual or organization.
c. [To be decided]

5. Implementation, Impact and Feasibility

Current practice / rules

None

Concerns / Questions

5.a Should the Working Group consider issues of implementation and feasibility as part of their work and if ‘yes’, how should this be done?

5.b Should there be a procedure for clarification, reconsideration or complaint once a policy moves into the implementation phase and questions or concerns arise?

5.c How to obtain feedback from the ICANN services or compliance team on the feasibility of the proposals / recommendations?

5.d Should there be a possibility to test a new policy to assess whether it has the desired effects and allow for fine-tuning if needed?

PDP-WT Response

5.a The WT supports that a Working Group should consider issues of implementation and feasibility as part of its work and should solicit feedback by all affected and/or impacted parties to make such assessments. A number of suggestions were made as to how this could be done e.g. require the inclusion of implementation guidelines as part of the Final Report; consultation with the WG / Council on the draft implementation plan; the creation of an implementation team. The WT recognizes that it may not have all of the expertise and experience alone to draft such a plan, but it believes that with the right outreach and inclusion of impacted parties, that such a plan can a should be developed. This would not be limited to contracted parties, but also include applicable ICANN staff that would be involved in the implementation of such policies, It was also noted that an impact analysis should not be restricted to the impact on the contracted parties, but should also include registrants, businesses, and other organizations, taking into account the AoC emphasis on ICANN acting in the public interest. Further, some in the group cautioned that should not necessarily be driven by what ICANN staff considers ‘easy’ to implement, but at the same time recommendations should not be impossible to implement.

5.b Regardless of when (or by whom) an implementation plan is drafted, the WT discussed whether the proposed implementation plan should be reviewed by the WG prior to going out for community public comment or whether the public comment period should be extended to allow for input by the original WG or the GNSO council on the proposed implementation plan. Overall, the WT does believe that the proposed implementation plan should be reviewed by the relevant WG to determine whether the implementation plan is consistent with the recommendations of the WG. It was pointed out, however, that it would be important to avoid a constant going back and forth on the implementation plan, unless new information would have come up in the meantime. Another idea discussed was whether the WG and/or GNSO Council should approve or not object to the implementation plan before it would go to the ICANN board for consideration. Another issue that was raised was what mechanism for redress or reconsideration, if any, should a WG or the GNSO Council have if it was deemed that implementation has crossed the line and moved into policy making or if it would want to reconsider the policy recommendations. At a minimum, it was proposed that the public comment period on the implementation plan should be extended beyond 21 days to allow for feedback and input from all interested parties.

5.c Most agreed that participation, communication and/or consultation with relevant ICANN departments should ensure relevant feedback on the feasibility of the proposed recommendations.

5.d [To be completed]

Recommendations

Recommendation 31.

§ The PDP-WT recommends that PDP WGs provide input on issues related to implementation, impact (economic, business, social, operational, etc.) and feasibility and is considering the following options:

o Require the inclusion of implementation guidelines as part of the Final Report;

o Consultation with the WG / Council on the draft implementation plan;

o The creation of an implementation team that consists of representatives of the WG, amongst others, which would be tasked to review / provide input during the implementation phase

The PDP-WT hopes to receive further input on these options during the public comment period. (see also recommendation 42)

6. ICANN Staff Resources

Current rules / practice

None

Concerns / Questions

6.a Should ICANN staff resources needed or expected to carry out the policy recommendations be evaluated as part of the WG recommendations?

PDP-WT Response

6.a The PDP-WT agreed that staff resources needed or expected to implement the policy recommendations should be evaluated as part of the WG recommendations as part of the feasibility analysis and/or impact statement. Someone suggested that an impartial or third party assessment of the ICANN staff resources could be considered.

Recommendations

Recommendation 32.

§ The PDP-WT recommends that staff resources needed or expected in order to implement the policy recommendations should be evaluated as part of the WG recommendations, and as part of the Council’s review of those recommendations, as part of the feasibility analysis and/or impact statement (see recommendation 31).

7. Stakeholder / Constituency Statements

Current by-law provisions

Section 7 - Task Forces

[…]

d. Collection of Information

1. Constituency and Stakeholder Group Statements. The Representatives of the Stakeholder Groups will each be responsible for soliciting the position of their Stakeholder Groups or any of their constituencies, at a minimum, and other comments as each Representative deems appropriate, regarding the issue under consideration. This position and other comments, as applicable, should be submitted in a formal statement to the task force chair (each, a "Constituency/Stakeholder Group Statement") within thirty-five (35) calendar days after initiation of the PDP. Every Constituency/Stakeholder Group Statement shall include at least the following:

(i) If a Supermajority Vote was reached, a clear statement of the constituency's or Stakeholder Group’s position on the issue;

(ii) If a Supermajority Vote was not reached, a clear statement of all positions espoused by constituency or Stakeholder Group members;

(iii) A clear statement of how the constituency or Stakeholder Group arrived at its position(s). Specifically, the statement should detail specific constituency or Stakeholder Group meetings, teleconferences, or other means of deliberating an issue, and a list of all members who participated or otherwise submitted their views;

(iv) An analysis of how the issue would affect the constituency or Stakeholder Group, including any financial impact on the constituency or Stakeholder Group; and

(v) An analysis of the period of time that would likely be necessary to implement the policy.

Concerns / Questions

7.a Are the requirements noted in the by-laws still relevant?

7.b How / when should Constituency / Stakeholder Group Statements be solicited?

7.c Should Constituency / Stakeholder Group Statements have a different ‘weight’ when considered by the Working Group i.e. should there be different guidance on how constituency statements should be reviewed compared to public comments?

7.d What, if anything, should be done if few or no Constituency / Stakeholder Group Statements have been received?

7.e How should the by-laws reflect that certain stakeholder groups will not have Constituencies?

7.f How to avoid that constituency statements contribute to ‘stake out’ positions at the inception of a WG instead of being statements that facilitate the ability of the WG to analyze and debate problems and potential solutions ‘without feeling that they have to develop or assert a particular, or fixed, constituency position’, a concern noted by the board?

PDP-WT Response

7.a Most agreed that the requirements noted in the by-laws are still relevant.

7.b Most agreed that Constituency / Stakeholder group statements should be solicited early on in the process, with a few suggesting this should be done in conjunction with the public comment period(s) so as to ensure adequate feedback.

7.c The responses to the survey on this question were divided between ‘yes’; constituencies / stakeholder groups have a special status, they should be considered as having unique expertise or perspective on the ramifications of the PDP, they represent a recognized stakeholder perspective in policy development; and ‘no’; they should be considered in the same way as public comments.

7.d Most agreed that additional follow-up should be carried out with the Constituencies / Stakeholder Groups in question to try and obtain statements. Some raised the question that not receiving statements might be a reflection of perceived importance and/or workload. In either case, it was suggested that it would be helpful to go back to those Constituencies / Stakeholder Groups that did not provide a response to find out the reason (e.g. need more time, not interested, agree with the approach taken by the WG).

7.e Changes have already been made in a recent update of the by-laws to reflect the new structure of the GNSO.

7.f [TBD]

Recommendations

Recommendation 33.

§ The PDP-WT recommends amending clause 7 of Annex A of the ICANN by-laws to reflect the practice that Stakeholder Group / Constituency statements are requested by the Working Group and the timeline for submission should start from that point instead of the initiation of the PDP (see below for proposed new language).

Original Text
ICANN By-Laws

Proposed Text

Section 7 - Task Forces
[…]
d. Collection of Information
1. Constituency and Stakeholder Group Statements. The Representatives of the Stakeholder Groups will each be responsible for soliciting the position of their Stakeholder Groups or any of their constituencies, at a minimum, and other comments as each Representative deems appropriate, regarding the issue under consideration. This position and other comments, as applicable, should be submitted in a formal statement to the task force chair (each, a "Constituency/Stakeholder Group Statement") within thirty-five (35) calendar days after initiation of the PDP. Every Constituency/Stakeholder Group Statement shall include at least the following:

(i) If a Supermajority Vote was reached, a clear statement of the constituency's or Stakeholder Group’s position on the issue;
(ii) If a Supermajority Vote was not reached, a clear statement of all positions espoused by constituency or Stakeholder Group members;
(iii) A clear statement of how the constituency or Stakeholder Group arrived at its position(s). Specifically, the statement should detail specific constituency or Stakeholder Group meetings, teleconferences, or other means of deliberating an issue, and a list of all members who participated or otherwise submitted their views;
(iv) An analysis of how the issue would affect the constituency or Stakeholder Group, including any financial impact on the constituency or Stakeholder Group; and
(v) An analysis of the period of time that would likely be necessary to implement the policy.

Section 7 – Working Groups
[…]
d. Collection of Information
1. Constituency and Stakeholder Group Statements. The Representatives of the Stakeholder Groups will each be responsible for soliciting the position of their Stakeholder Groups or any of their constituencies, at a minimum, and other comments as each Representative deems appropriate, regarding the issue under consideration. This position and other comments, as applicable, should be submitted in a formal statement to the Working Group chair (each, a "Constituency/Stakeholder Group Statement") within thirty-five (35) calendar days following the request of the Working Group. Every Constituency/Stakeholder Group Statement shall include at least the following:
(i) If a Supermajority Vote was reached, a clear statement of the constituency's or Stakeholder Group’s position on the issue;
(ii) If a Supermajority Vote was not reached, a clear statement of all positions espoused by constituency or Stakeholder Group members;
(iii) A clear statement of how the constituency or Stakeholder Group arrived at its position(s). Specifically, the statement should detail specific constituency or Stakeholder Group meetings, teleconferences, or other means of deliberating an issue, and a list of all members who participated or otherwise submitted their views;
(iv) An analysis of how the issue would affect the constituency or Stakeholder Group, including any financial impact on the constituency or Stakeholder Group; and
(v) An analysis of the period of time that would likely be necessary to implement the policy.

8. Translation (note, also one of the overarching issues)

Current rules / practice

None

Concerns / Questions

8.a Which documents of the Working Group, or which parts of documents (e.g. executive summary) should be translated, in which languages and with what impact on the overall timeline?

PDP-WT Response

8.a Most agreed that any translations should be done in the 6 UN languages. Some recommended that the Issues Report and all documents up for review before board approval should be translated, some supported the translation of only the final work product, some suggested the translation of executive summaries and any documents for which a specific translation request is received and some recommended to follow general ICANN translation policy.

8.b It was suggested that the base line text should be published first, followed by the translations once ready. It was suggested that it could be helpful to review how other international organizations such as the UN and the EU deal with public comment periods. The group briefly discussed ICANN’s translation principles (http://www.icann.org/en/transparency/acct-trans-frameworks-principles-23jun07.htm#trans), but it was pointed out that as these are only principles, the PDP WT should consider whether there should be any specific requirements for translation of documents that are part of a PDP (which documents may / must be translated, in which languages). Most agreed that there should be equal access, but there should not be any delay in making available the original version of the document, just because translations are not available yet. It was suggested that comment periods should not end at different dates so that comments in other languages can also be taken into consideration when submitting comments. There was some support for holding public comment periods in different languages (42%), some opposition (25%) and some that did not have a strong view either way (33%). Most agreed that running the public comment period in different languages would likely extend the timeline, depending on how many comments would be received in different languages and how long it would take to get these translated back to English.

Recommendations

See overarching issues (section 8)

9. Working Group Output

Current by-law provisions

8. Procedure if No Task Force is Formed

[…]

c. The Staff Manager will take all Constituency/Stakeholder Group Statements, Public Comment Statements, and other information and compile (and post on the Comment Site) an Initial Report within fifty (50) calendar days after initiation of the PDP. Thereafter, the PDP shall follow the provisions of Item 9 below in creating a Final Report.

[…]

9. Public Comments to the Task Force Report or Initial Report

b. At the end of the twenty (20) day period, the Staff Manager will be responsible for reviewing the comments received and adding those deemed appropriate for inclusion in the Staff Manager's reasonable discretion to the Task Force Report or Initial Report (collectively, the "Final Report"). The Staff Manager shall not be obligated to include all comments made during the comment period, including each comment made by any one individual or organization.

c. The Staff Manager shall prepare the Final Report and submit it to the Council chair within ten (10) calendar days after the end of the public comment period.

Concern / Questions

9.a Are these outputs still relevant (Initial Report, Final Report)?

9.b Currently, the Initial Report is often used to invite comments on possible recommendations or conclusions, which are then reviewed and further finalized by the Working Group. Should this be reflected in the by-laws?

9.c Should a bibliography be added of sources used n the report or compendium?

9.d Should requirements or metrics for assessing the effectiveness of a policy after it has been implemented be included as part of the report?

PDP-WT Response

9.a ICANN Staff shared that current practice is that the Initial Report provides some initial ideas or recommendations for consideration for the broader ICANN Community to comment on. Following receipt of the public comments, the WG normally continues its deliberations following which the report is finalized. It was pointed out that according to the current by-laws, the difference between the initial report and the final report is the inclusion by the Staff Manager of the public comments. No additional work by the WG is foreseen according to the by-laws. The WT agreed that there should at least be one draft or interim report before the final version is released. The WT discussed that a WG could probably have four different kinds of output, of which possibly only the draft final report and the final report would be mandatory outputs:

1) An initial report which would be put out before the working group does any work at all and is meant to set the path of the charter questions and frame the deliberations on the group.

2) The second being an interim report which may or may not have initial recommendations for the public to consider.

3) The third being a draft final report which contains the recommendations and is at the end of the process and it essentially gives the public an opportunity to weigh in prior to the working group concluding

4) The last report being of course the final report.

It was pointed out that the current by-laws do not prohibit a WG to hold additional public comment periods on specific questions or other documents than the initial report.

A majority (55%) of respondents to the survey agreed that the outputs listed in the current by-laws are still relevant, 18% of respondents disagreed and 27% has no strong view either way.

9.b A majority (55%) of respondents to the survey had no strong view either way, 36% of respondents agreed that this should be reflected in the by-laws and 9% disagreed.

9.c There was support (64% of respondents to the survey) and no opposition (36% no strong view either way) to the inclusion of a bibliography of sources to be added to the report. However, it was noted that this should not be a requirement.

9.d [TBC]

Recommendations

Recommendation 34.

§ The PDP-WT recommends that PDP Working Groups continue to be required to produce at least an Initial Report and a Final Report, noting that more products can be produced if desirable.

Recommendation 35.

§ The PDP-WT does note that the description of the difference between an Initial Report and a Final Report as currently described in the By-Laws is not in line with actual practice, and recommends that this language is updated to reflect that an Initial Report may reflect the initial ideas of a WG which are then finalized, in combination with review and analysis of the public comment period in the second phase leading to the Final Report.

Recommendation 36.

§ The PDP-WT recommends that a public comment period on the Initial Report remains mandatory. Additional guidance on further optional public comment periods, e.g. when there are substantial differences between the Initial Report and Final Report should be included as part of the Policy Development Process Manual or Guidebook.

6 Stage IV – Voting and Implementation

This stage was broken down in the following subjects:

1. Working Group Recommendations

2. Public Comments

3. Delivery of recommendations to the ICANN Board

4. Agreement of the GNSO Council

5. ICANN Board Vote

6. Implementation

1. Working Group Recommendations

Current by-law provisions

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.

Concerns / Questions

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

1.a 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?

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

1.c If the GNSO Council 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).

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

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

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

1.g 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.

PDP-WT Response

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

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

In addition, 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? This question was submitted to the Working Group Work Team for further consideration.

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 substantial 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 up with a process to ensure broader consensus or input, but it should not do the work itself.

In response to the survey, 45% of respondents noted that the GNSO Council should have the discretion to pick and choose which WG recommendations to adopt, while 36% were of the opinion that the GNSO Council should only have the possibility to adopt or reject the WG recommendations as a whole.

1.b In response to the survey, 63% responded that the GNSO Council should not be able to make any changes or only non-substantial changes to WG recommendations.

1.c It was suggested that a public comment period should be held and the GNSO Council should also go back to the Working Group and request its view on the intended changes. Some suggested that a difference should be made between those recommendations that require Board approval and those that do not.

1.d All agreed that the GNSO Council should have the option to send the recommendations back to the Working Group if it felt that further work needs to be undertaken.

1.e Some suggested that a vote consistent with an out of scope PDP should apply for those recommendations that are not consensus recommendations. Others noted that the WG should document clearly in its report why consensus could not be reached, and that both rough consensus and unanimous consensus should be sufficient basis for the GNSO Council to make a decision. Some suggested that the GNSO Council should explore whether further work should be undertaken in order to achieve consensus. It was also suggested that if the recommendations would be rejected, they could be sent back with commentary to the WG for further consideration. It was pointed out that such recommendations might still find consensus in the GNSO Council, as part of a compromise. Others suggested that positions should be fully documented and included in the report to the board. It was also suggested that those recommendation that do not at least have strong support should either be rejected or sent back to the Working Group, the GNSO Council should not be in a position of deciding between equal competing positions as these issues need to be negotiated by the Working Group to arrive at a more robust agreement.

1.f If the GNSO Council rejects the recommendations of a PDP Working Group, 55% of respondents to the survey agreed that the reason for rejection, including other instructions, should be sent back to the WG for reconsideration while 18% noted that the PDP was completed. Others noted that it was up to the GNSO Council to decide what should happen next, but some added that reasons for rejection should be shared with the Working Group.

1.g Most agreed that there should be an opportunity for the WG to meet with the Council (82% of respondents to the survey), 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.

1.h 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.

Recommendations

Recommendation 37.

§ The PDP-WT recommends modifying clause 10 – Council Deliberations of Annex A of the ICANN by-laws to reflect current practice and requirements in the rules of procedure to consider a report if it is received at least eight days in advance of a Council meeting, otherwise the report shall be considered at the next Council meeting. In addition, the PDP-WT is considering recommending adding language to codify the current practice that any Stakeholder Group and/or Constituency can request the deferral of the consideration of a final report for one Council meeting (see below for proposed new language).

Recommendation 38.

§ The PDP-WT recommends to provide additional guidance to GNSO Council in the Policy Development Process Manual or Guidebook on how to treat Working Group recommendations, especially those that have not received full consensus and the expected / desired approach to adoption of some, but not all, or rejection of recommendations. There is discussion within the PDP-WT whether the GNSO Council should have the flexibility to ‘pick and choose’ recommendations. There is no agreement yet on what guidance, if any, should be given on recommendations that have not received full consensus. The PDP-WT hopes to receive further input on this issue during the public comment period.

	Original Text ICANN By-Laws	Proposed Text
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.	10. Council Deliberations a. Upon receipt of a Final Report, whether as the result of a task force working group 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. then the Council shall consider the Final Report at the meeting following receipt of such Final Report; provided that receipt of the Final Report is at least eight (8) days prior to the meeting. In the event that receipt of the Final Report is less than eight (8) 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. 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.

2. Public Comments

Current rules / practice

None

Concerns / questions

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

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

2.c 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?

PDP-WT Response

2.a Most agreed that the 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 before submitting the Final Report to the GNSO Council.

2.b 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 or as an Annex to 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.

2.c 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. The question was raised how to go 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.

Recommendations

§ See recommendation 36

3. Delivery of Recommendations to the Board

Current by-law provisions

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.

Concerns / Questions

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

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

PDP-WT Response

3.a 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 to the ICANN Board Governance Committee asking that they attend one of the WT calls to discuss these 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.

3.b There was agreement that the GNSO Council should provide input to the Board Report (support from 91% of respondents to the survey). 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.

Recommendations

Recommendation 39.

§ The PDP-WT recommends that the GNSO Council is responsible for the Board Report either as author of the report or to approve the report before it is sent to the Board. The PDP-WT discussed at length the current practice of ICANN Policy Staff submitting a separate report to the Board which is never disclosed to the community, noting that this is not directly related to the PDP, and unanimously believe that this practice should no longer continue. Reports on PDPs should be delivered from the GNSO Council directly to the Board and if any summaries are needed, that should be the responsibility of the Council with the help of the Working Group (if necessary). The PDP-WT has discussed ways in which to make the report more focused and easier to digest, but has not agreed on a possible recommendation in relation to this issue yet and hopes to receive further input on this issue during the public comment period.

4. Agreement of the Council

Current by-law provisions

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.

Concerns / Questions

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

PDP-WT Response

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. Some noted in their response to the survey that the voting thresholds might need to be reviewed.

Recommendations

Recommendation 40.

§ The PDP-WT has discussed whether the voting thresholds might need to be reviewed (see also overarching issues) but has not arrived yet at a possible recommendation in relation to this issue and hopes to receive further input on this issue during the public comment period.

5. Board Vote

Current by-law provisions

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.

Concerns / Questions

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

5.b 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?

5.c 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?

5.d 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?

5.e 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?

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

5.g Should the part that goes to the Board just be the executive summary of the Final Report?

PDP-WT Response

5.a Most agreed (73% of respondents to the survey) that the current provisions are still relevant. Some noted that provision 13f needs further clarification as explained in further detail below in the response to question 5f.

5.b 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.

5.c 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.

5.d 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. In response to the survey, it was suggested that a ‘conference committee’ could be convened, in which representatives from both the GNSO Council and the Board would come together to work out a consensus position. In addition, additional means for direct communications such as conference calls was suggested.

5.e This has been addressed in issue 4.

5.f 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.

5.g Only 18% of respondents to the survey agreed that only the executive summary of the Final Report should be sent to the Board, others pointed out that Board members should at least have the opportunity, if not the obligation, to read the entire work and that it depends on what the Working Group and/or Council feel is important to include in the report.

Recommendations

Recommendation 41.

§ The PDP-WT recommends that the provisions in relation to the Board Vote in the ICANN By-Laws remain essentially unchanged, noting that a clarification might be required to provision 13f to clarify what ‘act’ means -- (13 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’ - see also overarching issues section 8).

6. Implementation

Current by-law provisions

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.

Questions / Concerns

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

6.b 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?

6.c 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?

6.d 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?

PDP-WT Response

6.a 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.

6.b Most agreed that there should be a mechanism (73% of respondents to the survey). 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.

6.c 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 ICANN staff, Board or GNSO Council, could initiate an implementation review.

6.d 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.

Recommendations

Recommendation 42.

§ The PDP-WT recommends creating a WG Implementation Review Team, which would be responsible in dealing with implementation issues. The PDP-WT has not arrived yet at a possible recommendation in relation to how the process for reviewing and addressing implementation questions would work and hopes to receive further input on this issue during the public comment period. (see also recommendation 31)

7 Stage V – Policy Effectiveness and Compliance

This stage was broken down in the following issues:

1. Periodic assessment of PDP Recommendations / Policy

2. GNSO Council Review of the PDP WG

3. Periodic assessment of Overall PDP process

1. Periodic assessment of PDP Recommendations / Policy

Current By-Law Provisions

None

Issues / Concerns

1.a What metrics would need to be developed in order to assess the effectiveness of the PDP recommendations and/or policy?

1.b Would these metrics be replicable for each PDP or should clear objectives and metrics be established for each PDP?

1.c Should a periodic assessment be inherent to every PDP or should this be determined on a case-by-case basis?

1.d If a periodic assessment is considered inherent, should the timing for such an assessment be the same for every PDP?

1.e Who should be responsible for carrying out this assessment? And how /what should be done with the outcomes of the review / assessment?

1.f How should public comments or community input on the effectiveness of a policy be factored in?

1.g How should compliance with a new policy or policy elements be assessed and factored in? E.g. Should an audit be part of the metrics / assessment of a policy?

1.h What role, if any, should the WG have in proposing or developing performance metrics?

PDP-WT Response

1.a Some noted that some past PDPs contained specific recommendations / suggestions on how and when to review the policy and its impact, such as the Domain Tasting PDP. In response to the survey, some pointed out that one would need to measure the effectiveness of addressing the issue but also any unexpected consequences, especially negative effects that were not anticipated beforehand. Some also noted that in order to measure the effectiveness, one would need to quantify the harm that the PDP is set out to address as ‘only when the problem is stated in measurable terms, can the solution’s efficacy also be measured’. Others noted that if a PDP was intended to launch something new, instead of solving a problem, the metrics used to assess the effectiveness should be broader and relate to the initial purpose. It was suggested that a standard table with criteria could be developed to which additional elements could be added depending on the nature and scope of the respective PDP.

1.b Most agreed that metrics would need to be adapted to each PDP, although some noted there might be some general categories that would apply to all.

1.c Most agreed that a periodic assessment should be inherent to every PDP.

1.d Most agreed that timing for such a periodic assessment should be allowed to vary depending on the nature and scope of the PDP.

1.e Several respondents to the survey suggested that ICANN staff should be responsible for the assessment, either with oversight by the GNSO Council, Community Input or co-operation with a dedicated review team designated by the GNSO Council. Some suggested that the GNSO Council should appoint review teams.

1.f Several noted that the normal procedure for a public comment period could be applied whereby the ICANN community is requested to provide feedback and input which is then reviewed and incorporated as deemed appropriate by the body dealing with the assessment (e.g. review team, GNSO Council and/or ICANN staff).

1.g Some noted that an audit might be appropriate while others noted that it would depend on the PDP in question. Some pointed out that compliance with the policy would be an important element in the evaluation with regard to the effectiveness of a policy. It was suggested that permanent monitoring tools could allow stakeholders to report infringements which could then feed into the periodic evaluation of the policy.

1.h Some noted that many WGs seem to be conscious of the need for assessment of a policy following its recommendations and are therefore providing concrete recommendations on how to make such an assessment based on the issue/problem the WG was aiming to address. Some raised the question how you can assess effectiveness if it is not clear which issue you are addressing, pointing to some recent PDPs where there seems to be a lack of clear direction on what issue/problem the objective of the PDP is. Some noted that such direction should be provided by the GNSO Council upon the initiation of the PDP and that it should not be the task of the WG to identify the issue. It was noted that with a more thorough and focused planning and initiation phase, as being proposed by the PDP WT, this issue might be avoided in the future. Most agreed that a WG should be expected to identify and integrate appropriate metrics in its report to the GNSO Council.

Recommendations

Recommendation 43.

§ The PDP-WT notes that a periodic assessment of PDP recommendations and/or policy is important but has arrived at any possible recommendations yet and hopes to receive further input on this issue during the public comment period.

2. GNSO Council Review of the PDP Working Group

Current By-Law Provisions

None

Issues / Concerns

2.a Should the GNSO Council be required to conduct an assessment at the end of a PDP process?

2.b If yes, what elements should be included in this process? The BGC WG reports suggests checking:

o Does the scooping of the issue remain valid

o Are all relevant stakeholders aware of, and involved in the process

o Has no one stakeholder group is dominating the process

o Are any necessary expert opinions provided

o Data has been provided and used where appropriate

o Can the proposed policy be implemented

2.c If the elements identified in the previous question are not met, what should the role of the GNSO Council be to ensure that these get addressed?

PDP-WT Response

2.a The question was raised whether it would be feasible to conduct an assessment after every PDP? It was suggested that it might be better to make it part of a periodic review of the overall PDP process. Some suggested that a review after one year, followed by periodic reviews might be appropriate, but some pointed out that a first PDP might not be concluded in one-year timeframe. Alternatively, it was suggested that a review should be conducted after x number of PDPs had been concluded. All agreed that it would be helpful if feedback from each PDP WG would be obtained to their experiences with the new PDP. Such data could then serve as input into an overall review of the new PDP.

2.b Most agreed that not all elements listed in the BGC WG Report might be appropriate for such a review as it would be more focused on the functioning of the actual PDP process and not be about the outcome or issue that was the focus of the PDP. All agreed that such a review should not have any impact or bearing on the recommendations or policy that had been adopted as a result of the PDP.

2.c In response to the survey, several suggested that the identified issues should be sent back to the WG for additional work or clarifications if the identified issues were deemed remediable. It was also suggested that in other instances the GNSO Council might want to include a note on the found deficiencies in its report to the ICANN Board. Others pointed out that in its new role, it would be the Council’s responsibility as a manager of the policy process to ensure that the appropriate rules are followed; the Council should not endorse a policy that did not follow those rules.

Recommendations

Recommendation 44.

§ The PDP-WT notes that the GNSO Council Review of a PDP Working Group is important but has not arrived at any possible recommendations yet and hopes to receive further input on this issue during the public comment period.

3. Periodic assessment of Overall PDP process

Current By-Law Provisions

None

Issues / Concerns

3.a What metrics would need to be developed in order to assess the effectiveness of the PDP process as a whole?

3.b What would be a realistic timeframe for conducting such periodic assessment?

3.c Who should be responsible for carrying out this assessment? And how /what should be done with the outcomes of the review / assessment?

PDP-WT Response

3.a Some metrics suggested in response to the survey included: time to completion; effectiveness and possible negative effects; record of compliance; public comments over time and review time; how often has a PDP been conducted in a certain time period; have timelines been respected; diversity of participants.

3.b See also the response to question 2a. It was suggested that a ‘problem driven’ review approach could be pursued; only if substantial or a sufficient number of issues have been identified by the GNSO Council, a review would be carried out. It was noted that the WG WT proposes in their Working Group Guidelines to have an annual check by the GNSO Council of whether there are any major issues identified with the WG Guidelines, if yes, a standing committee or ad-hoc WG might deal with these, if not, nothing is done. A similar approach might be pursued for the PDP review process.

3.c A number of different responses were received as part of the survey including: a GNSO Council appointed group; the PPSC as a standing committee; ICANN staff with overview of the GNSO Council; the PDP-WT, and; the Accountability and Transparency Review mechanism established by the AoC.

Recommendations

Recommendation 45.

§ The PDP-WT notes that the periodic assessment of the overall PDP process is important but has not arrived any possible recommendations yet and hopes to receive further input on this issue during the public comment period.

8 Overarching Issues

In addition to the five stages discussed in the previous sections of this report, the PDP-WT also identified a number of ‘overarching issues’ which were deemed to have an impact on the overall policy development process or related to various stages of the new PDP and therefore needed to be considered once an initial outline of the new PDP would have been completed. These overarching issues consist of:

o Timing

o Translation

o Development of definitions

o Voting thresholds

o Decision-making methodology

o Transition / Implementation of the new PDP

The PDP-WT has not completed its work on all these overarching issues, but has noted below its initial deliberations on some of these issues for public input and consideration. It is the intention of the PDP-WT to finalize its recommendations on these issues following the review and analysis of public comments on this initial report.

a) Timing

The overall timing of the new PDP, as well as timing of the respective stages of the PDP need to be reviewed and agreed upon. Some draft recommendations for changes to the current timing are already included in the different stages of the new PDP, but an overall review of the timing will need to be conducted.

b) Translation

What translations should be provided at each stage of the policy development process and how will translation impact timing / delay e.g. in relation to a public comment periods. How to assess the success and/or additional needs for translation? The following are ICANN’s current translation principles:

ICANN will provide timely and accurate translations, and move from an organisation that provides translation of texts to one that is capable of communicating comfortably with a range of different languages. The translation framework comprises a four-layer system:

- The bottom layer contains those specific documents and publications that address the organisation’s overall strategic thinking. They will be translated into an agreed block of languages.

- The next layer contains a class of documents that ICANN undertakes to provide in different languages to allow interaction within ICANN processes by non-English speakers.

- The third layer comprises documents suggested by ICANN staff as being helpful or necessary in ongoing processes; and documents requested by the Internet community for the same reasons. These documents will be run through a translation approval system.

- The top layer is where the community is encouraged to use online collaborative tools to provide understandable versions of ICANN materials as well as material dynamically generated by the community itself. ICANN will provide the technology for community editing and rating, and a clear and predictable online location for this interaction to occur. It will also seek input from the community to review the tools.

English will remain the operating language of ICANN for business consultation and legal purposes.

Every effort will be made to ensure equity between comments made in languages other than English and those made in English. If it is not possible to arrange the release of particular documents in the agreed languages at the same time, then each language will be provided with the same time period in which to make comments.

ICANN will adopt the International Organisation for Standardisation’s 639-2 naming system for identifying and labelling particular languages.

PDP-WT deliberations:

§ ICANN Staff noted that draft corporate translation policy is in the making which might be able to provide further input in due time. In addition, staff shared the main elements of the policy department translation policy which is to a large extend aspirational in having all relevant documents translated in the 5 UN languages, but noted that currently in practice almost all executive summaries of Issues, Initial and Final Reports are being translated.
§ The WT discussed the potential role of volunteers in assisting with translation of documents, but also noted the potential obstacles in shifting responsibility for translation to volunteers.
§ Some suggested that a volunteer editorial group could be considered which would be tasked to review translations developed by professional translators to ensure the ICANN lingo and technical terms have been translated correctly.
§ The WT discussed what or how ‘relevant languages’ could be decided upon and agreed that it might be better to stick to the 5 UN languages (French, Spanish, Arabic, Chinese and Russian) as the standard.
§ The WT agreed that the following elements must be translated:
- Charter
- Executive Summary of Initial, Final or any other report that is put out for public comment
§ In addition, the WT agreed that public comments must be received in other languages and where feasible, these comments should also be translated back into English.
§ Furthermore, the WT agreed that policy recommendations should be translated.
§ The WT agreed to discuss at its next meeting the potential impact of translation on timing, especially in relation to the public comment periods.
§ In relation to the issue of how to ensure that doing the translations when recommended by PDP-WT do not slow down PDP process or ensure that all comments received can be considered, the WT discussed the different options such as waiting until all translations are available before releasing the documents and opening the public comment period; extending public comment periods for other languages if the translated document becomes available later than the English version; shorten public comment periods in other languages than English to allow time to translate comments back in English. The WT also noted the budget implication that translations have. ICANN staff was asked to gather data on the use of and demand for translated documents to help inform the deliberations. Most members agreed that the WT should propose guidelines, instead of mandatory requirements in relation to translation, having as the ultimate target to ‘make as many documents available in the 5 UN languages in order for people to constructively participate in the PDP process’.

c) Development of Definitions

§ What is meant with Policy Development Process? What falls in this category? When does it start?

§ Consensus policies – difference between registry and registrar definitions

§ Clarification of terminology and distinguish between a request for an Issues Report and a request for a PDP

§ Constituency vs. Stakeholder Group

§ What is meant with ‘in scope and ‘not in scope’ as these concepts are used in relation to voting thresholds?

§ Also refer to article 16 of Annex A of the ICANN by-laws which contains a number of other definitions.

d) Voting thresholds

Are the voting thresholds as adopted as part of the new GNSO structure appropriate and effective (see current voting thresholds highlighted in green in the next chapter)?

Are the voting thresholds as adopted as part of the new GNSO structure appropriate and effective? Are there any others?

Existing thresholds:

1. Raising an Issue: Council initiation: 25% of the members of the Council of each house or a majority of one house.

2. Initiating PDP:

a. More than 33% of the Council members of each House; or More than 66% vote of one House if within scope

b. GNSO Supermajority Vote required if not in scope (75% of one House and a majority of the other house)

3. Vote on Approving the Charter (Does this apply to modifications to the Charter as well)

a. More than 33% of the Council members of each house; or More than 66% of one House if within Scope

b. GNSO Supermajority vote required if not in scope

4. Vote of Council (From Article 10, Section 3, #9)

a. Approve a PDP Recommendation without a GNSO Supermajority – requires an affirmative vote of majority of each House and further requires that one GNSO Council member representative of at least 3 of the 4 Stakeholder Groups supports the Recommendation

b. Approve a PDP Recommendation with a GNSO Supermajority – requires an affirmative vote of a GNSO Supermajority; and

c. Approve a PDP Recommendation Imposing New obligations on certain Contracting Parties: where an ICANN contract provision specifies that “a two-thirds vote of the council” demonstrates the presence of a consensus, the GNSO Supermajority vote threshold will have to be met or exceeded with respect to any contracting party affected by such contract provision.

5. Board Vote

a. 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.

b. 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.

c. 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.

d. 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.

e. 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 [NOTE – The PDP-WT should discuss what this means? How does this affect contracted parties? In other words, if there is no supermajority y in the GNSO, but it falls within picket fence, can this be enforced against contracted parties?]

f. 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 [Does anyone understand what this means?]

Other Item to discuss: Thresholds within a Working Group from WG WT Report along with comments received

PDP-WT Deliberations

§ The WT discussed voting threshold 1 ‘Raising an Issue’ – most agreed that the current threshold is appropriate as the initial gauge should be low. The WT discussed what ‘member of the Council’ means and noted that the GCOT is also reviewing these terms in the context of their discussion on proxy / absentee voting.

§ The WT discussed voting threshold 2 ‘Initiating a PDP’ and discussed whether a higher voting threshold should apply if staff would recommend against initiating a PDP (not related to scope issue). Most agreed that no higher voting threshold should be required, as it would otherwise give staff indirectly a vote in the process. WT members discussed the issue of prioritization and the role the current threshold, which is considered low by some, plays in creating work the community and staff has difficulty keeping up with. Some where of the opinion that keeping the threshold as it currently is would be appropriate. Others considered there to be a strong relationship between this threshold and the prioritization effort the GNSO Council is currently undertaking and were of the opinion that if there is no effective prioritization this threshold may need to be raised in order to avoid GNSO community and staff overload. It was agreed to put this issue to the mailing list for further input.

§ The WT discussed voting threshold 2b and debated what is actually meant with ‘if not in scope’. It was noted that there has been once PDP that was considered ‘out of scope’ namely the ‘GNSO Policies for contractual conditions, existing gTLDs PDP’ which addressed contractual provisions in gTLD registry agreements. In debating the value of initiating a PDP on issues that are ‘out of scope’ or on issues that might not be enforceable on contracted parties, it was pointed out that the PDP is the only formal mechanism the GNSO has to bring issues to the attention of the ICANN board.

§ The WT discussed the definition of a ‘GNSO Supermajority vote’ and it was proposed to add the original meaning of GNSO Supermajority i.e. 2/3 of Council members of each house to the definition so that it would be 75% of one House and a majority of the other house or 2/3 of Council members of each house.

§ The WT reviewed the proposed voting threshold for the adoption of a WG charter (3) and all supported the one as proposed, noting that this would require every WG to have a charter. The WT also discussed whether any provisions would need to be foreseen in the case that multiple charters would be proposed, a scenario that recently occurred in relation to the charter for the Vertical Integration PDP WG. In this scenario, it would in theory be possible for competing charters to be adopted as only 33% of one house is required for adoption. The WT agreed that this issue needed further discussion on the list as well as review of the pros and cons of possible solutions that were suggested such as: if there is more than one charter, it needs to be adopted by a majority vote; allow WG to decide on which charter; GNSO Council Chair to broker agreement.

§ The WT then discussed how modifications to a WG charter should be treated. It was suggested that administrative changes such as those modifying the timeline would need a majority of both houses, while material changes such as those modifying the charter questions would require a supermajority vote, to ensure that the substance of a WG charter could only be changed in exceptional circumstances..

§ The WT discussed voting threshold 4 – Vote of the Council and reconfirmed its earlier conclusion that the Council should have the flexibility to address WG recommendations as a package or individually, but that a WG would be encouraged to indicate to the Council where there would be linkage between recommendations as part of its report. In those cases where recommendations are considered to be mutually exclusive, it would be the expectation that the Council Chair would manage the process of deliberation and decision on such recommendations.

§ In relation to 4c, it was noted that only registrars have a clause in their agreement that specifies that “a two-thirds vote of the council” demonstrates the presence of a consensus. Registries have a general definition of consensus in their agreements. A staff memorandum circulated to the group (see http://forum.icann.org/lists/gnso-ppsc-pdp/msg00359.html) recommends ‘to standardize all of the voting requirements for all registries and all registrars in order to adopt Consensus Policies that would be enforceable against them. Staff proposes that the GNSO Supermajority Vote apply in all instances where the GNSO Council intends to adopt consensus policies to be enforceable against all registrars and registries’. Some argued that the current wording could also imply the lower threshold vote and this clarification would ensure that the higher threshold would apply, while others argued this might be a lower standard than currently applicable as ‘consensus’ in the registry agreement does not only relate to the vote of the GNSO Council.

§ In relation to 5a, the WT discussed whether it would be possible to word this provision in a positive way (instead of noting how many are needed to reject, note how many are needed to approve).

§ In relation to 5b, the WT highlighted the importance of the board statement with info on why something was rejected. The WT discussed whether a timeframe should be included as to when the board is required to submit its statement to the GNSO Council and it was suggested that a certain timeframe should be included (e.g. Board shall within x days submit the board statement to the GNSO Council with guidance on how to cure the identified deficiencies).

§ In relation to 5c, the WT agreed to consider including a similar timeframe as for earlier discussed items (i.e. consider at next meeting if received 8 days ahead of the meeting, or at the following meeting if not received 8 days ahead of the meeting).

§ The WT also discussed whether the board should be able to pick and choose recommendations or whether they should be adopted or rejected ‘en block’ as has been current practice. Most agreed that the board should only be able to adopt or reject the GNSO Council recommendations as a whole as policy development is supposed to be done at the SO level, not by the board.

§ The WT furthermore discussed whether an ad hoc procedure should be considered / developed to address situations such as the STI, but it was pointed out that the board already can form expert or technical committees to obtain advice.

§ The WT discussed 5e and noted that there were different interpretations of what ‘will be sufficient to act’ means. Some members of the contracted parties interpret this as meaning that without supermajority vote of the Council, the Board can act and adopt the recommendations with a majority vote, but these would not be binding on the contracted parties. Other members of the non-contracted parties were of the opinion that it meant that the board could act and adopt policy recommendations that would be enforceable on contracted parties even without a supermajority vote of the GNSO Council. There was support to clarify this provision to note that the board can adopt enforceable policy recommendations if there is no supermajority vote of the GNSO Council, but only if there is a supermajority vote of the Board in support. It was pointed out that it would be presumed that there was at least a majority vote in favor of the recommendations before the Board would consider any recommendations from the GNSO Council.

§ The WT discussed 5f and the meaning of ‘timely’. Some suggested this could mean time-sensitive, critical or urgent. The question was raised who makes the assessment on whether something is timely? Most agreed that it would be the role of the ICANN Board to make this assessment, although the GNSO Council could make a recommendation to this end. ICANN staff has been requested to ask for clarification from Legal on this provision.

e) Decision-making methodology

Should there be a specific decision-making methodology for PDP Working Groups? The methodology proposed by the Working Group Work Team for Working Groups in general is as follows:

*(*From the latest version of the WG WT GNSO Working Group Guidelines)

“Standard Methodology for Making Decisions
The Chair will be responsible for designating each position as having one of the following designations:

Full consensus – a position where no minority disagrees
Consensus - a position where a small minority disagrees but most agree
No consensus but strong support for a specific position / recommendation but significant opposition
Divergence – no strong support for a specific position / recommendation

In the case of consensus, no consensus or divergence, the WG Chair should encourage the submission of minority viewpoint(s).

Based upon the WG's needs and/or the Chair’s direction, WG participants may request that their name is not associated explicitly with any view/position.

If a chartering organization wishes to deviate from the standard methodology for making decisions or empower the WG to decide its own decision-making methodology it should be affirmatively stated in the WG Charter.

Consensus calls should always involve the entire Working Group. It is the role of the Chair to designate which level of consensus is reached and announce this designation to the Working Group. Member(s) of the Working Group should be able to challenge the designation of the Chair as part of the Working Group discussion. However, if disagreement persists, members of the WG may use the above noted process to challenge the designation.

If several participants in a WG disagree with the designation given to a position by the Chair or any other rough consensus call, they may follow these steps sequentially:

1. Send email to the Chair, copying the WG explaining why the decision is believed to be in error.

2. If the Chair still disagrees with the complainants, the Chair will forward the appeal to the CO liaison(s). The Chair must explain his or her reasoning in the response to the complainants and in the submission to the liaison. If the liaison(s) supports the Chair's position, the liaison(s) will provide their response to the complainants. The liaison(s) must explain their reasoning in the response. If the CO liaison disagrees with the Chair, the liaison will forward the appeal to the CO. Should the complainants disagree with the liaison support of the Chair’s determination, the complainants may appeal to the Chair of the CO or their designated representative. If the CO agrees with the complainants’ position, the CO should recommend remedial action to the Chair.

3. In the event of any appeal, the CO will attach a statement of the appeal to the WG and/or Board report. This statement should include all of the documentation from all steps in the appeals process and should include a statement from the CO.[3|#_ftn3]

Appeal Process

Any WG member that believes that his/her contributions are being systematically ignored or discounted or wants to appeal a decision of the WG or CO should first discuss the circumstances with the WG Chair. In the event that the matter cannot be resolved satisfactorily, the WG member should request an opportunity to discuss the situation with the Chair of the Chartering Organization or their designated representative.

In addition, if any member of the WG is of the opinion that someone is not performing their role according to the criteria outlined in section 2.2. of this document, the same appeals process may be invoked.

[1] It should be noted that ICANN also has other conflict resolution mechanisms available that could be considered in case any of the parties are dissatisfied with the outcome of this process.”

It should be noted that further changes might be made following submission to the Policy Process Steering Committee.

In addition, the PDP WT might want to review whether further details need to be provided for decision-making in a drafting team responsible for preparing a charter. No specific rules are currently provided, but a recent experience demonstrates that there might be a need to provide further guidance especially in cases where there is disagreement or even deadlock on what should be included in the charter.

See also feedback from WG-WT members to a number of questions in relation to decision-making: https://st.icann.org/icann-ppsc/index.cgi?additional_questions.

f) Transition

How should the transition to the new PDP be handled? What effect will it have on ongoing PDPs?

9 New PDP Flow Chart – Basis for new Annex A

This section of the Initial Report contains a flow-chart that shows the main elements of the proposed new Annex A – GNSO Policy Development Process of the ICANN By-Laws based on the recommendations that are put forward by the PDP-WT for the community’s consideration. The first chart provides a high level overview of the different steps and elements that are proposed to form the new PDP. Following the high level overview, you will find a more detailed breakdown of each phase, including the relevant recommendations of the PDP-WT in relation to each step. To facilitate review of the relevant recommendations, please see Annex IV for a list.

The Board Governance Committee Report on GNSO Improvements noted that ‘Many in the ICANN community support removing the PDP requirements from the Bylaws and incorporating them into the GNSO’s operating procedures. The procedure for developing “consensus policies,” however, must track with ICANN’s contractual requirements, and should be clarified in the Bylaws’. To this end, the PDP-WT has provided an indication of which elements the PDP-WT is considering recommending be included in Annex A of the ICANN by-laws (B) or the GNSO Rules of Procedure (R). The main difference being that changes to the ICANN by-laws need to be approved by the ICANN Board while changes to the GNSO Rules of Procedure can be adopted by the GNSO Council, without requiring Board approval.

Figure 1 – High level overview of the proposed new GNSO PDP

Figure 2 – Other GNSO Processes

Stage I – Planning and Request for an Issues Report

Stage II – GNSO Council Review of the Issues Report and Initiation of the Policy Development Process

Stage III – Working Group

Stage IV – Voting and Implementation

Stage V – Policy Effectiveness and Compliance

To be decided – see recommendations 43, 44, 45.

ANNEX I - Background

On 26 June 2008 the ICANN Board approved a set of recommendations designed to improve the effectiveness of the GNSO, including its policy activities, structure, operations, and communications. The GNSO Improvements Report, approved by the Board, identified the following key objectives:

Maximize the ability for all interested stakeholders to participate in the GNSO’s policy development processes;
Ensure that recommendations can be developed on gTLD “consensus policies” for Board review and that the subject matter of “consensus policies” is clearly defined;
Ensure that policy development processes are based on thoroughly-researched, well-scoped objectives, and are run in a predictable manner that yields results that can be implemented effectively;
Align policy development more tightly with ICANN’s strategic and operations plans; and
Improve communications and administrative support for GNSO objectives.

The Board emphasized the need to improve inclusiveness and representativeness in the GNSO’s work while increasing its effectiveness and efficiency. The following pertains to the PDP-WT’s mission:

Revising the PDP: The Policy Development Process (PDP) needs to be revised to make it more effective and responsive to ICANN’s needs. It should be brought in-line with the time and effort actually required to develop policy and made consistent with ICANN’s existing contracts (including, but not limited to, clarifying the appropriate scope of GNSO “consensus policy” development). While the procedure for developing “consensus policies” will need to continue to be established by the Bylaws as long as required by ICANN’s contracts, the GNSO Council and Staff should propose new PDP rules for the Board’s consideration and approval that contain more flexibility. The new rules should emphasize the importance of the preparation that must be done before launch of a working group or other activity, such as public discussion, fact-finding, and expert research in order to properly define the scope, objective, and schedule for a specific policy development goal and the development of metrics for measuring success.

The charter of the PDP-WT is to develop and document a revised GNSO Policy Development Process that achieves the goals established by the ICANN Board. The PDP-WT, with staff assistance, will need to determine what changes to the bylaws will be required. New processes will need to be documented properly to ensure that the bylaws (and any related operational rules or procedures) are updated accurately. The revised PDP, after review and approval by the PPSC, GNSO Council, and ICANN Board, would replace the current PDP defined in Annex A of the ICANN bylaws.

This mandate arises not from a change in the mission or role of the GNSO, but from the accumulation of experience with the current PDP and the decisions that have been made by the ICANN Board concerning an organizational restructuring of the GNSO.

The PDP-WT’s mission is closely related to that of the parallel Working Group Work Team (WG-WT) also chartered by the PPSC. The charter of the WG-WT is to “[d]evelop a new GNSO Working Group Model that improves inclusiveness, improves effectiveness, and improves efficiency”. The two PPSC Work Teams are expected to work independently, but in consultation with each other.

For further details please visit the GNSO Improvements Home Page.

ANNEX II - Working Group Charter

I. TEAM CHARTER/GOALS:

The GNSO Council’s responsibility in recommending substantive policies relating to generic top-level domains is a critical part of ICANN’s function. The mechanism by which the GNSO makes such recommendations to the ICANN Board of Directors is through the GNSO Policy Development Process (PDP) set forth in the ICANN Bylaws. The PDP Work Team is responsible for developing a new policy development process that incorporates a working group approach and makes it more effective and responsive to ICANN’s policy development needs. The primary tasks are to develop:

1. Appropriate operating principles, rules and procedures applicable to a new policy development process; and

2. An implementation/transition plan.

Specifically, the GNSO Improvements Report approved by the ICANN Board recommended that a new PDP:

1. Be better aligned with the contractual requirements of ICANN’s consensus policies as that term is used in its contracts with registries and registrars and clearly distinguishes the development of “consensus policies” from general policy advice the GNSO Council may wish to provide to the Board. In addition, the Bylaws should clarify that only a GNSO recommendation on a consensus policy can, depending on the breadth of support, be considered binding on the Board, unless it is rejected by a supermajority vote.

2. Emphasize the importance of the work that must be done before launching a working group or other policy development activity, such as public discussion, fact-finding and expert research in order to define properly the scope, objective and schedule for a specific policy development goal.

3. Be more flexible than the current model, containing timelines that are consistent with the task.

4. Provide for periodic assessment to determine the effectiveness of revised rules, processes, and procedures on policy development work including self-reporting by each working group of any lessons learned, as well as input on metrics that could help measure the success of the policy recommendation. In addition the GNSO Council Chair should present an annual report to the ICANN community on the effectiveness of new GNSO policies using the metrics developed at the end of each PDP. The report should also contain a synthesis of lessons learned from policy development during the year with a view to establishing best practices. The report should be presented annually at an ICANN public meeting each year, and the material should be incorporated into the ICANN Annual Report prepared by Staff.

5. Better align the PDP process with ICANN’s strategic plan and operations plan. The Council, constituencies and staff should publish an annual “policy development plan” for current and upcoming work, to better align resources with strategic objectives, and to create a stronger nexus between the work plan of the GNSO Council and the ICANN planning process. The plan should be linked to ICANN’s overall strategic plan, but be sufficiently flexible to accommodate changes in priority determined by rapid evolution in the DNS marketplace and unexpected initiatives.

6. Contain rules, processes and procedures that are more effective and efficient and that meet consensus policy requirements as detailed further in the Report, to include specifying certain policy activities that should be done, including: research, consultation with constituencies, periods for public comment, timelines consistent with the complexity of the task, regular reporting to the Council as established in the scoping phase, and a final report and public comment period as in the current PDP.

The PDP Team shall work independently from, but in close consultation with, the Working Group Team of the Policy Process Steering Committee (PPSC). The Policy Development Process Team shall be responsible for making recommendations concerning the development of and transition to a new PDP for PPSC review.

ANNEX III - The Working Group

Following the adoption of the charter by the GNSO Council, a call for volunteers was launched. The following individuals are part of the PDP-WT. Statements of Interests can be found here.

NAME	AFFILIATION	Meetings Attended
Sophia Bekele	Individual	6
James Bladel	Registrar	35
Marilyn Cade	Individual	11
Bertrand de la Chapelle	GAC	4
Paul Diaz	Registrar	32
Avri Doria	NCA/NCSG[4	#_ftn4]	17
J. Scott Evans (Observer)	IPC	0
Alex Gakuru	NCUC	15
Alan Greenberg	ALAC	26
Tony Harris	ISP	1
Wolf-Ulrich Knoben	ISP	23
Tatyana Khramtsova	Registrar	24
Cheryl Langdon-Orr	ALAC (Alternate)	1
Zbynek Loebl	IPC	1
David Maher	RyC	25
Jeff Neuman (Chair)	RyC	34
Gabriel Pineiro	NCUC	9
Mike Rodenbaugh	CBUC	8
Kristina Rosette	IPC	1
Greg Ruth	ISP	1
Antonio Tavares	ISP	0
Jean-Christophe Vignes	Registrar	2
Jaime Wagner	ISP	1
Liz Williams	CBUC	2
Brian Winterfeldt	IPC	9

To view the attendance sheet, please click here.

Annex IV - List of Recommendations

Recommendation 1.

§ Although a request for an Issues Report has never been issued directly by the ICANN Board, or any Advisory Committee (other than the At-Large Advisory Committee), the PDP-WT recommends that the current three mechanisms for initiating a request for an Issues Report should be maintained.

Recommendation 2.

§ The current language in Annex A of the by-laws continuous several references to the PDP which over the years have been the source of confusion. It not only refers to the PDP in terms of initiating an issues report, for example, but also in terms of formally establishing Task Forces or working groups. Therefore, the PDP-WT has divided the two concepts (1) Raising an Issue and (2) Initiation of a PDP and has recommended clarification of this language in the Bylaws (see section 3).

Recommendation 3.

§ The PDP-WT recommends the development of a Policy Development Process manual or guidebook, which will constitute an integral part of the GNSO Rules of Procedure, intended to provide guidance and suggestions to the GNSO and ICANN communities on the overall PDP process, including those steps that could assist the community, working group members, and Councillors in gathering evidence and providing sufficient information to facilitate the overall policy development process.

Recommendation 4.

§ The PDP-WT recommends that a ‘request for an issues report’ template should be developed including items such as definition of issue, identification of problems, supporting evidence, and rationale for policy development. Further consideration would need to be given as to whether some of these elements should be required before a request is considered by the GNSO Council. Such a template should become part of the above mentioned Policy Development Process Manual or Guidebook.

Recommendation 5.

§ The PDP-WT recommends developing a Policy Development Process Manual or Guidebook, which could be an integral part of the GNSO Rules of Procedure, that provides guidance and suggestions to those parties raising an issue on which steps could be considered helpful in gathering evidence and providing sufficient information to facilitate the overall policy development process.

Recommendation 6.

§ No changes to the By-laws are recommended in relation to the creation of the Issues Report by the PDP Work Team . The PDP-WT recommends including in the Policy Development Process Manual or Guidebook a recommendation for the entity requesting the issues report to indicate whether there are any specific items they would like to see addressed in the issues report, which could then be taken into consideration by the Council when reviewing the request. In addition, guidance could be provided in the Policy Development Process Manual or Guidebook that the Council and/or Staff could provide advice ahead of a vote on the request for an issues report whether they feel additional research, discussion, or outreach should be conducted as part of the development of the issues report, in order to ensure a balanced and informed Issues Report.

Recommendation 7.

§ The PDP-WT recommends better information and communication with Working Group members on the potential outcomes of a policy development process. Contrary to the belief of a number of members of the community, there are more potential outcomes of the PDP process than just the formation of “consensus policies” as defined under the applicable gTLD Registry and Registrar agreements. Acceptable outcomes include the development of best practices, recommendations to other supporting organizations, recommendations for future policy development, etc. This information could be included in the Charter of a Working Group or in the instructions to a WG. It is also an element that should be included in the Policy Development Process Manual or Guidebook.

Recommendation 8.

§ The PDP-WT recommends retaining the requirement for obtaining the opinion of the ICANN General Counsel in the Issues Report as whether a proposed PDP is within the scope of the GNSO. Further details regarding the opinion of counsel are expected to be included in the PDP rules of procedure as opposed to the Bylaws.

Recommendation 9.

§ The PDP-WT recommends that additional guidance on the different roles ICANN staff can perform, as outlined in the GNSO Working Group Guidelines, is to be included in the Policy Development Process Manual or Guidebook.

Recommendation 10.

§ The PDP-WT recommends the modification of timeframes included in clause 1 – Creation of an Issues Report in Annex A in relation to the development and delivery of an issues report. The following options are being explored:

e) Setting a maximum timeframe (e.g. 30-45 days) in the By-Laws which can be modified on the request of ICANN Staff with the agreement of the GNSO Council or the Issues Report requestor (if requested by an Advisory Committee or the ICANN Board); or

f) Request that ICANN staff provide the GNSO Council with an estimate of time it would take for the ICANN Staff to complete an issues report taking into account the complexity of the issue and the ICANN staff workload.

Recommendation 11.

§ The PDP-WT recommends that that there should be a public comment period that follows the publication of an Issues Report and before the GNSO Council is asked to consider the initiation of a PDP. Such a Public Comments period would, among other things, allow for additional information that may be missing from the Issues Report, or the correction or updating of any information in the Issues Report. In addition, this would allow for the ICANN Community to express their views to the Council on whether to initiate a PDP or not.

Recommendation 12.

§ The PDP-WT recognizes the value of workshops on substantive issues prior to the initiation of a PDP. It is therefore recommending that information on the potential role of workshops and information gathering events be provided in the Policy Development Process Manual or Guidebook. In addition, the PDP-WT recommends that the GNSO Council should consider requiring such a workshop during the planning and initiation phase for a specific issue.

Recommendation 13.

§ The PDP-WT recommends that the Policy Development Process Manual or Guidebook describe the option for the GNSO Council to require that an impact analysis be conducted if appropriate or necessary prior to the vote for the initiation of a PDP. Such an impact analysis could include the assessment of the economic impact, the impact on competition, the impact on consumer choice and/or protection, etc.

Recommendation 14.

§ The PDP-WT believes that the GNSO Council should prioritize PDPs and ensure that the resources exist (both staff and volunteer) upon the initiation of a PDP. In light of the upcoming GNSO Council Prioritization activity, the PDP-WT is deferring the specifics of how such prioritization can be achieved pending the outcome of such activity.

Recommendation 15.

§ The PDP-WT is considering the notion of having a fast-track procedure that would allow for a more timely PDP in cases where such urgent action is deemed to be necessary while at the same time ensuring broad participation and avoiding gaming. The PDP-WT hopes to receive further input from the community on which elements such a procedure should contain and how it would work in practice, during the public comment period.

Recommendation 16.

§ The PDP-WT recommends modifying the timeframes included in clause 3 – Initiation of a PDP to reflect current practice and experience. In addition, it proposed to add language to codify the current practice that any Stakeholder Group and/or Constituency can request the deferral of the consideration of an initiation of a PDP for one Council meeting (see section 3 for proposed new language).

Recommendation 17.

§ The PDP-WT recommends that further guidance be included in the Policy Development Process Manual or Guidebook on how to deal with situations where further flexibility is required e.g. additional research, ensuring that the Council provides clear indications on expected timing of next steps.

Recommendation 18.

§ The PDP-WT recommends that no special formal appeals mechanism be developed. However, the PDP-WT recommends that the GNSO Council be required to state its reasons for denying to Initiate a PDP after receipt of an Issues Report.

Recommendation 19.

§ The PDP-WT recommends to update clause 7 of Annex A of the ICANN by-laws to reflect that a charter is required for Working Groups and to include the voting threshold that should apply to the adoption of the working group charter which is identical to the one that applies to the initiation of the PDP (see section 3 for proposed new language).

Recommendation 20.

§ The PDP-WT recommends to working with the WG-WT/PPSC to provide input for the GNSO Working Group Guidelines section or annex that will be dedicated to a PDP WG concerning best practices for developing the charter for a PDP WG.

Recommendation 21.

§ The PDP-WT recommends that further guidance on how to involve Advisory Committees or Supporting Organisations are to be included as part of the Policy Development Process Manual or Guidebook.

Recommendation 22.

§ The PDP-WT recommends that further guidance on the options the GNSO Council has at its disposal to take an informed decision to be included as part of the Policy Development Process Manual or Guidebook.

Recommendation 23.

§ The PDP-WT recommends modifying clause 6 – public notification of initiation of the PDP to reflect current practice whereby a public comment period is initiated once a Working Group has been formed, not when the PDP is initiated to allow the WG to put out specific issues for public comment that might help inform its deliberations. The PDP-WT is considering whether this should be a mandatory or optional public comment period and hopes to receive further input on this issue during the public comment period.

Recommendation 24.

§ The PDP-WT recommends modifying clause 3 – Initiation of a PDP to clarify that within scope means ‘within scope of ICANN’s mission and more specifically the role of the GNSO’ as opposed to within scope of the contracted parties’ definition of “consensus policies”.

Recommendation 25.

§ The PDP-WT recommends that each PDP WG will be strongly encouraged to review the GNSO Working Group Guidelines that include further information and guidance on the functioning of GNSO Working Groups.

Recommendation 26.

§ The PDP-WT recommends that further guidance is to be provided on which mechanisms are available to a WG to communicate with different ICANN departments in the Policy Development Process Manual or Guidebook. Suggested approach would be for ICANN policy staff to serve as the intermediate between a WG and the various ICANN departments (finance, legal, compliance, etc.), provided that a procedure is in place which allows for escalation via the WG Chair if the WG is of the opinion that communication is hindered through the involvement of ICANN policy staff.

Recommendation 27.

§ The PDP-WT has not arrived at a possible recommendation in relation to this issue yet and hopes to receive further input on this issue during the public comment period.

Recommendation 28.

§ The PDP-WT recommends modifying clause 9 of Annex A of the ICANN by-laws to change the duration of the public comment period on the Initial Report from twenty to a minimum of thirty calendar days (see section 3 for proposed new language).

Recommendation 29.

§ The PDP-WT recommends modifying clause 9 of Annex A of the ICANN by-laws to reflect the current practice that a summary and analysis of the public comments received is to be provided by the staff manager to the Working Group who will be responsible for reviewing the public comments received (see section 3 for proposed new language).

Recommendation 30.

§ The PDP-WT recommends providing further guidance on how to conduct public comment periods and review public comments received as part of the Policy Development Process Manual or Guidebook.

Recommendation 31.

§ The PDP-WT recommends that PDP WGs provide input on issues related to implementation, impact (economic, business, social, operational, etc.) and feasibility and is considering the following options:

o Require the inclusion of implementation guidelines as part of the Final Report;

o Consultation with the WG / Council on the draft implementation plan;

o The creation of an implementation team that consists of representatives of the WG, amongst others, which would be tasked to review / provide input during the implementation phase

The PDP-WT hopes to receive further input on these options during the public comment period. (see also recommendation 42)

Recommendation 32.

§ The PDP-WT recommends that staff resources needed or expected in order to implement the policy recommendations should be evaluated as part of the WG recommendations, and as part of the Council’s review of those recommendations, as part of the feasibility analysis and/or impact statement (see recommendation 31).

Recommendation 33.

§ The PDP-WT recommends amending clause 7 of Annex A of the ICANN by-laws to reflect the practice that Stakeholder Group / Constituency statements are requested by the Working Group and the timeline for submission should start from that point instead of the initiation of the PDP (see section 3 for proposed new language).

Recommendation 34.

§ The PDP-WT recommends that PDP Working Groups continue to be required to produce at least an Initial Report and a Final Report, noting that more products (as described in the full report below) can be produced if desirable.

Recommendation 35.

§ The PDP-WT does note that the description of the difference between an Initial Report and a Final Report as currently described in the By-Laws is not in line with actual practice, and recommends that this language is updated to reflect that an Initial Report may reflect the initial ideas of a WG which are then finalized, in combination with review and analysis of the public comment period in the second phase leading to the Final Report.

Recommendation 36.

§ The PDP-WT recommends that a public comment period on the Initial Report remains mandatory. Additional guidance on further optional public comment periods, e.g. when there are substantial differences between the Initial Report and Final Report should be included as part of the Policy Development Process Manual or Guidebook.

Recommendation 37.

§ The PDP-WT recommends modifying clause 10 – Council Deliberations of Annex A of the ICANN by-laws to reflect current practice and requirements in the rules of procedure to consider a report if it is received at least eight days in advance of a Council meeting, otherwise the report shall be considered at the next Council meeting. In addition, the PDP-WT is considering recommending adding language to codify the current practice that any Stakeholder Group and/or Constituency can request the deferral of the consideration of a final report for one Council meeting (see section 3 for proposed new language).

Recommendation 38.

§ The PDP-WT recommends to provide additional guidance to GNSO Council in the Policy Development Process Manual or Guidebook on how to treat Working Group recommendations, especially those that have not received full consensus and the expected / desired approach to adoption of some, but not all, or rejection of recommendations. There is discussion within the PDP-WT whether the GNSO Council should have the flexibility to ‘pick and choose’ recommendations. There is no agreement yet on what guidance, if any, should be given on recommendations that have not received full consensus. The PDP-WT hopes to receive further input on this issue during the public comment period.

Recommendation 39.

§ The PDP-WT recommends that the GNSO Council is responsible for the Board Report either as author of the report or to approve the report before it is sent to the Board. The PDP-WT discussed at length the current practice of ICANN Policy Staff submitting a separate report to the Board which is never disclosed to the community, noting that this is not directly related to the PDP, and unanimously believe that this practice should no longer continue. Reports on PDPs should be delivered from the GNSO Council directly to the Board and if any summaries are needed, that should be the responsibility of the Council with the help of the Working Group (if necessary). The PDP-WT has discussed ways in which to make the report more focused and easier to digest, but has not agreed on a possible recommendation in relation to this issue yet and hopes to receive further input on this issue during the public comment period.

Recommendation 40.

§ The PDP-WT has discussed whether the voting thresholds might need to be reviewed (see also overarching issues) but has not arrived yet at a possible recommendation in relation to this issue and hopes to receive further input on this issue during the public comment period.

Recommendation 41.

§ The PDP-WT recommends that the provisions in relation to the Board Vote in the ICANN By-Laws remain essentially unchanged, noting that a clarification might be required to provision 13f to clarify what ‘act’ means -- (13 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’ - see also overarching issues section 8).

Recommendation 42.

§ The PDP-WT recommends creating a WG Implementation Review Team, which would be responsible in dealing with implementation issues. The PDP-WT has not arrived yet at a possible recommendation in relation to how the process for reviewing and addressing implementation questions would work and hopes to receive further input on this issue during the public comment period. (see also recommendation 31)

Recommendation 43.

§ The PDP-WT notes that a periodic assessment of PDP recommendations and/or policy is important but has arrived at any possible recommendations yet and hopes to receive further input on this issue during the public comment period.

Recommendation 44.

§ The PDP-WT notes that the GNSO Council Review of a PDP Working Group is important but has not arrived at any possible recommendations yet and hopes to receive further input on this issue during the public comment period.

Recommendation 45.

§ The PDP-WT notes that the periodic assessment of the overall PDP process is important but has not arrived any possible recommendations yet and hopes to receive further input on this issue during the public comment period.

[1|#_ftnref1] See https://st.icann.org/data/workspaces/icann-ppsc/attachments/pdp_team:20090604091634-1-14428/original/Summary%20of%20contribution%20of%20Thomas%20Narten.pdf

[2|#_ftnref2] 7. ICANN commits to adhere to transparent and accountable budgeting processes, fact-based policy development, cross-community deliberations, and responsive consultation procedures that provide detailed explanations of the basis for decisions, including how comments have influenced the development of policy consideration, and to publish each year an annual report that sets out ICANN's progress against ICANN's bylaws, responsibilities, and strategic and operating plans. In addition, ICANN commits to provide a thorough and reasoned explanation of decisions taken, the rationale thereof and the sources of data and information on which ICANN relied.

[3|#_ftnref3] It should be noted that ICANN also has other conflict resolution mechanisms available that could be considered in case any of the parties are dissatisfied with the outcome of this process.

[4|#_ftnref4] NCA until 26 Oct 09, NCSG after

Content

Space Tools

Initial Report Clean Version Update May 2010

1 Executive Summary

2 Approach taken

3 Stage I - Planning and Request for an Issues Report

4 Stage II – GNSO Council Review of the Issues Report and Initiation of the Policy Development Process

5 Stage III – Working Group

6 Stage IV – Voting and Implementation

7 Stage V – Policy Effectiveness and Compliance

8 Overarching Issues

9 New PDP Flow Chart – Basis for new Annex A

ANNEX I - Background

ANNEX II - Working Group Charter

ANNEX III - The Working Group

Annex IV - List of Recommendations