Regarding the topic list, see below my intended response to the IDNC list. Your feedback would be helpful. Before answering the questions there are a few basic principles I think, as my personal opinion, are important: 1. the fast track approach should be treated as experimental in nature (does not mean that delegation is not treated as long-term commitment, i.e. that delegation should not be revoked lightly) 2. because of its experimental nature, certain requirements (that do not currently apply to ccTLDs) would be appropriate 3. the point that no precedence should be set for the larger discussion is important to be stressed. Also, the "larger discussion", that is, the appropriation of IDN TLDs representing territories designated in the ISO3166-1 list into the ccNSOs remit, must involve an ICANN community-wide process and balanced participation from all stakeholders. 4. consistent with point 2., some form of agreement / understanding with ICANN should be required for the Fast Track to ensure that point 3 is observed (i.e. that it does not set a precedence or create any legacy issue). Also it should serve to ensure the adherence to the IDN guidelines and relevant technical standards.
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On
2. Mechanism for the selection of an IDN ccTLD string in the fast track o What are the requirements regarding the status of the script/language in the territory to be used in the IDN ccTLD string?
i. Should have published (or adopted) an IDN language table at IANA ii. Such publishing (or adoption) should have gone through due process involving local community and experts iii. Should have some experience with 2LD IDN registrations and management iv. Must comply with IDN guidelines
o Is there a limit to the number of scripts per territory to be used as an IDN ccTLD under the fast track approach? Should it be limited to one (1) per territory or some other number?
Should not be based on a arbitrary number. Should be based on practical circumstances in ways consistent with the fast track approach (more specifically not to impede the implementation).
o Who should be able to propose a string for the territory?
The proposed string should be based on authoritative sources for a phrase that is representative of describing the territory. The entity that will be operating or overseeing the operations of the TLD should present the case for the delegation of the IDN TLD.
o Who is required to endorse a string once proposed?
"Endorsement" may not be the appropriate characterization. The "proposed" string should already exist and based firmly on authoritative sources. As such, no "endorsement" should be required. Confirmation may be useful and that should include advice from the GAC and response from the community, including through an "objection" process (see below for thoughts on "objection process").
o What are the criteria for such a string to be acceptable under the fast track (for example: meaningful representation in a selected script of the name of the territory or recognized abbreviation as listed on ISO 3166 -1)
- meaningfully represents the territory designated by the ISO3166-1 list - non-controversial - must comply with IDN guidelines - should not be confusingly similar to existing TLDs (except for the corresponding ccTLD) - does not have a secondary meaning that may be generic in nature and not representing the corresponding territory
o Will a proposed string be ¡¥evaluated¡Š against criteria? If so, who will the ¡¥evaluator¡Š be and who will appoint them?
"Evaluation" may not be the best characterization. Nevertheless, proposals should be vetted to ensure that adequate supporting documentary evidence is accompanied to suggest that the proposed string is reflective and based on authoritative sources.
o Assuming a string and script are selected in accordance with proposed criteria, should there be an objection procedure? If so, who should be eligible to object? On what grounds? What is the impact of an objection (for example non-eligibility under fast track)?
Yes, there should be a process for indicating concern or "objection". The reason to avoid "objection" is that there may be cases where a formal "objection" would be prohibitively difficult for certain entities, such as a government. The process should balance between providing a reasonable avenue for raising concerns and to avoid abusive objections. Concerns raised should also not immediately disqualify a proposal.
3. Mechanism to designate an IDN ccTLD manager. o Should any criteria specific to IDNs be taken into consideration for the designation of an IDN ccTLD manager?
Yes. The Registry Operator must commit to abiding by the IDN Guidelines and relevant RFCs.
o Are there any specific requirements regarding the technical and operational readiness of the eligible IDN ccTLD manager?
The entity operating or overseeing the operation of the IDN TLD should have some experience with IDN registrations. (understand this is specific for the fast-track).
o Should there be a proven track record for running a TLD operationally?
Yes. Again, note this is for fast-track.
o Should the eligible entity have experience (operationally or experimentally) with running IDN in the relevant script at the second and /or higher levels?
Yes.
o Should adherence to the IDNA protocol and related requirements be ensured? How should this be ensured?
Yes. In my opinion, the Fast Track process should be treated like an experimental process. The entity operating the TLD should have an agreement or some executed understanding with ICANN whereby the delegation would be revoked should there be threats to the technical stability and security of the Internet. Once the larger question of how the delegation and appropriation of IDN TLDs representing territories designated by the ISO3166-1 list is to be managed is answered by the yet to be formed ICANN community-wide exercise is completed, such agreement or understanding could be superseded.
o Is the registration policy of the IDN ccTLD relevant in relation to the IDNA protocols and related requirements? If so how is adherence to such required policy ensured?
Yes. They should be adherent to the IDN Guidelines and should have published (or adopted) an IDN language table at IANA. Edmon