Skip to main content

Extending Public Comments: Fast Track Review

Updated: 17 December 2010

Per community request the first annual review of the IDN ccTLD Fast Track Process has been extended. Comments can be submitted to fast-track-review-2010@icann.org through 31 January 2011.

Proposed discussion topics are provided in the below. Interested parties are also encouraged to review the material provided in the IDN ccTLD fast Track Review session held at the recent ICANN meeting in Cartagena, Columbia. Please visit: http://cartagena39.icann.org/node/15415

To review received comments on the Fast Track Process Review, please see: http://forum.icann.org/lists/fast-track-review-2010/

 

We are nearing the one-year anniversary date (16 November 2010) of the launch of the IDN ccTLD Fast Track Process. The Final Implementation Plan for the Fast Track Process requires that the process undergo review annually. ICANN is now opening a public comments forum on the review of the process.

Commenters are asked to suggest potential changes to improve the process for the end-users, including: the respective IDN ccTLD managers, the governments as well as the users of the resulting IDN ccTLDs (both registrants and general Internet users).

The public comment period is open until 17 December 2010. There will also be a session scheduled in the ICANN meeting in Cartagena, Colombia, to further discuss the performance and potential improvement of the process, and to facilitate useful community communication about the review.

Following the close of the public comment period, Staff will produce a paper that contains analysis of the received comments as well as recommendations (if any) for changes to the Final Implementation Plan for the Fast Track Process. This paper will be publicly posted and it will be provided to the ICANN Board. The ICANN Board will consider next steps including, which of the proposed changes should be implemented and if additional community discussion is required.

To help initiate the discussion, Staff has produced the following information. It should be noted that all aspects of the Fast Track Process are under review so any other subjects can be raised and are welcomed.

As of the date of this posting:

From a financial aspect, the process was intended to cover its own costs by a recommended processing fee of 26.000USD per string requested. A total of $106.000 USD has been received to date. It should be noted that the invoicing of Fast Track requests are done towards the end of the processing, hence not all requests that have completed the String Evaluation step has yet been invoiced.

To submit comments on the Fast Track Process Review please email fast-track-review-2010@icann.org

To review received comments on the Fast Track Process Review, please see http://forum.icann.org/lists/fast-track-review-2010/

Proposed discussion topics – aspects of the developed IDN policy for the Fast Track:

Transparency: The published policy document states that requests are only published when they have successfully passed through the String Evaluation portion of the process. Before then ICANN publishes only the total number of received requests, the status the requests are in and the corresponding number of languages. In this published material there is no regarding the countries and territories requesting the TLD, nor any details of the requests’ contents.

  1. This is very useful from the perspective that in some cases the requester wishes to keep the request confidential, and in other cases ICANN has received requests that are not valid and do not fulfill the established requirements.

  2. To a certain extent, the process is not completely open and transparent. A lot of end-user inquiries have been received about which countries and territories ICANN has received requests from, which we have not been able to adequately respond to. Further, in comparison, the gTLD process will publish received requests (minus selected confidential information) after the administrative review that takes place immediately after the close of an application round.

Community Support: The policy document requires demonstration of Internet community support for the applied-for TLD string. The notion of community support and the requirement for documenting such has been a topic of discussion since the launch of the process. While examples and descriptions of what this support could entail, the Final Implementation Plan does not specify exactly the amount or detail of how one can demonstrate community support. The policy reason behind this is that the approach is different depending on geographic location, culture, and other developments in the respective countries and territories. All such different approaches are valid and appropriate to the Fast Track Process.

The following issues have been raised, that may be appropriate for discussion in this review:

  • Some do not agree with the need for community support documentation and do not understand the difference between the type of support for the string (to be established in the String Evaluation) and the type of the support for the ccTLD manager (to be established in the Delegation evaluation).
  • Some do not find it necessary to demonstrate community support for the string nor the manager. The reason being that such decisions can be made by government entities, and the need for support undermines the authority of the government in the country or territory.

Meaningfulness: The strings requested through the Fast Track Process must be demonstrated to be meaningful representations of the corresponding country or territory name. If the strings requested do not automatically fulfill this requirement through a published authoritative list, the requester must include documentation from a linguistic expert that the strings are in fact meaningful representations of the country or territory name. Some requesters have stated that this requirement is not necessary in cases where the strings requested are agreed to by the government and otherwise seem obviously meaningful.

The issue has been raised that in some cases, the strings requested do not fulfill the meaningfulness automatically. Staff is looking especially for feedback as to whether additional elements could result in automatically fulfilling this requirement, and if so, which.

Determination of the IDN ccTLD Manager: This is a topic related to the community support topic discussed above and is primarily raised here for clarification purposes.

In many cases the IDN ccTLD manager is the manager that submits the original IDN ccTLD request. However, this is not a requirement. But it results in confusion in some cases because the IDN ccTLD manager is not “evaluated” in the String Evaluation, but only subsequently in the String Delegation.

Clarifications in the long term will be beneficial on this subject (we are also trying to make this more clearly in the information provided participants in the Fast Track Process).

IDN tables: Historically the content of IDN Tables has not been evaluated and approved in any way or form by ICANN. This includes the IDN tables provided in the Fast Track Process. Staff does review the received tables in very limited capacity and only in relation to for example potential/obvious errors and to what extend the tables fulfill the requirements of the IDN Guidelines.

However there has been a discussion in the community that requesters should simply send in or refer to other IDN tables (that have already “passed through” the system) and in that way their lack of a table will not delay the processing of the IDN ccTLD request. Such behavior opens the discussion of whether there should be better or other types of checks in place to review the received IDN tables.

The responsibility of serving the community in the best possible way (and most secure way) by having measures in place with these IDN tables, including sufficient variant identification and registration rules, which is intended to avoid user confusion as much as possible is a responsibility primarily of the TLD registry. The question is, as we open up for more IDNs and IDNs generally at the top level, if additional rules should be in place.

Disputes: No controversial strings have been considered at this stage. As such, no disputes between requesters from different territories and countries have been experienced. Disputes between requesters from the same country or territory needing to deal with and decide locally which requests proceeds seems to be working adequately at this stage. The approach to date is that there needs to be agreement within a country or territory before a fast Track request can be processed.

It might be useful to have a discussion about what action, if any, ICANN should take in situation where one part of a government or relevant public authority provides the necessary support documentation for an IDN ccTLD request, but another part of the same government or public authority states an opinion which could be considered opposite. This situation could occur during String Evaluation, String Delegation or post delegation

Confusingly similar string: Some issues have arisen out of requested strings that are confusingly similar to existing strings and/or other requested-strings. The confusability is determined by the DNS Stability panel, which works well, although there is some cases has been demonstrated different opinions on whether a string is confusingly similar or not. Staff believes that the DNS Stability Panel working guidelines are adequate as they supply a careful approach to what strings are approved as TLDs, especially due to the limited nature of the Fast Track Process. Nonetheless this has been raised as a topic of discussion.

Objection/re-evaluation rights: It has been noted by the community that there are no re-evaluation or objection mechanism for declined IDN ccTLD requests. The primary reason for this is that the Fast Track Process is considered an interim process, short-termed for those countries and territories where there is no controversy with implementing IDN ccTLDs. As such if there are any disputes or issues coming up through the evaluation, such should be referred to the coming long-term process for IDN ccTLDs. The long-term process is currently in the policy developed phase in the ccNSO. Question is if the Fast Track Process should be expanded to include such options, or if it should stay in its limited capacity.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."