Skip to main content

Inter-Registrar Transfer Policy Part C Policy Development Process

Comment Period Deadlines (*) Important Information Links
Public Comment Box
Open Date: 21 November 2011 To Submit Your Comments (Forum Closed)
Close Date: 22 December 2011 Time (UTC): 23:59 View Comments Submitted
Section I: Description, Explanation, and Purpose

The Inter-Registrar Transfer Policy Part C Policy Development Process Working Group is requesting your input on its Charter Questions to help inform its deliberations. The Charter Questions are:

  • "Change of Control" function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security.
  • Whether provisions on time-limiting Form Of Authorization (FOA)s should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold the FOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed.
  • Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.

For further information on these Charter Questions, please review the IRTP Part C Final Issue Report (see [PDF, 625 KB]).

In addition, the Working Group has identified the following specific issues / questions it would like to receive further input on:

  • In relation to charter question a), the Issue Report notes that ‘data on the frequency of hijacking cases is a pivotal part of this analysis. Mechanisms should be explored to develop accurate data around this issue in a way that meets the needs of registrars to protect proprietary information while at the same time providing a solid foundation for data-based policy making. Data on legitimate transfer activity benefitting from the current locking policy wording needs to be collected’.
  • In addition to the ccTLDs described in the Issue Report that do have a procedure or process for a ‘change of control’ (.ie, .eu and .uk) are there any other ccTLDs that have similar procedures or processes which the WG should review in the context of charter question a)? Furthermore, the WG would be interested to receive feedback on the experiences with these or other ccTLD procedures or processes for a ‘change of control’ as well as identifying potential benefits and/or possible negative consequences from applying similar approaches in a gTLD context.
  • In relation to charter question b) and c), the WG would be interested in further input or data in relation to the incidence of this issue to determine its scope and the most appropriate way to address it.
Section II: Background

The aim of the Inter-Registrar Transfer Policy (IRTP) is to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another. The GNSO Council is reviewing and considering revisions to this policy through a series of Working Groups it has established to conduct these efforts. The IRTP Part C Policy Development Process has just begun and the Working Group formed is requesting your input to help inform its deliberations, as required by the ICANN Bylaws.

Section III: Document and Resource Links

IRTP Part C Final Issue Report: [PDF, 625 KB]
Inter-Registrar Transfer Policy:

Section IV: Additional Information
Staff Contact: Marika Konings Email:

(*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses.

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