Skip to main content
Resources

Inter-Registrar Transfer Policy Part B Policy Development Process - Recommendation 9, Part 2 Concerning a New Provision to Lock and Unlock Domain Name

Comment/Reply Periods (*) Important Information Links
Comment Open: 23 January 2012
Comment Close: 13 February 2012
Close Time (UTC): 23:59 Public Comment Announcement
Reply Open: Cancelled – No Comments To Submit Your Comments (Forum Closed)
Reply Close:   View Comments Submitted
Close Time (UTC):   Report of Public Comments
Brief Overview
Originating Organization: ICANN Board
Categories/Tags:
  • Policy Processes
  • ICANN Board/Bylaws
  • Contracted Party Agreements
Purpose (Brief): Public notice is hereby provided of the proposed change to the Inter-Registrar Transfer Policy (IRTP) to address the locking and unlocking of domain names that is considered for adoption as well as an opportunity to comment on the adoption of the proposed policy change, prior to ICANN Board consideration.
Current Status: Following adoption by the Generic Names Supporting Organization (GNSO) Council of IRTP Part B Recommendation #9, part 2, a public comment forum is now opened as required by the ICANN Bylaws prior to ICANN Board consideration.
Next Steps: Following the closing of the public comment period, the ICANN Board will consider the comments received in conjunction with its consideration of the proposed change to the IRTP.
Staff Contact: Marika Konings Email: Policy-staff@icann.org
Detailed Information
Section I: Description, Explanation, and Purpose

The Inter-Registrar Transfer Policy Part B presented its recommendations to the GNSO Council last year. For one of those recommendation, #9 part 2 ("denial reason #7 should be replaced by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked concerning a new provision to lock and unlock domain names"), the GNSO Council requested ICANN staff to provide a proposal. In consultation with the IRTP Part B Working Group, ICANN Staff prepared a proposal that, together with the IRTP Part B recommendation, has now been approved by the GNSO Council.

The ICANN Staff proposal, taking into account the deletion of denial reason #7 as previously approved by the ICANN Board, proposes to expand the existing section 5 (EPP - based Registry Requirements for Registrars) of the IRTP to address "Registrar Lock Status". The proposed modifications to the IRTP can be found in redline form in the ICANN Staff Proposal on IRTP Part B Recommendation #9 part 2 [PDF, 490 KB]. The main elements of the proposed modifications are:

  • Registrar may only impose a lock that would prohibit transfer of the domain name if it includes in its registration agreement the terms and conditions for imposing such lock and obtains express consent from the Registered Name Holder: and
  • Registrar must remove the "Registrar Lock" status within five (5) calendar days of the Registered Name Holder's initial request, if the Registrar does not provide facilities for the Registered Name Holder to remove the "Registrar Lock" status

You are invited to submit comments until 13 February 2011 before final consideration by the ICANN Board.

Section II: Background

The Inter-Registrar Transfer Policy (IRTP) aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another should they wish to do so. The policy also provides standardized requirements for registrar handling of such transfer requests from domain name holders. The policy is an existing community consensus policy that was implemented in late 2004 and is now being reviewed by the GNSO.

The IRTP Part B Policy Development Process (PDP) was the second in a series of five PDPs that address areas for improvements in the existing Inter-Registrar Transfer Policy. The GNSO IRTP Part B Policy Development Process Working Group was tasked to address five issues focusing on issues related to domain hijacking, the urgent return of an inappropriately transferred name and "lock status". The WG delivered its Final Report to the GNSO Council on 31 May 2011. The GNSO Council acted on a number of the recommendations at its meeting on 22 June 2011. In relation to recommendation #9, part 2, a proposal from staff was requested. Following consultations with the IRTP Part B Working Group and a public comment forum on the Staff Proposal, GNSO Council approved IRTP Part B Recommendation #9, part 2 and the staff proposal at its meeting on 19 January 2012 (see http://gnso.icann.org/resolutions/#201201). As required by the ICANN Bylaws, public notice is hereby provided of the policy that is considered for adoption as well as an opportunity to comment on the adoption of the proposed policy, prior to consideration by the ICANN Board of these recommendations.

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