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 ​16 March 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 period for draft Thick RDDS Consensus Policy for Consistent Labeling and Display requirement for all gTLDs closed 15 February 2016
  • RDAP Operational Profile public comment period closed 15 February 2016
  • Transition from Thin to Thick
    • Implementation Review Team (IRT) discussing phased/decoupled implementation plan
    • New registrations would be transitioned independently from existing registrations, with each track following own timeline
    • IRT to meet with Registry Stakeholder Group at ICANN55 to recruit volunteer registrars to contribute to study of current registration data and determine type and magnitude of challenges they will face transitioning .com, .net, and .job registrations from Thin to Thick
  • 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)
  • Recruitment of Implementation Review Team now in progress
  • Implementation plan draft expected to be complete by mid- to late April 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 that is likely to be delivered week of 8 February 2016
  • 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 open 5 February 2016 to 16 March 2016
  • Registrar Services staff drafting strawman implementation framework for internal discussion during week of 15 February 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
  • 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."