Public Comments for ccNSO IDNC Proposal Methodology for Fast-Track IDN ccTLDs
DRAFT Methodology for Fast Track
Published for Comment
PLEASE NOTE: This is a first Discussion Draft and is published for comment and input. This document has not been signed off by the IDNC Working Group who will continue to provide their own comments and input.
1. Introduction
The purpose of the fast track is to introduce a limited number of non-contentious IDN ccTLDs to meet near term demand. The goal of the IDNC WG is to recommend a Fast Track model that contains a mechanisms for the selection of an IDN ccTLD string, and a mechanism to designate an IDN ccTLD manager.
The model needs to take into account the overarching requirements of stability and security; IDNA protocols and IDN guidelines; input of the technical community in respect to implementation of IDNs; and current practices for the delegation of ccTLDs.
The IDNC WG published for comment a draft Initial Report, to canvass the topics that need to be covered.
There seems to be consensus that the questions raised in the draft Initial Report did canvass the areas that any proposed mechanisms would need to cover. Comment and input was also received addressing some of the possible answers to the questions raised in the draft Initial Report.
Based on our understanding of the substantive input to the draft Initial Report we think there is a rough consensus on the following points:
A: Ongoing Process
The Fast Track should be an ongoing process, which ends before the overall IDN ccTLD policy has been adopted by the ICANN Board. Thus an IDN ccTLD manager can enter the fast track when ready. The window of opportunity has no fixed end-date.
B: Non pre-emption of overall policy
The Fast Track must not pre-empt final IDN ccTLD policy so must be a simple, clear and limited solution.
C: Purpose of Fast Track is to meet pressing demand
The Fast Track should only be available where there is a pressing demand in the territory. The existence of this demand is evidenced by the readiness of the IDN ccTLD manager and relevant stakeholders in the territory to meet the requirements to introduce an IDN ccTLD under the Fast Track. The territory needs to be ready to use the IDN ccTLD and to demonstrate that readiness.
D: Fast Track only for non-Latin scripts
As the Fast Track has been initiated to meet near term demand for IDNs and to avoid pre-empting the outcome of the ccPDP, the script has to be a non-Latin script.
E: The proposed string and delegation request should be non-contentious within the territory
The two mechanisms should only allow for the delegation of a non-contentious string for an IDN ccTLD and designation of a non-contentious IDN ccTLD manager.
F: The Fast Track is experimental in nature
The introduction of IDN ccTLD is experimental in nature, and this should be taken into consideration in devising the mechanisms and the Fast Track process.
G: Criteria to determine number under the fast track.
The criteria to select the IDN ccTLD string, and to designate the IDN ccTLD manager should determine the number of eligible IDN ccTLDs, not an arbitrarily set number.
In section 2 a model is proposed that we think meets the above points and the guiding principles. This model is based on a four stage approach which maps and follows the activities, roles, and responsibilities of the actors involved. The model is devised to enable the relevant actors in the territory to self-asses and determine whether delegation of IDN ccTLD under Fast Track process is feasible, and enable them to prepare for a delegation request. Section 3 contains notes on definitions and section 4 contains notes on the proposed testing stage (stage 3).
2. Proposed Fast Track model
Stage 1: Preparing for the Fast Track in Territory
This part of the process is performed in territory by the local actors involved.
1. Identify the language and script for the language

  • criteria: must be ‘official’ language (see section 3)
  • criteria: fast track is only for non-Latin scripts

2. Prepare language table

  • may already exist prepared by another territory using same language/script.
  • fast track should encourage cooperation, in accordance with IDN guidelines

3. Identify String

  • must meet technical and meaningful requirements

4. Select intended IDN ccTLD registry
5. Get evidenced endorsement by actors in territory of proposed string and IDN ccTLD registry

  • Government, Local Internet Community, existing ccTLD manager

Stage 2: Evaluation
1. Place language table into IANA Repository
2. Have string checked/evaluated by ‘Technical Committee’ and ‘Language Committee’ (see section 3).
Stage 3: Reporting
1. Document experience with managing IDNs, including use of the proposed language table at second or higher levels & implementation of IDN guidelines and compliance with IDNA protocol.
2. Complete IANA request for delegation documentation.
Stage 4: Designation of IDN ccTLD
Request for delegation

  • In accordance with current IANA practices

3. Definitions
Official language:
For the purpose of the Fast Track, an ‘official’ language is one that has a legal status in the territory or that serves as a language of administration.
This definition is based on: “Glossary of Terms for the Standardization of Geographical Names”, United Nations Group of Experts on Geographic Names, United Nations, New York, 2002.
For the purpose of the Fast Track a language could be demonstrated to be an official language:
a. If the language is listed as an ISO 639 language in Part Three of the Technical Reference Manual for the standardisation of Geographical Names, United Nations Group of Experts on Geographical Names (UNGEGN) < http://unstats.un.org/unsd/geoinfo/default.htm>;
b. If listed as administrative language for the relevant territory in ISO 3166-1 standard under column 9 or 10; or
c. It is demonstrated/evidenced that the language is used in official communications of the relevant public authority in the territory and serves as a language of administration.
Meaningful string:
For purpose of the Fast Track process a string is meaningful if it is:
a) the name of the territory in the selected language; or
b) a part of the name of the territory in the selected language denoting the territory in that language; or
c) an acronym of the name of the territory in the selected language denoting the territory in that language.
If the proposed string is demonstrated to be listed as such in the Technical Reference Manual for the standardisation of Geographical Names, UNGEGN, Part Three column 3 or 4, it is considered to be meaningful for the purpose of the Fast Track. In other cases, it has to be demonstrated in another way.
Language Committee:
A small committee tasked with validating that the proposed string is in a language that is ‘official’ in the territory and is meaningful in accordance with the definition.
Technical Committee:
A small committee tasked with checking the proposed string against the IDNA Guidelines to ensure it will not cause any technical issues (for example a string in Cyrillic that appears to be the same as a string of ASCII characters).
4. Reporting experience stage
The purposes of reporting is:
a) The intended IDN ccTLD manager documents its experience with IDN’s;
b) The stakeholders in the territory have been prepared and informed on the possible introduction of the IDN and have the opportunity to demonstrate support and endorsement of the selected language, script and string for IDN ccTLD;
c) There has been testing of the language table and the opportunity for the intended IDN ccTLD manager to demonstrate and evidence compliance with IDNA protocols and guidelines and the maintenance of security and stability;
The intended report would cover at least following:
(i) Compliance with IDNA protocols and guidelines and how it was demonstrated in test phase;
(ii) Community use of and any potential limitations, and problems relating to the use of the intended language/script table;
(iii) description of potential cross-TLD registration conflicts, and intended resolution process, if any (for instance sunrise, dispute resolution methods);
(iv) Statistics on use;
 (v) Involvement in testing of local internet community, relevant public authorities and ccTLD manager, demonstrating near term demand. (for instance by providing user statistics, public consultations and information sessions etc.)