Skip to main content
Resources

Inter-Registrar Transfer Policy Part C Policy Development Process Initial Report

Comment/Reply Periods (*) Important Information Links
Comment Open: 4 June 2012
Comment Close: 4 July 2012
Close Time (UTC): 23:59 UTC Public Comment Announcement
Reply Open: 5 July 2012 To Submit Your Comments (Forum Closed)
Reply Close: 25 July 2012 View Comments Submitted
Close Time (UTC): 23:59 UTC Report of Public Comments
Brief Overview
Originating Organization: GNSO Working Group
Categories/Tags: Policy Processes
Purpose (Brief): The Generic Names Supporting Organization's (GNSO) Inter-Registrar Transfer Policy (IRTP) Part C Working Group has published its Initial Report and is looking for community input on its proposed recommendations for changes to the existing IRTP.
Current Status: As a required step of the GNSO Policy Development Process, the IRTP Part C Working Group has now published its Initial Report for public comment.
Next Steps: Following review of the public comments received, the Working Group will continue its deliberations and finalize its report for submission to the GNSO Council.
Staff Contact: Marika Konings Email: policy-staff@icann.org
Detailed Information
Section I: Description, Explanation, and Purpose

In addition to background information, an overview of the WG's deliberations and community input received to date, the Initial Report [PDF, 1.23 MB] contains the following four preliminary recommendations:

  • Recommendation #1 (Charter Question A) – The IRTP Part C WG recommends the adoption of change of registrant consensus policy, which outlines the rules and requirements for a change of registrant of a domain name registration. At this point in time, the WG is of the view that such a policy should follow the five steps as outlined in the section 5 of the Initial Report under the heading 'proposed change of control process for gTLDs', but recognizes that there are additional details and/or steps that may need to be added and therefore requests community input on the proposed process and related notes.
  • Recommendation #2 (Charter Question B): the WG recommends Section 2 of the IRTP be revised to insert the following section: 2.1.4 Once obtained, an FOA is valid for (45 or 60 1) calendar days, or until the domain name expires, or until there is a Change of Registrant, whichever occurs first. The WG recorded rough consensus for the above recommendation, but some noted that support was conditional on a second recommendation related to this charter question being considered by the WG, which recommends that:
  • Recommendation #3 (Charter Question B): the Standard FOA is enhanced to support FOAs that have been pre-authorized or auto-renewed by a Prior Registrant who has chosen to opt out of this time-limiting requirement after having received a standard notice as to the associated risks. This enhancement would introduce a modified FOA, which would serve exclusively as a notification to the Prior Registrant that their pre-authorized domain transfer had occurred. The implementation of this recommendation should be accompanied by the appropriate security measures to protect Registrants from hijacking attempts using pre-approval as the attack vector. The WG is planning to discuss the details of such security measures in further detail in the next phase of its work.
  • Recommendation #4 (Charter Question C): The WG recommends that all gTLD Registry Operators be required to publish the Registrar of Record's IANA ID in the TLD's thick WHOIS. Existing gTLD Registry operators that currently use proprietary IDs can continue to do so, but they must also publish the Registrar of Record's IANA ID. This recommendation should not prevent the use of proprietary IDs by gTLD Registry Operators for other purposes, as long as the Registrar of Record's IANA ID is also published in the TLD's thick Whois.

In addition to input on these preliminary recommendations, the WG is specifically requesting feedback on a number of open items such as, amongst others: whether the proposed change of registrant policy should be accompanied by a restriction that would prevent a change of registrar immediately following a change of registrant for 60 days; whether this change of registrant policy should be incorporated as a stand-alone policy or as part of the existing IRTP; which changes to registrant information should qualify as a 'change of registrant', and; whether there are any other expected impacts of the proposed recommendations in addition to those already anticipated by the WG.

Those interested in providing input are strongly encouraged to especially review section 5 of the Initial Report in further detail in order to obtain further understanding concerning the WG's thinking and rationale with regards to these recommendations.

The WG appears to have rough consensus for all the above recommendations, but it should be noted that no formal consensus call was undertaken. Such a formal consensus call will be conducted once the recommendations are finalized following review of the public comments received on this Initial Report.

The WG would like to encourage all interested parties to submit their comments and suggestions so these can be considered as the WG continues its deliberations in view of finalizing its report and recommendations in the next phase of the policy development process.

1 The WG has not decided yet on the exact timeframe and would welcome community input.

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 PDP Working Group has been tasked to consider the following three questions:

  1. "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.
  2. 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.
  3. Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.
Section III: Document and Resource Links
Section IV: Additional Information
None

(*) 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.

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