Table of contents Page A. Summary B. Objective C. Background D. Issues F. Proposed Terms of Reference G. References As requested by the GNSO Council at its meeting on 2 December 2005 and during subsequent discussions, in particular during the ICANN 2006 meetings in Wellington and Marrakech, this document sets out policy issues involved with the potential introduction of Internationalized Domain Names (IDN) into the root zone of the DNS, provides relevant references, and suggests how to proceed. The issue areas are related to the issues identified in the ongoing policy development process on introduction of new gTLDs. It is recommended that the GNSO launch a focused policy development process, in close consultation with the ccNSO and the broader ICANN community including the Government Advisory Committee (on the public policy aspects). The proposed terms of reference for this policy development process are based on suggestions by the GNSO working group established for this purpose. This report is designed to give the GNSO Council the information necessary to make a decision about whether to proceed with a policy development process on policy aspects related to the introduction of IDN at the root. It should be read in conjunction with previous ICANN work to develop policy for IDN, including the top-level. This work started in 2000 with an IDN Committee created by the ICANN Board responsible for promoting the coordination of the work of the ICANN supporting organizations, committees, and other groups on the policy issues arising from IDN. Links to reports from this and the ensuing activities are found in the reference section. As agreed during discussions in Wellington, the intention is to establish a full picture of policy issues that need to be dealt with before deployment of IDN Top-Level Domains (TLDs) can take place. It follows that the issues listed in this report are of a broad nature, reaching beyond the remit of the GNSO and calling for necessary expert advice from other ICANN entities such as the ccNSO, the GAC, and the President’s Advisory Committee for IDN, as well as from individual experts in this area. Also required, is collaboration with and advice from the technical community specifically, RSSAC, IAB, IETF, SSAC. The GNSO Guidelines for Issues Reports have been used to frame this document. In particular, the Issues Report describes the key issues, provides relevant background and links, and recommends how to proceed. Deployment of IDN labels has been considered by ICANN and the ICANN community for some time in some depth. IDN efforts were the subject of a 25 September 2000 resolution by the ICANN Board of Directors, which recognized "that it is important that the Internet evolve to be more accessible to those who do not use the ASCII character set," and also stressed that "the internationalization of the Internet's domain name system must be accomplished through standards that are open, non-proprietary, and fully compatible with the Internet's existing end-to-end model and that preserve globally unique naming in a universally resolvable public name space." A three-part protocol suite defining a standard for internationalized domain names in applications was published as RFCs 3490, 3491, and 3492. An Internationalized Domain Name Committee was established by ICANN Board resolution 01.94 and served until October 2003 as a general coordination body for the work on policy issues related to Internationalized Domain Names (IDN). The IDN Committee issued a series of reports and recommendations regarding IDN and related issues. A more complete area designed to document the progress of the implementation of IDN as well as allow for discussion of issues encountered in implementation can be found at http://www.icann.org/topics/idn/. Technical tests of two approaches to the insertion of internationalized domain name (IDN) labels into the root zone of the DNS have been considered within the ICANN President’s Advisory Committee established to discuss key IDN implementation issues. The intention to perform the tests along with a timeline was publicly announced on 14 March 2006, see http://www.icann.org/announcements/announcement-14mar06.htm . The technical test plan is currently being revised in the light of recent findings, as further discussed during the ICANN meeting in Marrakech. Originally, the tests were foreseen to include the insertion of IDN labels into the root zone of the DNS by the following two approaches:
The revised technical test plan includes testing of NS-records by insertion of IDN labels into the root zone. After some review, it has been determined that the potential DNAME solution requires additional technical analysis before testing can take place. Therefore, NS-record testing will proceed in accordance with the IDN program plan while DNAME testing will not be planned prior to the completion of analysis. It deserves to be mentioned that, in principle, the two approaches above are not mutually exclusive. Accordingly, if both are technically feasible, one of these approaches will not preclude the use of the other, pending policy considerations. DNAME records imply a situation where the operator of an existing TLD would map it into some other script equivalent, either synonymous to or a transliteration of the original TLD. NS records allow the creation of a new TLD that can be proposed by any entity regardless of whether it is currently operating a top-level domain or not. From a policy perspective, the technical tests will prim arily serve the purpose of ascertaining feasibility of technical solutions. Technical analysis to specifically inform policy development is as such outside the scope of the technical test plan. While recognizing that it would be premature to anticipate the outcome of the technical tests, discussions have emerged in parallel on how to address related policy issues. The GNSO has requested an issues report to this end. This issues report should be read with the understanding that any outcome of ongoing policy issue discussions would be conditional upon the viability of necessary technical solutions. A key background for the Issues Report is the GNSO Council resolution of 2 December 2005: “WHEREAS, the GNSO Council recognises that one of the goals of ICANN is to increase the internationalisation of the domain name space. WHEREAS, the GNSO Council wishes to liaise closely with the ccNSO with respect to the issue of localised IDN equivalents of existing gTLDs and ccTLDs, and for the purpose of jointly requesting an issues report The GNSO Council requests that the staff produce an issues report on the policy issues associated with creating internationalised equivalents of existing gTLDs, and second level domains within existing gTLDs. The GNSO also requests that the staff liaise with the ccNSO to ensure that the policy issues associated with internationalised versions of the existing ccTLDs can also be considered.” Since this resolution was adopted, discussions within the GNSO Council and with other ICANN entities, in particular during the ICANN meeting in Wellington (25 – 31 March, 2006), have shown a need to frame the issue areas more broadly than originally specified in the resolution, in order to get a proper overview. A precursor to the Issues Report was drafted as a discussion paper and introduced at the Wellington meeting. During the Wellington meeting, it was also proposed to form a joint working group for IDN matters, consisting of members of the GNSO and ccNSO Councils to address policy matters within their respective remits. During these discussions, the need to connect to the ongoing policy development process for new gTLDs was also highlighted, with a view to map the IDN-related issues to the issue areas already identified in the ongoing PDP for new gTLDs, notably selection criteria, allocation methods and contractual conditions. This approach is reflected in the appended draft terms of reference for further GNSO work. Some guiding principles also emerged during these discussions, in particular the necessity to focus on usability, user experience, user expectations and user needs with respect to timeliness. These guiding principles must be stated with particul arity and synthesized in the policy development process to ensure that user experience is appropriately taken into account. Also, in view of a timely introduction, the priority for the next steps should be to identify the issues to be worked on first, as well as who should be involved in addressing each issue, to allow the initial introduction of IDN. On 12 June, the IAB issued a new version of “Review and Recommendations for Internationalized Domain Names” (see reference section). The GNSO received a briefing on the findings of this report by John Klensin and Patrik Falstrom. ICANN supports the finding of this report, and recommends that they are considered by the GNSO Council as the policy discussion moves forward. A preliminary version of this Issues Report was posted for public comments on 28 May 2006. Furthermore, it was discussed by a GNSO working group in early June as well as at the ICANN meeting in Marrakesh late June 2006, where also workshops on IDN at the top-level were held. While the public comment posting did not prompt any comments, other input from meetings and from direct comments has been used to update the final version of the Issues Report. During the discussions in Wellington, possible scen arios were identified as a starting point for analyzing the issues involved: a) A gTLD registry operator wishes to introduce an IDN based string that relates to the existing gTLD. b) A ccTLD registry operator wishes to introduce an IDN based string that relates to the existing ccTLD. c) A party may wish to introduce an IDN based string that relates to a gTLD, in competition with the gTLD registry operator. d) A party may wish to introduce an IDN based string that relates to a ccTLD in competition with the ccTLD. e) A party wishes to introduce a new IDN string with no relationship to an existing TLD. These issues have been discussed in other fora. Notably, an Internationalized Domain Name Committee was established by ICANN Board resolution 01.94 and served until October 2003 as a general coordination body for the work on policy issues related to IDN. The IDN Committee issued a series of reports and recommendations regarding IDN and related issues that should be consulted during the discussion of these issues. These scen arios may need individual, independent consideration and may imply different issues and different preferred solutions. With a general presumption that an introduction of IDN at the root is feasible, potential policy issues are listed in question form below. Some of these issues relate only to certain scen arios above while others relate to all. As mentioned previously, guiding principles for assessing the issues would include achieving timely benefit for Internet users, ensuring that user expectations are met and providing a good user experience. Issues are listed below related to the identified issue areas of the ongoing policy development process regarding new gTLDs, in order to connect to this process. This mapping is not stringent, though, as many issues relate to more than one of these areas. Issues of relevance for selection criteria Does the operation of an IDN TLD registry require particular additional competences that should be reflected in selection criteria? How far is it essential to safeguard against business failure of new IDN TLDs? Do such risks for a new IDN TLD differ from those involved in a new TLD in general? How should the choice of the IDN string or strings be governed? How would the approaches for gTLDs and for ccTLDs differ? Is it from a policy standpoint advisable to create internationalized equivalents of existing TLDs? How could an introduction of internationalized equivalents of existing TLDs best promote competition and choice for end-users? What selection and approval processes should apply for translation and/or transliteration of an existing <.tld> to its script equivalent(s) <.idn-tld>? Should any transliteration be phonetic (= transcription) or definitional/literal? Should a registry be able to determine its own equivalent(s), subject to an approval process involving input from the community, including governments? How should public policy aspects be reflected in such an approval process? How can the identified need for consistency between different national character tables for the same language best be achieved? How should the number of IDN top-level labels per existing TLD be determined? If limits should apply, how many IDN strings should be allowed per existing TLD, and based upon what criteria? Are there reasons to have conservative limits initially, with a view to easing them as experience is gained? Should entities other than the existing TLD registry be entitled to run an IDN equivalent or equivalents of this TLD? If so, under what policies should the ‘new’ registry manage the <.idn-tld>? Conversely, should an existing registry be prevented from operating a related IDN TLD on the grounds of promoting competition? Are there special considerations required in these regards concerning TLDs with eligibility requirements? Reference: GNSO mailing list for the questions in this paragraph and similar questions. Should the IDN based string relate to an official language within the country of the ccTLD? In cases when a language can be represented in multiple scripts, should each script be entitled to a separate IDN based string? What is the accepted representation of a country name in non-ASCII scripts? What considerations need to be made for languages and scripts used across multiple countries? What are the advantages and drawbacks of having <.idn-tld> map into <.tld>? (This, for example, means that www.example.tld and www.example.idn-tld will resolve to the same website.) Given that the ultimate user experience has been identified as an overall priority, how can any risks for end user confusion best be counteracted? V arious risks, issues and aspects of user experience must be a priority. Acceptable user experience levels must be discussed and targeted. Issues of relevance for allocation methods If more than one party apply for the same IDN top-level label, on what grounds should a single applicant be selected? This is similar to having two applications for the same ascii-tld. There are additional complexities such as if an applicant wishes to introduce and <idn-tld> that is a translation or transliteration of an existing gTLD. Similarly, what measures should ICANN take into consideration when selecting between more than one application for different IDN top-level labels that have a similar or identical purposes? What importance should be given to the sequential order in which such applications are received in relation to other possible aspects? How should conflicts between a proposed IDN top-level label and a trademark be resolved? Does a specific dispute resolution mechanism need to be put in place to resolve such conflicts? In this scen ario ICANN is effectively the registrar for the root zone. The policy should address the issue of determining which, if either, of two countries requesting the same name is designated as the TLD. In what order should applications for IDN top-level labels be handled in case that: (i) countries or ccTLDs are determined to be entitled to one or more IDN-based TLDs and (ii) more applications appear at the same time than can effectively be processed? Issues of relevance for contractual conditions What particular contractual provisions are required for an <.idn-tld> in addition to those normally required for any <.tld>? How could IETF IDN standards and ICANN’s IDN Guidelines best be incorporated in the contractual conditions? To what extent are current established policies adequate for IDN? Are modifications of the existing UDRP required to address disputes concerning IDN labels? Are modifications needed to facilitate usability of WHOIS information for end-users with different scripts? Provided that an internationalized equivalent of a TLD exists as <idn-tld> in some script, should there be a policy for what script(s) may be used at the second level, such as <idn-domain>.<idn-tld>? In other words, should the script used on the second level match the script used in the top-level? Given that, with specific exceptions, mixing of scripts is prohibited on the second level, should the same rule apply to the top-level? Should a registrant in <.tld> have a prior right to register in the IDN version <.idn-tld>? Would current domain name holders feel that they are forced to register in the IDN equivalent for brand protection? Does an intellectual property rights holder in one or more jurisdictions have a prior right to register in an IDN version? What rules should govern timing and sequencing of the launch of IDN top-level domains? Is there a need for sunrise periods? Is there a need for concurrent launch of multiple IDN top-level domains for fair competition reasons? Other aspects The above examples of issue areas and aspects are not exhaustive. There are certainly other IDN aspects to consider that may affect policy preferences, like email interoperability and browser appearance of v arious identifiers. As an example; even though ASCII encodings of IDN may be introduced into the domain name strings – there are still issues in using such domain names in email and websites. Such issues may indeed be of major importance from the user perspective – even to the extent of degrading the user experience considerably. While such issues clearly fall outside the remit of GNSO, they deserve to be kept in mind for a full perspective of the ultimate user experience. It is recommended that the GNSO launch a policy development process on the gTLD issues outlined in the 2 December 2005 resolution, as expanded upon during discussions in Wellington and Marrakech, in cooperation with the ccNSO (on the ccTLD aspects) and the Government Advisory Committee (on the public policy aspects), as well as in close consultation with the broader ICANN community. It is further recommended to support this process by a dedicated communication plan to be developed by ICANN staff. Consistent with the discussions in the GNSO Working Group, it is recommended that a process be developed to create or identify some form of table of IDN based country code equivalents to support IDN-ccTLDs (based upon the current ISO3166 table that provides two letter Latin-script strings). This process would be developed in collaboration with the ICANN Board, cctld sponsors, the ccNSO, members of the Government Advisory Committee, and other Governments. Essential to this process will be timely and frequent collaboration with the technical community, specifically RSSAC, IAB, IETF, SSAC. ICANN staff also recommends that the GNSO Council considers the already established GNSO working group as a starting-point when deciding whether a PDP be performed through a task force, or through some other mechanism. ICANN staff will continue to update the GNSO on the extensive, ongoing community discussions about v arious aspects of IDN, and on the implementation of IDN TLDs, to enable the GNSO to factor these efforts into its PDP work. The need for tutorial sessions on IDN matters in order to inform the process should be addressed early on jointly by ICANN Staff and the GNSO Council. General Counsel’s opinion: The General Counsel’s opinion is that the development of policies relating to ICANN's introduction of IDN gTLDs is within the scope of the GNSO and the ICANN policy development process. The General Counsel notes that care will need to be taken to ensure that any PDP on IDN stays narrowly focused on discrete gTLD policy questions in line with the limited intended ambit of the policy development process as set forth in the ICANN Bylaws <http://www.icann.org/general/bylaws.htm#AnnexA>, and does not become over-broad and begin to encompass more questions than can be successfully answered in one policy development process. The General Counsel's office will continue to work closely with ICANN's policy development staff and the GNSO on the appropriate scope of the PDP as work on IDN evolves and additional specific policy development tasks are defined. F. Proposed Terms of Reference The following terms of reference for further work are focused on the GNSO activities, which should address gTLD aspects, as recommended by the GNSO working group assessing the Preliminary Issues Report. 1. Introduction of Generic Top-Level Domains with IDN Labels (IDN-gTLDs)
2. Selection Criteria for Top-Level Domains with IDN Labels
3. Allocation Methods for Top-Level Domains with IDN Labels
4. Policy to Guide Contractual Conditions for Top-Level Domains with IDN Labels
5. Additional Policy Considerations Regarding Top-Level Domains with IDN Labels
For detailed information describing Punycode, see RFC 3492 ICANN’s IDN Implementation Guidelines, available at http://www.icann.org/topics/idn/implementation-guidelines.htm ICANN Wellington meeting, March 2006, At-large IDN workshop, available at http://www.icann.org/meetings/wellington/agenda-idn-28mar06.htm ICANN Marrakech meeting, June 2006, IDN workshops, available at http://www.icann.org/meetings/marrakech/idn-workshop-jun06.htm Technical test announcement, available at http://www.icann.org/announcements/announcement-14mar06.htm IDN Background paper, available at http://gnso.icann.org/mailing-lists/archives/council/msg01479.html Selected IETF documents, RFCs 3454, 3490, 3491, and 3492 IAB “Review and Recommendations for Internationalized Domain Names”, available at http://www.ietf.org/internet-drafts/draft-iab-idn-nextsteps-06.txt New gTLD PDP, progress reflected on the GNSO website at http://gnso.icann.org/issues/new-gtlds/ Internationalized Domain Names Internal Working Group (of the Board) http://www.icann.org/committees/idn/iwg-15nov01.htm and its final report at http://www.icann.org/committees/idn/final-report-28aug01.htm Internationalized Domain Names (IDN) Committee at http://www.icann.org/committees/idn/ and its final report at http://www.icann.org/committees/idn/final-report-27jun02.htm Proceedings from ITU and UNESCO May 2006 “Global Symposium on Promoting the Multilingual Internet”, available at http://www.itu.int/ITU-T/worksem/multilingual/programme.html ITU “Internationalized Domain Names” references, at http://www.itu.int/ITU-T/studygroups/com17/idn/index.html Paul Hoffman “Terminology used in Internationalization in the IETF”, January 2002, available at http://www.icann.org/committees/idn/draft-hoffman-i18n-terms-05.txt A short introduction to Punycode is provided in the References section. |
GNSO Issues Report Policy Issues Relating to IDN at the Top-level
Last Updated:
Date