Skip to main content

The New GNSO Policy Development Process Presented for Approval | Policy Development Process Work Team Submits its Final Report

The Policy Development Process Work Team (PDP-WT) was tasked to develop a new GNSO policy development process that incorporates a working group approach and makes it more effective and responsive to ICANN's policy development needs. Today, the PDP-WT has submitted its Final Report [PDF, 1.39 MB] to the GNSO Council for its consideration. The Final Report contains amongst others forty-seven (47) 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.

The Recommendations include amongst others:

  • Recommending the use of a standardized "Request for an Issue Report Template"
  • 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
  • A Requirement that each PDP Working Group operate under a Charter
  • 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
  • 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
  • Clarification of 'in scope of ICANN policy process or the GNSO'
  • 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
  • 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
  • A recommendation allowing for the termination of a PDP prior to delivery of the Final Report
  • Guidance to the GNSO Council on the treatment of PDP WG recommendations
  • 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
  • The use of Implementation Review Teams

Further details and background on the different recommendations, the proposed Annex A and PDP Manual can be found in the PDP-WT Final Report [PDF, 1.39 MB]. The GNSO Council will now consider this Final Report for adoption.


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 revised PDP, after review and approval by the GNSO Council and ICANN Board, would replace the current PDP defined in Annex A of the ICANN bylaws.

Further Information:

PDP-WT Final Report – [PDF, 1.39 MB]

Proposed Final Report Public Comment Review Tool – [PDF, 196 KB]
PDP-WT Proposed Final Report – [PDF, 1.21 MB]
PDP-WT Initial Report – [PDF, 2.35 MB]
PDP-WT Workspace –
GNSO Improvements –

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