Skip to main content

ICANN Requests Public Comments on Experiences with Inter-Registrar Transfer Policy

The Inter-Registrar Transfer Policy, a consensus policy developed through the ICANN policy development process, was finalized in July of this year and went into effect on 12 November 2004 after a four-month implementation phase. All ICANN-accredited registrars and unsponsored gTLD registry operators are required to follow this policy. Consistent with the policy recommendations of the GNSO Council’s Transfers Task Force, ICANN staff will report to the Council at three, six and twelve month intervals after implementation with the goal of determining;

i. How effectively and to what extent the policies have been implemented and adopted by Registrars, Registries and Registrants,

ii. Whether or not modifications to these policies should be considered as a result of the experiences gained during the implementation and monitoring stages,

iii. The effectiveness of the dispute resolution processes and a summary of the filings that have been resolved through the process.

In order to perform a meaningful evaluation, ICANN therefore invites any comments from the community on experiences with the initial stages following implementation of the policy, including any suggested modifications to be considered.

Comments submitted here will be publicly accessible and will be reviewed by ICANN staff for purposes of completing the required policy review. Comments for the first review should be submitted by 1 February 2005.

A. Standardized Forms of Authorization

The policy requires that specific standardized forms be used by registrars to obtain or confirm a registrant’s intent to transfer a domain to a new registrar.

Click here to submit comments about the standardized form(s) currently in use

Click here to view comments received on this topic

B. Dispute Resolution Processes

The Transfer Dispute Resolution Policy incorporates mechanisms for resolution of disputes between registrars over alleged violations of the policy. Dispute proceedings may be initiated with the relevant registry operator or with an independent third-party dispute resolution service provider.

Click here to submit comments about the dispute resolution policy

Click here to view comments received on this topic

C. Transfer Denial Reasons

The policy includes a list of 9 instances in which a transfer request may legitimately be denied by the Registrar of Record, as follows:

  1. Evidence of fraud
  2. UDRP action
  3. Court order by a court of competent jurisdiction
  4. Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact
  5. No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer.
  6. Express written objection to the transfer from the Transfer Contact. (e.g. - email, fax, paper document or other processes by which the Transfer Contact has expressly and voluntarily objected through opt-in means)
  7. A domain name was already in “lock status” provided that the Registrar provides a readily accessible and reasonable means for the Registered Name Holder to remove the lock status.
  8. A domain name is in the first 60 days of an initial registration period.
  9. A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs).

Click here to submit comments about this list

Click here to view comments received on this topic

D. Transfer Undo Mechanism

The policy provides that registry operators implement and make available a Transfer-Undo mechanism, to be used in cases where a transfer is determined to have been processed in contravention of the policy.

Click here to submit comments on the transfer undo mechanisms in use by the registries

Click here to view comments received on this topic

E. Records

The policy provides that registrars maintain copies of the forms of authorization and related documentation, and make these available upon request by the other registrar that is party to a transfer transaction, ICANN, the registry operator, a court or authority with jurisdiction over the matter, or a third party dispute resolution panel.

Click here to submit comments about the document retention requirements of the policy

Click here to view comments received on this topic

F. EPP – AuthInfo

For domain names in EPP-based registries (.biz, .info, .name, .org, and .pro), registrars are required to provide registrants with a unique Auth-Info code, for purposes of validating the identity of the registrant. Registrars are required to provide this code to registrants within 5 days of a request.

Click here to submit comments about the Auth-Info code requirements applicable to registrars in EPP-based registries

Click here to view comments received on this topic

G. General Comments

Click here to submit general comments about the effectiveness of the policy, or comments that relate to a topic not listed above

Click here to view comments received on this topic

For specific questions about the policy, please send an email message to This address is directed to staff who can answer policy inquiries. These messages are not publicly posted, although they may be reviewed to identify common issues.

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