Skip to main content
Resources
Graphic of How are gTLD Policies Implemented?

PDF versions available in: English | العربية | Español | Français | Português | Pусский | 中文

Implementing Policy at ICANN

A fundamental part of ICANN's mission is to coordinate policy development related to the Internet's system of unique identifiers. Policy development for gTLDs is carried out through a multi-stakeholder, bottom-up process. Once developed, ICANN's Global Domains Division (GDD) brings these policies to life.

How Does the Global Domains Division Implement Policy?

GDD staff actively monitor and participate in all gTLD policy development processes to deliver a smooth transition from policymaking to implementation to the final enactment of a Consensus Policy. GDD staff consult with the community—through implementation review teams and other means—throughout the implementation process to ensure that the intent underlying Consensus Policy recommendations is reflected in the policy's implementation.

GDD uses a standard process to implement gTLD Consensus Policy recommendations, and to support predictability, accountability, transparency and efficiency in Consensus Policy implementation work.

(Read and download a detailed PDF version of the Consensus Policy Implementation Framework here)

Each policy implementation project occurs according to the following stages as detailed in the framework:

  • Prepare: GDD staff will follow policy development activities to engage on implementation-related matters, as appropriate. Consideration and feedback to policy work products and Consensus Policy recommendations as it relates to implementation will occur through the various phases of the GNSO Policy Development Process. The Board's approval of Consensus Policy recommendations marks the formal endpoint of this phase.

  • Plan: Policy and GDD staff arrange for the recruitment of the IRT at the beginning of this stage. Policy formally hands off the project to GDD for implementation. GDD staff will organize the activities required to implement Consensus Policy recommendations. A project plan with complete work breakdown structure is the primary output; including a draft requirements document. GDD's initial contacts with relevant service providers and the Implementation Review Team (IRT) will occur during this stage. This phase is completed when the implementation project plan is posted.

  • Analyze and Design: GDD staff will work with the IRT, if convened, during this stage to develop and complete new Consensus Policy language (if required) and any new service that may be needed. Public comments regarding the implementation will also be solicited at this stage. This stage is completed when the final implementation and effective date is announced.

  • Implement: GDD staff will announce final implementation details to the community and conduct targeted outreach to contracted parties during this phase. The implementation project is formally handed off from GDD to Contractual Compliance staff at the conclusion of this phase, when the Consensus Policy goes into effect.

  • Support and Review: GDD staff may serve as a resource to Contractual Compliance in its enforcement of new Consensus Policies. GDD staff may also review Consensus Policy implementations.

Policy Change Calendar and Implementation Project Status

GDD launched a new Policy Change Calendar initiative in May 2015. GDD staff will bundle gTLD Consensus Policy implementation effective dates into six-month cycles based on the estimated timing of GNSO Council approval and Board adoption of Consensus Policy recommendations.

As the implementation projects in each bundle near completion, GDD staff will officially announce the implementation bundle's effective date. The effective date will be at least six months after the announcement. For example, GDD staff might announce on Feb. 15 that a bundle will go into effect on Aug. 15 of that year.

These procedures are being established on a trial basis, and will be reviewed for possible modifications after they have been in use for at least one year.

(A full description of the Policy Change Calendar initiative is available here)

Last updated on ​12 April 2016

Project Board Approval Date Estimated Time to Complete Phase Current Status

Projected Effective Date

Links
Thick Whois February 2014 2+ years Analyze and Design

Public comment periods for RDAP Operational Profile and draft Thick RDDS Consensus Policy for Consistent Labeling and Display Requirement for All gTLDs closed 18 March 2016, with staff reports expected by 18 April 2016

Consistent Labeling and Display: July 2017

Transition from Thin to Thick: July 2017 - December 2017

IRT Project Workspace

GNSO PDP Page

Protection of IGO/INGO Identifiers in All gTLDs 7 February 2014 (approval requesting review and analysis of GAC advice on INGO protections) 1 year (+review and analysis of GAC advice on INGO protections) Plan

IRT generally agreed to latest Consensus Policy outline

Includes top- and second-level protection mechanisms
Includes identifiers-to-DNS matching rules

Project team working with IRT on lists of DNS labels and related challenges
Implementation of claims protection next priority for IRT

 

July 2017 GNSO PDP Page
Inter-Registrar Transfer Policy C (IRTP C) December 2012 3 years Implement Final implementation published and new transfer policy goes into effect 1 August 2016 1 August 2016 (actual)

Transfer Policy Amendments and Effective Date Announced

Change of Registrant Policy

ICANN Meeting Session: White Boarding Session With IRTP-C IRT

GNSO PDP Page

Inter-Registrar Transfer Policy D (IRTP D) February 2015 1 year Analyze and Design

Updated TDRP and Transfer Policy posted for public comment 10 November 2015

Public comment closed 21 December 2015

January 2017

GNSO PDP Page

IRT Workspace

Translation and Transliteration of Contact Information September 2015 18 months Plan

Project now proceeding following Board resolution adopted during ICANN55, which directs T/T implementation team to incorporate the technical (i.e. non-policy) recommendations of the Internationalized Registration Data Working Group into the T/T implementation project (Board resolutions 2016.03.10.05 - 2016.03.10.07)

Staff exploring options for IRT deployment

Implementation plan draft expected to be complete in May 2016

June 2017 GNSO PDP Page

IGO/INGO Access to Curative Rights Protection Mechanisms

Q1 2016 (Estimated)

6 months

Prepare

Working group met 16 December, awaiting draft report from external legal expert by late April

Next meeting not yet scheduled

January 2017 GNSO PDP Page

Privacy/Proxy Accreditation

May 2016 (Estimated)

18+ months

Prepare

GNSO Council scheduled to consider motion to approve recommendations from staff's Final Report in May

GNSO Council adopted Working Group's Final Report at 21 January 2016 meeting

Public comment on PDP recommendations for Board consideration closed 16 March 2016, with staff report expected by 18 April 2016

January 2018 GNSO PDP Page
Next-Generation gTLD Registration Directory Service to Replace WHOIS (Next-Gen RDS) TBD TBD upon publication of WG work plan Prepare

Working Groups next meeting held on 12 April 2016

Discussions centered on work plan

PDP Working Group Charter adopted at GNSO Council meeting on 19 November 2015

Call for volunteers for Working Group initiated 4 January 2016

Initial meeting held 26 January 2016

TBD upon publication of WG work plan GNSO Wiki Page

Items in blue are current GNSO policy development processes that may result in Consensus Policy recommendations. Should such recommendations be adopted by the ICANN Board, they will then become formal implementation projects.

What is the Global Domains Division?

The Global Domains Division is the unit of ICANN that engages the Internet community to implement ICANN policies for gTLDs through contracts and services, and delivers IANA functions.

The objective of the GDD is to serve the global public interest, registrants and end users of the Internet by ensuring a secure, stable and resilient domain name system, while promoting trust, choice and competition in the trusted domain name service industry.

Questions? Comments?

Please send any inquiries or comments to: [email protected]

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""icann.org"" is not an IDN."