Skip to main content

Public Comment: Proposed New GNSO Policy Development Process | PDP-WT presents its Proposed Final Report

As part of GNSO Improvements, the Policy Development Process (PDP) Work Team (WT) was tasked to develop recommendations for a new GNSO policy development process. ICANN's policies have wide-ranging impact on how domain names are handled in the gTLD environment, so the method of developing the policies matters. Following review of the comments received on its Initial Report and continued deliberations on remaining issues, the PDP-WT now publishes its Proposed Final Report which contains amongst others forty-eight (48) recommendations, an outline of the proposed new Annex A as well as a supporting document that is envisioned to be included in the GNSO Council Operating Procedures as the PDP Manual. Before finalizing its report and submitting it to the GNSO Council for its consideration, the Working Group is asking for your input. The public comment forum will be open until 1 April 2011.

For those interested, the PDP-WT will present its report and the proposed new GNSO Policy Development Process at the ICANN meeting in San Francisco (see for further details).

Key Recommendations

  • Some of the key recommendations of the new PDP include:
    • Recommending the use of a standardized “Request for an Issue Report Template” (recommendation 4)
    • The introduction of a “Preliminary Issues Report” which shall be published for public comment prior to the creation of a Final Issues Report to be acted upon by the GNSO Council (recommendations 10 & 11).
    • A Requirement that each PDP Working Group operate under a Charter (recommendation 19)
    • Dialogue between the GNSO Council and an Advisory Committee in the event that an the GNSO Council decides not to initiate a PDP following an Issues Report requested by such Advisory Committee (recommendation 18)
    • Changing the existing Bylaws requiring a mandatory public comment period upon initiation of a PDP to optional at the discretion of the PDP Working Group (recommendation 22)
    • Clarification of ‘in scope of ICANN policy process or the GNSO' (recommendation 23)
    • Changing the timeframes of public comment periods including (i) a required public comment period of no less than 30 days on a PDP Working Group's Initial Report and (ii) a minimum of 21 days for any non-required public comment periods the PDP WG might choose to initiate at its discretion (recommendation 28)
    • Maintaining the existing requirement of PDP Working Groups producing both an Initial Report and Final Report, but giving PDP Working Groups the discretion to produce additional outputs (recommendation 34)
    • A recommendation allowing for the termination of a PDP prior to delivery of the Final Report (recommendation 37)
    • Guidance to the GNSO Council on the treatment of PDP WG recommendations (recommendation 39)
    • New procedures on the delivery of recommendations to the Board including a requirement that all reports presented to the Board are reviewed by either the PDP Working Group or the GNSO Council and made publicly available (recommendation 40)
    • The use of Implementation Review Teams (recommendation 43)
    • A redefinition of ‘GNSO Supermajority vote' to include the original meaning of GNSO Supermajority i.e. 2/3 of Council members of each house so a GNSO Supermajority vote would be 75% of one House and a majority of the other house or 2/3 of Council members of each house (recommendation 48)

For a complete overview of all the recommendations, please see Section 2 of the Proposed Final Report.


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

Further Information

PDP-WT Proposed Final Report – [PDF, 1.21 MB]
PDP-WT Proposed Final Report – Executive Summary Only – [PDF, 580 KB]
PDP-WT Proposed Final Report – Executive Summary& Recommendations PDP-WT Proposed Final Report – without annexes – [PDF, 998 KB]
PDP-WT Initial Report – [PDF, 2.36 MB]
PDP-WT Workspace -
GNSO Improvements -

Deadline and how to submit comments

Comments are welcome via e-mail to until 1 April 2011.
Access to the public comment forum from which comments can be posted can be found at
An archive of all comments received will be publicly posted at

Staff responsible: Marika Konings

More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."