555
12th April 2009, 01:59 AM
Page 32: http://www.icann.org/en/topics/idn/fast-track/draft-implementation-plan-cctld-clean-19feb09-en.pdf
7.4 Discussion of Contention Issues with Existing TLDs and new gTLD Applications
During implementation of the Fast Track process and the process for introducing new gTLDs, a potential contention has been identified between Fast Track requested IDN ccTLD strings and:
•
Existing gTLD strings
•
Existing ccTLD strings
•
Proposed strings in new gTLD applications
These contention issues can involve two or more strings that are identical or are so confusingly similar that they cannot coexist in the DNS.
Some cases will be covered as the process for introducing new gTLDs requires government support if the proposed string represents a country or a territory name. However, in rare cases, an applied for
generic string could be identical or confusingly similar to a requested IDN ccTLD string, without the gTLD string being submitted for the same purpose as the IDN ccTLD string.
This issue is made more complex by Fast Track requests being considered confidential until the end of the request and evaluation stage (see Module 5) while all applications in the New gTLD Program are
public as soon as the application period closes.
While contention situations between Fast Track requests and new gTLD applications are unlikely to occur, ICANN received several comments on this topic revealing that it is necessary to:
•
Have adequate coordination in place between the two processes to identify any strings that are in conflict (i.e., identified as very similar) as early as possible.
•
Have an adequate procedure in place to determine, in the case of contention, which application prevails over the other(s).
In response to these comments, ICANN proposes the following rules and thresholds to benefit the Fast Track applicant as much as possible because the Fast Track applicant is requesting a country or
territory name.
Assessments of whether strings are considered in conflict with existing or applied-for new gTLD strings are made in the technical
32
Draft Implementation Plan for the IDN ccTLD Fast Track Process
validation step for Fast Track requests and in the initial evaluation step for new gTLD applications. The following supplemental rules are proposed to adequately address contention cases between
the processes.
A.
A gTLD application that is approved by the ICANN Board will be considered an existing TLD in inter-process contention unless it is withdrawn. Therefore, any other later application for the same
string will be denied.
B.
A validated request for an IDN ccTLD will be considered an existing TLD in inter-process contention unless it is withdrawn. Therefore, any other later application for the same string will be denied.
•
For the purpose of contention, an IDN ccTLD string is validated once it is confirmed that the string is a meaningful representation of the country or territory and that the string has passed the
Technical Committee evaluation.
C.
Upon receipt of an IDN ccTLD request, if contention is identified with a new gTLD application not yet approved by the ICANN Board, the new gTLD application will be placed on hold and the IDN ccTLD
request will prevail, provided it passes validation. However, if both parties have the requisite government assent, both applications will be placed on hold until the contention is resolved through
agreement between the parties.
7.5 IDN Table Procedure
An IDN Table is a list of all those characters that a particular TLD registry supports beyond the twenty-six letters of the basic Latin alphabet (a-z), ten digits (0-9), and the hyphen ( - ). If any
characters in a table are considered to be variants of each other (essentially meaning “the same as”), this is indicated next to each character in a variant group. The term “variant” designates
orthographic equivalence on the character level, such as that between “æ” and “ae” in “encyclopædia” and “encyclopaedia”, but not in the broader sense that pertains to the variant spelling of words,
as “encyclopaedia” vs. “encyclopedia” or “color” vs. “colour”.
An IDN Table will typically contain characters that either represent a specific language, or are taken from a specific script without particular reference to any of the languages that are written with it.
The term “IDN Table” as it is used here, corresponds to what in previous contexts was referred to as a “variant table”, a ”language variant table”, a “language table”, or a “script table”.
In accordance with the IDNC WG Final Report and consistent with the IDN Guidelines, an IDN Table identified is required for IDN registries. The table must indicate the script(s) or language(s) it is
33
Draft Implementation Plan for the IDN ccTLD Fast Track Process
34
intended to support and any variant characters as defined above must be identified in the table.
The IDNC WG Final Report says that countries and territories using the same script are encouraged to cooperate in developing a language/script table in accordance with the IDN guidelines.
Based on the IDNC
recommendation and on the input and comments received on this topic, ICANN prepared a paper (Development and use of IDN tables and character variants for second and top level strings )
providing proposed implementation details on this subject. The paper provides definitions of IDN Tables and character variants. The benefits to TLD registries that plan to introduce IDNs
(either at the second or top level) are described. The paper also proposes an outline for developing an IDN Table and a methodology for how ICANN should use the IDN Tables provided in the
criteria for the TLD allocations and management.
The paper is posted in conjunction with this revised Draft Implementation Plan, and comments are sought in preparation for a finalized Implementation Plan.
7.6 Proposed Evaluation of Fast Track the Process
To ensure that the Fast Track process functions in the best interests of the entire Internet community and for the benefit of registrants, the following review process is proposed.
Every 12 months following the opening of the Fast Track process, ICANN should open a period for public comment on the functionality of the process. The public comment period should last at least 45 days.
At the conclusion of the comment period, ICANN should analyze the comments received and seek community guidance and feedback on such comments, in particular from the ccNSO, GAC, GNSO, ALAC and the SSAC.
If necessary, based on these consultations, the Fast Track process can be modified to better suit the needs of the community. If such changes are implemented, a one-month notice must be provided publicly,
containing clear descriptions of the changes that are introduced and their impact on prospective IDN ccTLD managers.
Based on the comments received on this topic ICANN will schedule a review of the Fast Track process as proposed. Depending on the time required to complete the ccNSO PDP on IDNs, one or more such
reviews may take place.
7.4 Discussion of Contention Issues with Existing TLDs and new gTLD Applications
During implementation of the Fast Track process and the process for introducing new gTLDs, a potential contention has been identified between Fast Track requested IDN ccTLD strings and:
•
Existing gTLD strings
•
Existing ccTLD strings
•
Proposed strings in new gTLD applications
These contention issues can involve two or more strings that are identical or are so confusingly similar that they cannot coexist in the DNS.
Some cases will be covered as the process for introducing new gTLDs requires government support if the proposed string represents a country or a territory name. However, in rare cases, an applied for
generic string could be identical or confusingly similar to a requested IDN ccTLD string, without the gTLD string being submitted for the same purpose as the IDN ccTLD string.
This issue is made more complex by Fast Track requests being considered confidential until the end of the request and evaluation stage (see Module 5) while all applications in the New gTLD Program are
public as soon as the application period closes.
While contention situations between Fast Track requests and new gTLD applications are unlikely to occur, ICANN received several comments on this topic revealing that it is necessary to:
•
Have adequate coordination in place between the two processes to identify any strings that are in conflict (i.e., identified as very similar) as early as possible.
•
Have an adequate procedure in place to determine, in the case of contention, which application prevails over the other(s).
In response to these comments, ICANN proposes the following rules and thresholds to benefit the Fast Track applicant as much as possible because the Fast Track applicant is requesting a country or
territory name.
Assessments of whether strings are considered in conflict with existing or applied-for new gTLD strings are made in the technical
32
Draft Implementation Plan for the IDN ccTLD Fast Track Process
validation step for Fast Track requests and in the initial evaluation step for new gTLD applications. The following supplemental rules are proposed to adequately address contention cases between
the processes.
A.
A gTLD application that is approved by the ICANN Board will be considered an existing TLD in inter-process contention unless it is withdrawn. Therefore, any other later application for the same
string will be denied.
B.
A validated request for an IDN ccTLD will be considered an existing TLD in inter-process contention unless it is withdrawn. Therefore, any other later application for the same string will be denied.
•
For the purpose of contention, an IDN ccTLD string is validated once it is confirmed that the string is a meaningful representation of the country or territory and that the string has passed the
Technical Committee evaluation.
C.
Upon receipt of an IDN ccTLD request, if contention is identified with a new gTLD application not yet approved by the ICANN Board, the new gTLD application will be placed on hold and the IDN ccTLD
request will prevail, provided it passes validation. However, if both parties have the requisite government assent, both applications will be placed on hold until the contention is resolved through
agreement between the parties.
7.5 IDN Table Procedure
An IDN Table is a list of all those characters that a particular TLD registry supports beyond the twenty-six letters of the basic Latin alphabet (a-z), ten digits (0-9), and the hyphen ( - ). If any
characters in a table are considered to be variants of each other (essentially meaning “the same as”), this is indicated next to each character in a variant group. The term “variant” designates
orthographic equivalence on the character level, such as that between “æ” and “ae” in “encyclopædia” and “encyclopaedia”, but not in the broader sense that pertains to the variant spelling of words,
as “encyclopaedia” vs. “encyclopedia” or “color” vs. “colour”.
An IDN Table will typically contain characters that either represent a specific language, or are taken from a specific script without particular reference to any of the languages that are written with it.
The term “IDN Table” as it is used here, corresponds to what in previous contexts was referred to as a “variant table”, a ”language variant table”, a “language table”, or a “script table”.
In accordance with the IDNC WG Final Report and consistent with the IDN Guidelines, an IDN Table identified is required for IDN registries. The table must indicate the script(s) or language(s) it is
33
Draft Implementation Plan for the IDN ccTLD Fast Track Process
34
intended to support and any variant characters as defined above must be identified in the table.
The IDNC WG Final Report says that countries and territories using the same script are encouraged to cooperate in developing a language/script table in accordance with the IDN guidelines.
Based on the IDNC
recommendation and on the input and comments received on this topic, ICANN prepared a paper (Development and use of IDN tables and character variants for second and top level strings )
providing proposed implementation details on this subject. The paper provides definitions of IDN Tables and character variants. The benefits to TLD registries that plan to introduce IDNs
(either at the second or top level) are described. The paper also proposes an outline for developing an IDN Table and a methodology for how ICANN should use the IDN Tables provided in the
criteria for the TLD allocations and management.
The paper is posted in conjunction with this revised Draft Implementation Plan, and comments are sought in preparation for a finalized Implementation Plan.
7.6 Proposed Evaluation of Fast Track the Process
To ensure that the Fast Track process functions in the best interests of the entire Internet community and for the benefit of registrants, the following review process is proposed.
Every 12 months following the opening of the Fast Track process, ICANN should open a period for public comment on the functionality of the process. The public comment period should last at least 45 days.
At the conclusion of the comment period, ICANN should analyze the comments received and seek community guidance and feedback on such comments, in particular from the ccNSO, GAC, GNSO, ALAC and the SSAC.
If necessary, based on these consultations, the Fast Track process can be modified to better suit the needs of the community. If such changes are implemented, a one-month notice must be provided publicly,
containing clear descriptions of the changes that are introduced and their impact on prospective IDN ccTLD managers.
Based on the comments received on this topic ICANN will schedule a review of the Fast Track process as proposed. Depending on the time required to complete the ccNSO PDP on IDNs, one or more such
reviews may take place.