Deliverable I - Propose process for developing gTLD and other ICANN policy in the form of GNSO "Policy Development Process" and "Policy Guidance" and propose criteria for determining when each would be appropriate


(Derived from Charter Question II - A process for developing gTLD policy, perhaps in the form of “Policy Guidance”, including criteria for when it would be appropriate to use such a process (for developing policy other than “Consensus Policy”) instead of a GNSO Policy Development Process)



Further Information

WG Discussion

A. Review mechanisms that the GNSO has used to date to develop policy / advice outside of the PDP (e.g. STI, SCI) and what lessons can be learned from those?

SCI Charter: https://community.icann.org/x/L4Hg

STI: http://gnso.icann.org/en/group-activities/inactive/2010/sti


Documentation & correspondence related to non-PDP, non-WG GNSO work & other GNSO Council advice:



B. Review draft process outlined in Staff Discussion Paper

From the Staff Discussion Paper : “The draft framework that can be found in the annex to this paper aims to outline a process for dealing with some of the issues that are outlined above. The starting premise would be that a proposed change is treated as an implementation change unless the objective is to create new obligations on certain parties (in which case a PDP may be appropriate. A proposed procedure, modeled on the existing process for changes to the new gTLD Applicant Guidebook, outlines the next steps depending on whether the proposed change is considered an: (i) administrative update, error corrections and clarification; (ii) change involving public consultation; or (iii) other changes as directed by the ICANN Board. Should as a result of public comments received, advice from Implementation Review Teams, SOs and/or ACs indicate that “Policy Guidance” is required, the issue would move to the “Policy Guidance” track. As outlined below, the suggestion is that each SO/AC identifies which processes are to be used for developing formal “Policy Guidance” [2] to the ICANN Board and that the Board clarifies how formal “Policy Guidance” from an SO/AC is to be considered. Some basic steps that could be part of such a “Policy Guidance” process have been included in the proposed framework for further discussion and refinement (Note: some SO/ACs may already have formal processes in place)”.

The Annex has also been included here at the end of the document.


C. Review ‘Questions for discussion’ contained in the Policy versus Implementation Draft Framework prepared by ICANN staff ( http://www.icann.org/en/news/public-comment/policy-implementation-31jan13-en.htm )

Questions for discussion


In addition to the issues outlined above and the proposed framework, there are a number of other questions that could be discussed in this context:


a)        The GNSO PDP process specifically discusses the implementation phase after the PDP recommendations are approved by the Board. Accordingly, should the level of implementation that should be part of the actual PDP be detailed? Should it be mandatory to form a Community Implementation Review Team whose task it is to provide guidance and/or clarification as needed to ICANN Staff as they develop the implementation plan?

b)       The Policies developed through a PDP have differing levels of detail included within the policy recommendations. For example, the recommendations on the expansion of new gTLDs were very high-level principles that necessitated the creation of a great amount of implementation detail. Alternatively, there are Policies such as the PEDNR recommendations, that include very particular details within the Policy – appearing to some to be implementation and policy in one or IRTP Part B where specific implementation proposals were asked from ICANN Staff which were then approved together with the policy recommendation. What guidance should there be on the level of particularity that PDP recommendations should embody and how/where should that be specified? It should be noted that if very specific implementation guidance is desired as part of the policy recommendations, specific expertise (legal, technical) will be needed by WGs developing such guidance.

c)        Particularly when policy recommendations are stated as high-level principles, ICANN may need more community involvement in reaching the implementation details. As part of this work, the Board has begun a process of soliciting “policy advice” – advice on whether specific implementation ideas are in-line with the principles stated in policies. This has been an area of confusion for the community, most recently with the Board request to the GNSO on IOC/Red Cross names. How can such a consultation mechanism, proposed above as a policy Guidance WG, be improved to clarify this advice-seeking role? Certain SO/ACs have mechanisms in place to develop a position on such requests from the Board (e.g. ccNSO), while others like the GNSO do not have a formal mechanism but have developed ad-hoc approaches depending on the request (e.g. STI, IOC/RC discussion group).

d)       One of the advisory-seeking mechanisms used recently was the IRT/STI process used in crafting the rights protection mechanism in the New gTLD Program. While some considered this “policy”, others considered this implementation of the principle that there must be a process to protect the rights of others when expanding the gTLD space. How could such consultation mechanisms be clarified to better explain the purpose and role and outcomes of the work requested? How can the work of these consultation mechanisms be updated to take into account input from other SO/ACs and the public?

e)        There should be recognition of the potential for overlap in responsibilities between an SO/AC and ICANN, such as when an issue can be the subject of a PDP, where it still may be appropriate for Staff or the Board to act. In ICANN’s multi-stakeholder bottom-up policy development structures, the inability to reach consensus on key issues could produce stalemates that by default preserve the “status quo” instead of enabling badly needed changes. Examples of this might be the vertical integration issue or the changes to the RAA. In addition, there may be instances where competing “policy advice” is given by different SO/AC. How is the Board expected to handle such situations?

f)         One distinction to consider between formal “P”olicies and little “p”olicies may be the expected longevity of the policy. For example, formal “P”olicies under the new GNSO PDP can only be modified after implementation by undergoing another formal PDP. This results in the formal “P”olicy becoming everlasting, and long lasting. In contrast, could a little “p”olicy adopted to meet the needs of a specific circumstance (example, the Conficker response) evolve based upon changing circumstances or experience with the effectiveness of the little “p”olicy? 


D. What lessons can be learned from past experience?
a. What are the consequences of an action being considered “policy” vs. “implementation?
b. Why does it matter if something is “policy” or “implementation”?
c. Under what circumstances, if any, may the GNSO Council make recommendations or state positions to the Board on matters of policy and implementation as a representative of the GNSO as a whole?
d. How do we avoid the current morass of outcome-derived labeling (i.e., I will call this policy because I want certain consequences/”handling instructions” to be attached to it)?
e. Can we answer these questions so the definitions of “policy” and “implementation” matter less, if at all?



E. What options are available for policy (“Consensus Policy” or other) and implementation efforts and what are the criteria for determining which should be used?
a. Are policy and implementation on a spectrum rather than binary?
b. What are the flavors of “policy” and what consequences should attach to each flavor?
c. What happens if you change those consequences?






From Staff Discussion Paper – Policy vs Implementation – Draft Framework

[1] Although this issue was by then subject to a full GNSO PDP, the relevant Board resolutions had specifically requested updates from the GNSO Council by certain deadlines laid out in the resolutions in question.

[2] There could also be circumstances in which the ICANN Board would directly ask for “Policy Guidance” from different SO/ACs (see section on Community Guidance and Input).