Skip to main content

Policy Implementation Update

ICANN announces the implementation of amendments to the Transfer Policy and the Transfer Dispute Resolution Policy (TDRP).

The amended Transfer Policy is applicable to all gTLD names and ICANN-accredited registrars. The amended TDRP is applicable to all gTLD names, ICANN-accredited registrars, and registries. These new requirements will take effect and will be enforced by ICANN beginning on 1 December 2016.

History

The GNSO Council unanimously voted to approve the consensus policy recommendations of the IRTP Working Group C on 17 October 2012. The ICANN Board adopted the recommendations of the GNSO Council on 20 December 2012. ICANN worked in consultation with the GNSO Implementation Review Team, which was formed as directed by the GNSO Council to work with ICANN, to ensure that the resultant implementation fulfills the intentions of the approved policy recommendations. The draft policy went through public comment on 30 March 2015. The updates were announced on 24 September 2015. Following subsequent feedback from members of the ICANN community, ICANN has updated the text of the Transfer Policy to address concerns and provided additional time for registrars to implement the revised Transfer Policy.

The GNSO Council unanimously adopted the recommendations of the IRTP Working Group D on 15 October 2014. The ICANN Board adopted the recommendations of the IRTP Part D Working Group on 12 February 2015. The Implementation Review Team in conjunction with ICANN staff worked together to develop a revised Transfer Dispute Resolution Policy (TDRP) as well as a revised Transfer Policy. The draft policy went through public comment on 10 November 2015.

Updates

The updates to the Transfer Policy include:

  1. Registrars must deny an inter-registrar transfer request if the registrar imposed a 60-day inter-registrar transfer lock following a Change of Registrant, and the Registered Name Holder did not opt out of the lock.
  2. The definition of Material Change, as it relates to a Change of Registrant, has been clarified.
  3. The required information in the notification to the Prior and New Registrant has been modified.
  4. Registrars must deny an inter-registrar transfer in the event of a URS proceeding that the registrar has been informed of.

A redline version of the Transfer Policy showing changes can be found here: https://www.icann.org/en/system/files/files/transfer-policy-redline-25may16-en.pdf [PDF, 552 KB]

An updated version of the Transfer Policy can be found here: https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en

The updates to the TDRP include:

  1. New definitions have been added.
  2. Registrars must file TDRP complaints with ICANN-approved dispute resolution providers and can no longer file TDRP complaints with registries.
  3. The statute of limitations to file a TDRP Complaint has been changed from 6 months to 12 months.
  4. The updated enumerated reasons for denying an inter-registrar transfer in the Transfer Policy have been added to the TDRP.
  5. Transfers from a Gaining Registrar to a third registrar, and all other subsequent transfers, are invalid if the Dispute Resolution Panel decides that the Gaining Registrar acquired the domain name(s) through an Invalid Transfer.
  6. In the event the Dispute Resolution Panel determines that an Invalid Transfer occurred, the domain shall be transferred back to the registrar that was the Registrar of Record immediately prior to the Invalid Transfer.
  7. TDRP Providers must publish TDRP decisions.

A redline version of the TDRP can be found here: https://www.icann.org/en/system/files/files/tdrp-redline-25may16-en.pdf [PDF, 370 KB].

An updated version of the TDRP can be found here: https://www.icann.org/resources/pages/tdrp-2016-06-01-en.

Questions about these policy changes may be directed to globalsupport@icann.org.


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