Skip to main content

Inter-Registrar Transfer Policy Part B – Recommendation #8 and #9 Part 2 – Staff Proposals

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

The Inter-Registrar Transfer Policy Part B presented its recommendations to the GNSO Council earlier this year. For two of those recommendations, recommendation #8 concerning the standardization and clarification of Whois status messages regarding Registrar Lock status and recommendation #9 part 2 concerning a new provision to lock and unlock domain names, the GNSO Council requested ICANN staff to provide proposals. In consultation with the IRTP Part B Working Group, ICANN Staff has prepared the following two proposals: ICANN Staff Proposal on IRTP Part B Recommendation #8 [PDF, 288 KB] and ICANN Staff Proposal on IRTP Part B Recommendation #9 part 2 [PDF, 490 KB]. Before submitting these proposals to the GNSO Council for its consideration, ICANN Staff is requesting your 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 B Working Group presented its Final Report in May this year (see http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf [PDF, 972 KB]). In relation to recommendation #8, the GNSO Council resolved: 'Prior to the consideration of approval of the recommendation regarding the standardizing and clarifying WHOIS status messages regarding Registrar Lock status, the GNSO Council requests ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation.' (As adopted by the GNSO Council in Resolution 20110622-1 on 22 June 2011)

In relation to recommendation #9 – part 2, the GNSO Council resolved: 'Prior to the consideration of approval of the recommendation which states: "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", the GNSO Council requests ICANN Staff to provide a proposal for such a new provision, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report – (Recommendation #9 – part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation.' (As adopted by the GNSO Council in resolution 20110622-1 on 22 June 2011)
Section III: Document and Resource Links
Section IV: Additional Information
None
Staff Contact: Marika Konings Email: policy-staff@icann.org

(*) 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""icann.org"" is not an IDN."