Table of contents Page A. Summary B. Objective C. Background D. Issues F. Proposed Terms of Refereence G. References As requested by the GNSO Council at its meeting on 2 December 2005 and during subsequent discussions, in particular during the ICANN meeting in Wellington (25 – 31 March, 2006), this document sets out policy issues involved with the potential introduction of IDNs 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 IDNs at the root. It should be read in conjunction with the Background Report on Internationalized Domain Names prepared earlier. 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 IDNs. 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. Technical tests of two approaches to the insertion of internationalized domain name (IDN) labels into the root zone of the DNS are currently being developed within the ICANN President's Advisory Committee that has been 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. The outcome of the technical tests will provide information to address and inform policy questions that need to be addressed. The tests will include the insertion of IDN labels into the root zone of the DNS by the following two approaches:
These two approaches 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. While recognizing that it would be premature to anticipate the outcome of these 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. 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 user experience, user expectations and user needs with respect to timeliness. 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 IDNs. On 12 June, the IAB issued a new version of "Review and Recommendations for Internationalized Domain Names" (see reference section). These findings have been considered in drafting the final version of this Issues Report. 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 scen arios may need individual consideration and may imply different issues and different preferred solutions. With a general presumption that an introduction of IDNs 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? In 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? Should there be a limit on the number of IDN top-level labels per existing TLD? If so, how many IDN strings should be allowed per existing TLD? For ccTLDs, should such a limit be related to the number of official languages or scripts used within the respective country? 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>? Are there special considerations required in this regard concerning TLDs with eligibility requirements? 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-Latin scripts? As ISO 3166 provides for translations of its labels into some other scripts, what status should be given to these translations regarding IDN based strings? Should there be a requirement that any party aspiring to run an IDN version of a ccTLD must be located within the geographic territory associated with the ccTLD? What considerations need to be made for languages and scripts used across multiple countries? What are the advantages and drawbacks of having a TLD (<.tld>) and its internationalized equivalent (<.idn-tld>) in the same TLD or in two different TLDs?
Would any or both of the two approaches under consideration for technical tests lead to overall satisfactory results from a policy perspective? How can any risks for end user confusion best be counteracted? 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? Similarly, how to select between more than one party that apply for different IDN top-level labels but with identical purposes? 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 what order should applications for IDN top-level labels be handled in case of limited resources? 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 IDNs? 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, browser appearance of v arious identifiers etc. As an example; even though ASCII encodings of IDNs may be introduced into the domain name strings – there are still issues in using such domain names in email and websites. 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. 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. This process would be developed in collaboration with the ICANN Board, cctld sponsors, the ccNSO, members of the Government Advisory Committee, and other Governments. The country code equivalents should be constrained to be consistent with the intent of the current ISO3166 table that provides two letter latin-script strings which relate to the country name. 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 various aspects of IDNs, and on the implementation of IDN TLDs, to enable the GNSO to factor these efforts into its PDP work. 6. 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 IDNs 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 IDNs 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. Should IDN Top-Level Domains be introduced?
2. Selection Criteria for IDN Top-Level Domains
3. Allocation Methods for IDN Top-Level Domains
4. Policy to Guide Contractual Conditions for IDN Top-Level Domains
5. Additional policy considerations regarding IDN Top-Level Domains
Punycode, an introduction Punycode is a bootstring encoding that will convert the local characters in a domain name into the limited character set that is supported by the DNS. The encoding is applied to each component of a domain name and a prefix 'xn--' is added to the translated Punycode string. For example, the first component of the domain name rodgrodmedflode.dk becomes "xn --rdgrdmedflde-vjbdg" , and the domain will be represented as xn --rdgrdmedflde-vjbdg.dk. This kind of encoding would apply for top-level labels with characters from non-Latin scripts. ICANN's IDN Implementation Guidelines, available at http://www.icann.org/topics/idn/implementation-guidelines.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/ |
GNSO Issues Report Policy Issues Relating to IDN at the Top-level
Last Updated:
Date