Drewbert
11th March 2010, 09:15 AM
Annex A to GAC Communiqué to be formally presented to ICANN tomorrow:
####
GAC Interim Principles on IDN ccTLDs
1. General Principles The main provisions of the GAC ccTLDs principles:
"Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains" apply also for IDN ccTLDs. The current principles are intended to supplement the aforementioned principles insofar as non-ASCII ccTLDs are concerned.
2. The introduction and operation of IDN ccTLDs should not undermine the security and stability of the DNS. To this end, all actors, including TLD operators, ICANN and the relevant government should work together to ensure that the highest standards of TLD operation are achieved, taking account of best practices and internationally accepted technical standards where they exist.
3. All countries and distinct economies, listed in the International Standard ISO
3166-11 have equal rights to creating IDN ccTLDs that reflect their languages and scripts.
4. Ultimate public policy authority over the IDN ccTLD(s) of a country or distinct economy rests with the government or relevant public authority. How this authority is exercised, is determined by applicable law.
5. On receipt of an IDN ccTLD application, ICANN should ensure that either the proposal has the support of the Government or relevant public authority or that the Government or relevant public authority raises no objections to the application. In the event that such confirmation is not obtainable, ICANN should desist from the introduction of the proposed IDN ccTLD until such confirmation is obtained.
6. The number of IDN strings per territory should reflect the cultural and linguistic characteristics of the community concerned. A limit on the number of IDN strings per territory may only be considered if there are reasons to believe that some form of limitation on the overall size of the root zone file is necessary to preserve the stability of the DNS. If a limit is to be introduced, this should be done in agreement with the government or relevant public authority of the territory concerned, and adequate justification for such a limit should be made clear beforehand in order for territories to establish their priorities properly.
7. It is anticipated in most cases that the Government or relevant public authority will decide that one IDN ccTLD per script will be sufficient, but it should also be borne in mind that within some countries and distinct economies different scripts are in use and, in some cases, the same script is used in a number of widely used languages. In these cases the Government or relevant public authority may determine that more than one IDN ccTLD is necessary.
IDN ccTLDs Strings
8. It is anticipated that an IDN ccTLD string will normally:
o be shortest meaningful representation of the name of the territory
o not be restricted to a fixed length, its maximum length being set by the prevailing technical standards with stability, security, integrity and usability in mind
9. Given the different form that IDN ccTLDs will take and the absence of an equivalent of the ISO 3166-1 list used for ASCII ccTLDs, the experience of relevant international organizations2 should be taken into account.
10. Only the Government or the relevant public authority of the country or distinct economy concerned, representing all relevant stakeholders within its jurisdiction, can provide authoritative advice to ICANN on the legitimacy of any application for an IDN ccTLD.
11. An IDN ccTLD string that refers to a specific country or distinct economy, even if unapplied for, should be reserved for it.
IDN ccTLDs Scripts
==================
12. Nobody has property rights over a script. Some scripts are commonly used to write more than one language and should be available to be used for IDN ccTLD purposes in each of those languages.
13. It is recommended that each language community develop one language table for its script. Language tables, after elaboration, should be deposited with IANA and posted for public use by any registry with no restriction in any sense.
14. The latest available version of Unicode in use should be complete, including all scripts, and constantly upgraded with newer versions to help include maximum character sets of any language and ensure a strong and dynamic variant table to handle security issues.
Stakeholders
=============
15. Relevant actors for international coordination include:
o Concerned governments
o Relevant international organizations within their respective mandates o Standardization bodies o Language experts o Language communities and local users o ICANN SOs/ACs o ISOC (chapters) o IETF o Unicode consortium
16. All relevant actors should participate in a public and inclusive consultation process, at the international level, and work towards evolving a consensus for IDN ccTLDs formulation from the point of view of technical and operational stability, security as well as addressing public-policy issues.
Introduction and Delegation of IDN ccTLDs =========================================
17. Procedure for delegation of an IDN ccTLD should follow GAC ccTLDs
principles: "Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains".
18. A mandated list / reference table of strings representing the IDN ccTLDs of countries and distinct economies, as listed in the ISO 3166-13, would facilitate management and would ensure predictability of the IDN ccTLD system.
19. Competing or confusingly similar requests should be dealt with on a case by case basis and resolved in consultation with all concerned stakeholders.
20. Policies for dealing with multiple applications, objections to applications or disputes that are currently applied for ASCII ccTLDs should be equally applied to IDN ccTLDs.
21. The decision regarding whether an existing ASCII ccTLD manager should also be the operator of a corresponding IDN ccTLD is a matter to be decided by the national/local Internet community, including the government or relevant public authority, subject to applicable legislation. In cases of dispute, ICANN should seek authoritative advice from the government or relevant public authority.
22. There should be some form of transparent communication as appropriate between ICANN and any IDN ccTLD registry to define their respective roles and responsibilities.
####
GAC Interim Principles on IDN ccTLDs
1. General Principles The main provisions of the GAC ccTLDs principles:
"Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains" apply also for IDN ccTLDs. The current principles are intended to supplement the aforementioned principles insofar as non-ASCII ccTLDs are concerned.
2. The introduction and operation of IDN ccTLDs should not undermine the security and stability of the DNS. To this end, all actors, including TLD operators, ICANN and the relevant government should work together to ensure that the highest standards of TLD operation are achieved, taking account of best practices and internationally accepted technical standards where they exist.
3. All countries and distinct economies, listed in the International Standard ISO
3166-11 have equal rights to creating IDN ccTLDs that reflect their languages and scripts.
4. Ultimate public policy authority over the IDN ccTLD(s) of a country or distinct economy rests with the government or relevant public authority. How this authority is exercised, is determined by applicable law.
5. On receipt of an IDN ccTLD application, ICANN should ensure that either the proposal has the support of the Government or relevant public authority or that the Government or relevant public authority raises no objections to the application. In the event that such confirmation is not obtainable, ICANN should desist from the introduction of the proposed IDN ccTLD until such confirmation is obtained.
6. The number of IDN strings per territory should reflect the cultural and linguistic characteristics of the community concerned. A limit on the number of IDN strings per territory may only be considered if there are reasons to believe that some form of limitation on the overall size of the root zone file is necessary to preserve the stability of the DNS. If a limit is to be introduced, this should be done in agreement with the government or relevant public authority of the territory concerned, and adequate justification for such a limit should be made clear beforehand in order for territories to establish their priorities properly.
7. It is anticipated in most cases that the Government or relevant public authority will decide that one IDN ccTLD per script will be sufficient, but it should also be borne in mind that within some countries and distinct economies different scripts are in use and, in some cases, the same script is used in a number of widely used languages. In these cases the Government or relevant public authority may determine that more than one IDN ccTLD is necessary.
IDN ccTLDs Strings
8. It is anticipated that an IDN ccTLD string will normally:
o be shortest meaningful representation of the name of the territory
o not be restricted to a fixed length, its maximum length being set by the prevailing technical standards with stability, security, integrity and usability in mind
9. Given the different form that IDN ccTLDs will take and the absence of an equivalent of the ISO 3166-1 list used for ASCII ccTLDs, the experience of relevant international organizations2 should be taken into account.
10. Only the Government or the relevant public authority of the country or distinct economy concerned, representing all relevant stakeholders within its jurisdiction, can provide authoritative advice to ICANN on the legitimacy of any application for an IDN ccTLD.
11. An IDN ccTLD string that refers to a specific country or distinct economy, even if unapplied for, should be reserved for it.
IDN ccTLDs Scripts
==================
12. Nobody has property rights over a script. Some scripts are commonly used to write more than one language and should be available to be used for IDN ccTLD purposes in each of those languages.
13. It is recommended that each language community develop one language table for its script. Language tables, after elaboration, should be deposited with IANA and posted for public use by any registry with no restriction in any sense.
14. The latest available version of Unicode in use should be complete, including all scripts, and constantly upgraded with newer versions to help include maximum character sets of any language and ensure a strong and dynamic variant table to handle security issues.
Stakeholders
=============
15. Relevant actors for international coordination include:
o Concerned governments
o Relevant international organizations within their respective mandates o Standardization bodies o Language experts o Language communities and local users o ICANN SOs/ACs o ISOC (chapters) o IETF o Unicode consortium
16. All relevant actors should participate in a public and inclusive consultation process, at the international level, and work towards evolving a consensus for IDN ccTLDs formulation from the point of view of technical and operational stability, security as well as addressing public-policy issues.
Introduction and Delegation of IDN ccTLDs =========================================
17. Procedure for delegation of an IDN ccTLD should follow GAC ccTLDs
principles: "Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains".
18. A mandated list / reference table of strings representing the IDN ccTLDs of countries and distinct economies, as listed in the ISO 3166-13, would facilitate management and would ensure predictability of the IDN ccTLD system.
19. Competing or confusingly similar requests should be dealt with on a case by case basis and resolved in consultation with all concerned stakeholders.
20. Policies for dealing with multiple applications, objections to applications or disputes that are currently applied for ASCII ccTLDs should be equally applied to IDN ccTLDs.
21. The decision regarding whether an existing ASCII ccTLD manager should also be the operator of a corresponding IDN ccTLD is a matter to be decided by the national/local Internet community, including the government or relevant public authority, subject to applicable legislation. In cases of dispute, ICANN should seek authoritative advice from the government or relevant public authority.
22. There should be some form of transparent communication as appropriate between ICANN and any IDN ccTLD registry to define their respective roles and responsibilities.