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


In brackets, those PI WG members that have indicated that they either participated in the effort or would like to contribute to developing the table for that specific effort.


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

  1. Staff letter suggesting possibilities for GAC/GNSO collaboration on RC/IOC protections: http://gnso.icann.org/correspondence/pritz-to-dryden-11aug11-en.pdf (August 2011)
  2. Formation & work of RC-IOC Drafting Team: http://gnso.icann.org/en/group-activities/active/ioc-rcrc (Sept/Oct 2011) (Alan, Chuck, Greg)
  3. GNSO Council responses to Board requests concerning IGO protections [1] : http://gnso.icann.org/correspondence/gnso-to-board-igo-names-26mar12-en.pdf (March 2012)   ; http://gnso.icann.org/en/correspondence/robinson-to-icann-board-07nov12-en.pdf (Nov 2012) (Alan, Chuck, Greg)
  4. Board request for GNSO to consider defensive registrations at the second level in the New gTLD Program: http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-10apr12-en.htm (Apr 2012)
  5. GNSO feedback on WHOIS Review Team Final Report: http://gnso.icann.org/en/correspondence/robinson-to-icann-board-07nov12-en.pdf (Nov 2012)
  6. Correspondence on TMCH “strawman” proposal: http://gnso.icann.org/en/correspondence/chehade-to-robinson-04dec12-en.pdf (Dec 2012 request); http://gnso.icann.org/en/correspondence/robinson-to-chehade-28feb13-en.pdf (Feb 2013 response) (Avri)
  7. Development of TMCH “strawman ” proposal:   http://www.icann.org/en/news/public-comment/tmch-strawman-30nov12-en.htm (November 2012) (Avri, Alan, Greg)
  8. Response to Board request on “closed generics”: http://gnso.icann.org/en/correspondence/robinson-to-crocker-chalaby-07mar13-en.pdf (Mar 2013) (Greg, Anne)
  9. Correspondence on “string similarity”: http://gnso.icann.org/en/correspondence/robinson-to-crocker-chalaby-18sep13-en.pdf (Sept 2013 Council letter); http://gnso.icann.org/en/correspondence/chalaby-to-robinson-24oct13-en.pdf (Oct 2013 NGPC response)
  10. GNSO Council comments on ATRT2 recommendations: http://gnso.icann.org/en/correspondence/council-comments-atrt2-recommendations-13dec13-en.pdf (Dec 2013)
  11. Board request concerning .brand RA, Specification 13: http://gnso.icann.org/en/correspondence/chalaby-to-robinson-03apr14-en.pdf (Apr 2014)
  12. Implementation Recommendation Team (April 2009):   http://gnso.icann.org/en/group-activities/inactive/2009/trademark-protection-irt (April 2009)   ( Alan )

Review relevant documents  - possible sub-committee or 1 person per effort


Staff to develop table / chart to be used for this efforts as a starting point, to be further completed based on input from participants in the different efforts listed.


The following elements would need to be included in the table:

  1. What triggered it?
  2. Strong points / weak points
  3. Time constraint
  4. ‘Threat’
  5. What steps / procedures were followed – methodology
  6. Duration / what time it took complete
  7. Selection methodology and composition of the group (which interests were represented)
  8. Who framed the issue or how was the issue framed?
  9. Nature of the outcome (e.g. letter, report)
  10. Methodology for selecting membership (open, selected by someone?)
  11. Was public comment solicited (and if so, how)?


Aim to have first draft of table available by next week ’s meeting but consider incorporating comments first before brining it back to the whole group.

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.

Review of B postponed until after A, C and D have been reviewed / addressed.

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? 

Take one question at a time for WG review / discussion – if needed, sub-team could be formed to further deliberate and develop proposed response.

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?


Use similar approach as for C (once A has been completed)

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?


Probably tackle after work has been completed on A-D




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