Skip to main content

Policy Implementation Updates

ICANN announces the implementation of two new consensus policy initiatives: the Additional Whois Information Policy (AWIP) and amendments to the Inter-Registrar Transfer Policy (IRTP) related to domain name unlocking.

These policies are applicable to all ICANN-accredited registrars and registry operators under contract with ICANN. These new requirements will take effect and will be enforced by ICANN as of 31 January 2015.

The updates include:

AWIP

The AWIP was developed with the goals of providing a better understanding of the existing domain name statuses (also known as EPP status codes) for Whois service users, and to create more uniformity among the multiple Whois outputs provided by ICANN-accredited registrars and gTLD registry operators. The AWIP requires each ICANN-accredited registrar and gTLD registry operator that displays Whois status codes to include in its Whois output a link to an ICANN web page where the existing domain names statuses are listed along with their respective meanings. (Note that the actual language of the AWIP, rather than the summary provided here, is binding on ICANN-accredited registrars and gTLD registries.)

Additionally, registries must identify the Globally Unique Registrar ID (GURID, also commonly known as an IANA ID) of the registrar that sponsors each registration in its Whois output.

The AWIP was developed from Generic Names Supporting Organization (GNSO) recommendations, which were adopted by ICANN's Board of Directors on 6 May 2012 and 20 December 2012. (https://www.myicann.org/2012-12-20-gnso-council-recommendations-irtp-part-c?language=fr) The recommendations included standardizing and clarifying Whois status messages (https://features.icann.org/2012-05-06-irtp-part-b-recommendation-8) and requiring registries to refer to registrars by their IANA IDs. (https://community.icann.org/display/gnsoirtppdpwg/3.+WG+Charter) The policy was drafted in consultation with the GNSO's IRTP Part B and IRTP Part C Working Groups, and was posted for public comment on 22 November 2011 (https://www.icann.org/resources/pages/irtp-b-staff-proposals-2011-11-22-en) and 22 October 2012 (https://www.icann.org/resources/pages/irtp-c-recommendations-2012-10-22-en) and adopted by the GNSO Council on 21 February 2012 (http://gnso.icann.org/resolutions/#201202) and 17 October 2012. (http://gnso.icann.org/en/resolutions#20121017-4)

All ICANN-accredited registrars and gTLD registries are required to comply with the AWIP by no later than 31 January 2015. A link to the AWIP can be found here  https://www.icann.org/resources/pages/consensus-policies-2012-02-25-en. A link to the EPP status code document can be found here: https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en. Links to the individual status codes are available here: https://www.icann.org/resources/pages/epp-status-codes-list-2014-06-18-en

IRTP Clarifications

ICANN is amending the Inter-Registrar Transfer Policy (IRTP) to implement the GNSO's recommendations related to locking and unlocking of domain names as a result of the IRTP Part B Policy Development Process (PDP). These changes came after significant collaboration and deliberation by the GNSO and other members of the ICANN community, and were approved by the ICANN Board of Directors on 16 March 2012.

The modifications are the following:

  1. Registrars will be obligated to inform their registrants in the registration agreement under which circumstances a domain name will be locked and how a domain name can be unlocked.
  2. Registrars will be obligated to unlock a domain name within five (5) calendar days of receiving a request to unlock a domain name from the registrant if the registrar does not provide facilities for the registrant to unlock the domain name.

A redline version of the policy showing changes is available here [PDF, 76 KB].

An updated version of the IRTP can be found here: https://www.icann.org/resources/pages/transfers-2012-02-25-en


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