Egypt’s top-level domain .eg is operated by the Egyptian Universities Network (EUN) (http://www.iana.org/domains/root/db/eg.html). The Arabic script top-level domain .masr (مصر, http://www.iana.org/domains/root/db/xn--wgbh1c.html) is operated by the National Telecommunication Regulatory Authority of Egypt (NTRA) (http://www.iana.org/domains/root/db/xn--wgbh1c.html).

The primary servers they operate have been inaccessible to those outside of Egypt since January 27. Secondary DNS servers for .eg, located in Austria and the United States, have continued to function with data provided before the shutdown.

The .مصر DNS servers are exclusively in Egypt and there do not appear to be any secondary DNS servers outside the country. This means that service to sites served by this top-level domain are unreachable by the rest of the world.

Secondary servers copy their data from the primary server at regular intervals. Data in the secondary DNS servers, serving anyone in the world wishing to receive .eg DNS services, have an expiration date. Secondary servers require regular updating from the primary server at specified intervals – called “time to live” (TTL) – and that time is set to expire in 140 days.

Normally when primary servers fail – for example, following the earthquake in Haiti – the operator wants secondary servers to continue operating with the last zone file they had provided. This allows users around the world to connect to functioning servers in their zone.

ICANN’s Manager for Regional Relations for the Middle East has been communicating with both TLD operators, EUN and NTRA. The operators of .eg have communicated with ICANN and through ICANN are communicating with the secondary operators outside the country. They have requested that the secondary operators continue using the existing zone files past their time to live timeframes, if necessary.

This experience offers a number of lessons, among them that a policy to encourage the establishment of secondary servers to promote continuity of service as well as DNS stability could be useful and in the global public interest. ICANN will ask the ccNSO to consider proposing a policy to address this type of situation.

ICANN helps to ensure a secure and stable global Internet through its coordination of the domain name system, and is the global policy development body for the DNS and related matters. More than 100 ccTLD operators are voluntary members of the Country Code Names Supporting Organization (ccNSO), a formal ICANN policy and coordination body.

It turned out they needed less than three hours to reach to the 100,000 domain names! Such a gold rush was not expected, and numbers continued to grow – 200,000 within 6 hours from the beginning of the registration period. And more than 460,000 by today.

The registration process, which clearly exceeded (and continues to exceed) all expectation, includes some interesting details, for example there is a list of 4023 words, which are not allowed for registration. The so-called “black list” contains variations of all different vulgar words, known in the Russian language. However, users have already found ways to bypass it, with simply adding another word in front, or after the blacklisted words.

We’ll be waiting to hear more on the history and the development of the Russian IDN ccTLD during the ICANN meeting in Cartagena, where several of the Russian ccTLD top management people will be present.
And we’ll prepare a posting on that topic, with more details for the general public. We hope that these details might be helpful in the launch of other new TLDs.

There are hundred of publications in the Russian central media, and even more all over the web, with people sharing opinions about who might be these registrants, why there are so many domains registered, and what does the fact of so many domains mean for the Russian Internet. It will be also interesting to see in exactly one year how many of these domains will be renewed. But certainly the Russian IDN ccTLD has made history.

More on the Russian ccTLD Coordination Center here (in Russian).

More on the ICANN IDN program here.

Interesting background information
The Cyrillic IDN ccTLD started as an idea, discussed during the meeting of the Bulgarian President Georgi Parvanov with his Russian colleague President Vladimir Putin on January 18, 2008 in Sofia, Bulgaria. The Bulgarian President’s office published last week the transcript from that meeting. Asked by President Putin, the Russian foreign minister responds, “As for the usage of Cyrillic in the Internet, our experts have already reviewed these issues, we have contacts with the international structures [ICANN], now we are solving the technical questions and the contacts between our specialists on that issue, of course, will confirm our commitment that Cyrillic should be used in the domain names. As for the consultations, as a whole, we are very happy from our cooperation [between Russia, Bulgaria, and ICANN].”

UPDATE FROM November 18, 2010:
As of today, November 18, the number of domains in .рф (.rf IDN ccTLD) passed half a million. As the Coordination Center announced, the 500000th domain registered was металлоконструкции74.рф (xn--74-6kctqamahahrlb5apjiu5d.xn--p1ai – in puny-code). This number brings .рф on 17th place among all European domains. Domains, which were delegated, or a working, account to more than 162,000. Most of them are already used in advertising, not only as single words, but as whole phrases, which are easy for the Russian speaker to understand.

A delegation from ICANN, headed by President and CEO Rod Beckstrom and including Barbara Clay, Tina Dam and Veni Markovski, was in Moscow on a 3-day visit, and participated actively in a number of events (in time order):

- A meeting at the Institute for Information Security Issues (IISI) – the organization that has signed an MoU with ICANN and that is organizing the Garmisch Meeting on Security*. Col.-Gen. Sherstyuk** discussed with ICANN opportunities for further cooperation in the field of internet security.

- Visit to former Soviet President M.S. Gorbachev – the conversation covered a number of issues, not only related to the Internet, and gave us the opportunity to explain the development of the IDN ccTLD, and the gTLD policies. Mr. Gorbachev was particularly impressed by his guests’ remarks about his role in changing the history of Eastern Europe, and the freedom and opportunities this brought to the whole world.

- Rod gave five exclusive interviews, including Reuters and four major Russian media. The Reuters interview was published in many media in countries all over the world, and in Russian, Spanish, Portuguese, Chinese, French, etc. Some of the Russian language pieces could be found here: Rossiiskaya gazeta, Chastnii korrespondent, and Computerra, and some of the English langauge ones are at Radio Free Europe, and at RT (watch the video there).

Russian Internet Governance Forum and official Launch of the Russian .рф IDN ccTLD
The Ministry of Telecom and Mass Communications and the Russian ccTLD Coordination Center organized a great Internet Governance Forum – IGF. The Coordination Center arranged an amazing list of speakers, proving that they are indeed a professional registry, with great staff and leadership.

At the opening of the Forum, the Russian Minister of Communications, Igor Schegolev, praised ICANN for the work it has done, and Rod delivered a special plaque to Andrei Kolesnikov (attached), CEO of the Coordination Center for .ru ccTLD, to confirm the Center was approved as the operator of the new .рф Cyrillic IDN ccTLD.
The opening session included Rod’s keynote address and speeches by Larry Strickling, Col.-Gen. Sherstyuk, Chuck Gomes (GNSO), Chris Disspain (ccNSO), Wolfgang Kleinwachter (NomCom) as well as Russian politicians and businessmen. A full recording (MP3) could be downloaded from the site of the organizers (110 Mb)
here was a VIP lunch, given by the Minister for the top Russian and US officials*** and the ICANN delegation. With lots of greetings, and in a cheerful atmosphere, the lunch allowed informal communication to take place.
Later that day Rod participated in a panel discussion on security, sharing the stage with cyber experts from CISCO, Kaspersky, Lille University, the Russian Parliament, and others.

ICANN’s press activities for these two days produced stories in more than 100 publications, all of them positive about ICANN and the IDN ccTLD program.

But that was not all – IDN “guru” Tina Dam participated in a panel on IDNs, and special attention was paid to her for her achievements, and Veni Markovski was a panelist talking about the governance of the Internet critical infrastructure.

The first day of the Russian IGF ended on a high note, with a cruise for all participants on the Moscow River.

In conclusion, the visit was a big success. ICANN is today more respected, has more friends, and is better known in Russia, than it was before.

Having said that, the work is not done. There are a number of items on the agenda in Russia and the region which require constant attention, cross-cultural knowledge, and good communication. ICANN top executives were able to see and understand this with their own eyes. The investment in improving relations with Russia paid off – less than two years ago nobody believed that ICANN would be welcome in Russia, that Russia would join the GAC, and that such good and positive relations were possible.

The launch of the Cyrillic IDN ccTLD was the focus of this visit, and it was well navigated on two continents, with a 9 hour time zone difference, and included dedicated work between IANA, Tina Dam, regional liaisons, top management, to make sure that not only it will be successful, but it will be a great celebration for the Russian Internet. ICANN performed at its best, and so did the Russians.

Congratulations, Russia! And good luck to the new IDN ccTLD .рф! And thank you, everyone, for the great time, wonderful launch, and being such good hosts!

Notes:
- Pictures from the Russian IGF could be seen here, and from the other meetings – here.
- We are deliberately not putting the names of all the people from Russia, who organized the Russian IGF, and who helped for the success of the ICANN’s visit. We don’t want to omit anyone, but we are thankful to everyone. Спасибо!
__________
* – The Garmisch meeting takes place every year in April, and ICANN is an active participant and supporter; last April George Sadowsky, Greg Rattray, Yurie Ito and Veni Markovski spoke there.
** – Col.-Gen. Sherstyuk is head of the IISI, and undersecretary of the Russian National Security Council to President Medvedev
*** – Besides Assistant Secretary Strickling, the US delegation included Ambassador Philip Verveer, Fiona Alexander, as well as representatives from State Department, Department of Commerce, the US Embassy in Moscow, and others.

IDN ccTLDs in the DNS root zone:

Egypt: مصر (Egypt)
Saudi Arabia: السعودية (AlSaudiah)
United Arab Emirates: امارات (Emarat)

- in addition Russian Federation: рф (rf) is approved by the ICANN Board for delegation, and related activities are scheduled for the Russian Internet Governance Forum http://russia2010.intgov.net/eng/program.php (next week)

A big congratulation to all four countries from the ICANN Team on reaching these goals! We are very much looking forward to seeing how the market will adopt and use these IDN ccTLDs.

Also a big THANK YOU goes out to all of those in the communty that have worked on this for years. That is, those on the ground at the various registries and governments that have worked actively locally; the IDNA protocol authors for outstanding technical volunteer work for years; the policy makers for getting the processes ready; application developers for making sure that IDNs functions in all new versions of the main browsers – and so forth.

IDN ccTLDs ready for TLD Delegation:

The last step in the Fast Track Process is the delegation step. Once requests successfully meet string the evaluation criteria they are eligible to apply for delegation. This is following the same ICANN IANA process as is used for ASCII based ccTLDs.

A total of nine (9) countries/territories are current at this stage. A full list of them, the IDN ccTLDs, and contact details are available here: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

The languages include: Chinese, Arabic, Sinhalese, Tamil, and Thai.

IDN ccTLDs under evaluation

In addition to everything listed above, ICANN is currently processing requests from eight (8) countries/territories. As soon as these have completed the String Evaluation” criteria they will be added to the list at: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

IDN ccTLD Fast Track Process looking forward

As is clear from all the positive IDN news, the fast Track Process is working really well for many countries. Part of making sure that it works effectively for all users is a review of the process. This is scheduled annually, which would be 16 November 2010. Staff is currently reviewing whether a review should take place sooner.

Also, as stated in the Fast Track Process, variant TLDs cannot be introduced until a method for this is made available. Please see a previous blog post for details on work that still needs to be done on this subject: http://blog.icann.org/2010/04/update-about-synchronized-idn-cctlds/

We hope to come with a more detailed plan on this soon.

IDN usability

Finally, we continue to receive a lot of questions concerning usability. The IDNs works well. We are working on a blog post with usability examples and explanations, and will publish this shortly.

Meanwhile, if you have experience with the new IDN ccTLDs please send them to us either as comments to this blog post, or directly to me at tina.dam@icann.org

What you should be seeing is something like the following:

It even works on a mobile phone:

The three new top-level domains are السعودية. (“Al-Saudiah”), امارات. ( “Emarat”) and مصر. (“Misr”). All three are Arabic script domains, and will enable domain names written fully right-to-left. Expect more as we continue to process other applications using the “fast track” methodology.

ICANN staff are still finishing the processing of these domain’s delegations, but now that they are visible in the root zone it is fair to say these are mostly formalities. The remaining tasks include final technical verifications, updating the IANA WHOIS database and publishing the delegation reports.

Now the hard work happens in the countries which have their new IDN ccTLDs. They will now commence their own processes to launch the domains in a way that gives their communities access to put them to day-to-day use.

As you may know, one of the ICANN Board resolutions from the recent ICANN meeting in Nairobi directed staff to develop an extension to the Fast Track Process: a mechanism to introduce Synchronized IDN ccTLDs. A Proposed Implementation Plan was subsequently published for public comments.

The Proposed Implementation Plan can be found here: http://icann.org/en/announcements/announcement-22mar10-en.htm

Since Synchronized IDN ccTLDs in the Fast Track context is a new concept, naturally this has raised some concerns and confusion. The best place to record comments and questions is in the public forum: http://icann.org/en/public-comment/#synch Still, we thought it would be helpful to point to some resources, and answer questions we have seen in mail lists and elsewhere.

If you haven’t read it yet, we encourage you to read the recently published Q&A. The Q&A addresses concerns raised by the technical community due to the usage of certain terminology in the Board resolution and the Proposed Implementation Plan. In particular the Q&A explains that “synchronized” relates solely to policy and procedural requirements. The Q&A further clarifies that there is no (DNS) technical mechanism by which domains under Synchronized IDN ccTLDs will be made to resolve identically (same address/value etc) at the DNS protocol level. As a result, from a purely technical/DNS protocol perspective, two synchronized IDN ccTLDs are simply two separate delegations from the root zone.

If you have further questions, we encourage you to attend one or both of two upcoming webinars. These webinars will be recorded and the recordings will be published at the public comment forum for review by all interested parties. The webinars are scheduled for 14 April at 01:00 and 14:00 UTC. Registration and access information can be found at: http://icann.org/en/announcements/announcement-2-08apr10-en.htm or directly at the e-learning site at: http://icann.org/en/learning/

In addition it is important to note that the plan for synchronized IDN ccTLDs is not a general statement from ICANN about how all variant TLD introductions can or should be made. Quite the contrary, the requirements in the Proposed Implementation Plan for Synchronized IDN ccTLDs assures that it is limited. As one example of these limitations it is required that Synchronized IDN ccTLDs request first must complete the String Evaluation step in the Fast Track Process. Again, the Synchronized IDN ccTLD Process is an extension of the Fast Track Process and all Fast Track rules apply.

Given these designed-in requirements/limitations, the volume of Synchronized IDN ccTLDs will not really increase the total volume of new TLDs already contemplated within the Fast Track Process. Also, confusingly similar IDN ccTLDs will not be allowed for delegation regardless of whether they are considered synchronized or not (this type of variant TLDs needs additional work, see below). And, there are no current activities ongoing towards a notion of “Synchronized IDN gTLDs”.

As mentioned, more work is required to create a general mechanism by which all variant IDN TLDs (not just the very limited set of Synchronized IDN ccTLDs) can be introduced. The term variant has been used loosely; other related terminology used is aliasing, sameness, and so forth. A clarification of the terminology and what is meant by it is needed before the ongoing work can be initiated. A more general solution depends on (at least!):

• Definition of what exactly it is that is being sought by a “variant solution”. What is the desired behavior of variants in all cases?

• Definition of the different types of variants – which may inform the answers to 1).

• Review and test of DNAME as a technical solution, and its adequacy to achieve variant TLD management.

• Review/test of BNAME as a technical solution, and its adequacy to achieve variant TLD management. It is noted that the BNAME proposal is rather new and currently exist as an Internet Draft in the IETF.

• Review/test of variant management via procedures and registration policies. This based on the experience with the Synchronized IDN ccTLDs.

Along with the technical community, ICANN wants to contribute to finding the answers to these questions, and is launching a project to address them. Part of this work will be looking to use the community experience on this subject. In particular ICANN is seeking advice from the technical community, such as for example the work currently ongoing in the IETF/DNSEXT on the subject of sameness and variants in context of the DNS.

Meanwhile we look forward to your comments in the public forum, and your participation in the upcoming webinars!

The overall rules seem clear:

1) If you apply for an IDN ccTLD that is confusingly similar with an existing ccTLD, gTLD, or reserved name, then your request will be declined.

2) If you request an IDN ccTLD that is confusingly similar to a “validated” IDN ccTLD, then your request will be declined.

3) If you request an IDN ccTLD that is confusingly similar to another IDN ccTLD under evaluation, and yet not “validated”, then both request will be placed on hold until a solution is found.

4) If you request an IDN ccTLD that is confusingly similar to an applied-for gTLD string that has reached Board approval, and hence considered an existing TLD, then your request will be declined.

5) If you request an IDN ccTLD that is confusingly similar to an applied-for gTLD string, then both parties will be informed.

Validation, for the purpose of the Fast Track Process means that it has been established that the string is a meaningful representation of the corresponding country/territory name, and that it has successfully passed the DNS Stability Panel evaluation.

However, it is the notion of confusingly similar and exactly how it is established that two or more strings are so confusingly similar that they cannot co-exist in the DNS, that reasonably is raising questions.

As the Final Implementation Plan states, any such determination is on a case-by-case basis. However, it is probably useful to provide some insight into how the panel makes such a determination.

While the determination is done by the DNS Stability Panel, Fast Track participants should know that ICANN staff will provide them with concerns about confusability (if such is found) during the initial review of a Fast Track request. The requester then has the opportunity to either (i) change the string they requested, (ii) withdraw the request and resubmit at a later stage, or (iii) continue with the request as originally submitted.

Type styles, fonts, etc.

Issue: A sufficiently creative choice of type styles or the exploitation of information about scripts that a given user may be unable to display can result in one character (or a sequence of characters) in one script being visually confusable with one or more characters (or character sequence(s)) in another script.

The issue becomes even more serious for closely related scripts (for example, Greek/Latin/Cyrillic).

While we are aware of the issues, some level of risk must be accepted. These kinds of issues cannot be completely guarded against, especially as type styles and fonts (just like languages and scripts) evolve and change over time.

Instead, determining confusability is focused on issues that may arise from the basic geometry of characters that is preserved, to a greater or lesser degree, across a variety of fonts, styles, and formatting.

Two-character strings

Issue: Two-character strings that consist of Unicode code points in scripts such as the Latin, Greek, and Cyrillic script blocks are intrinsically confusable with currently defined or potential future country code TLD (ccTLD) strings based on the ISO 3166-1 alpha-2 codes.

This is particularly true when variations in font and presentation interface are considered. And it is not limited to the pairs of “visually confusable characters” identified in Unicode Technical Report #39. Those characters are based on Unicode Reference Fonts that are deliberately designed to reduce the potential for visual confusion.

Therefore, a very conservative standard is being used to assess applied-for strings that consist of two Greek, Cyrillic, or Latin characters, including a default presumption of confusability to which exceptions may be made in specific cases.

How are strings ranked?

The Fast Track Process recognizes the following rankings for requested two-character IDN ccTLD strings. The higher the rank the more likely the applied-for string as a whole presents a significant risk of user confusion.

[6] Both characters are visually identical to an ISO 646 Basic Version (ISO 646-BV*) character. [International Organization for Standardization, "Information Technology – ISO 7-bit coded character set for information interchange," ISO Standard 646, 1991.]

[5] One character is visually identical to, and one character is visually confusable with, an ISO 646-BV character.

[4] Both characters are visually confusable with, but neither character is visually identical to, an ISO 646-BV character.

[3] One character is visually distinct from, and one character is visually identical to, an ISO 646-BV character.

[2] One character is visually distinct from, and one character is visually confusable with, an ISO 646-BV character.

[1] Both characters are visually distinct from an ISO 646-BV character.

Some disagreement may arise in assessing whether a string is confusingly similar with existing ccTLDs, gTLDs, or applied-for strings. Thus, these rankings are for guidance only, and the DNS Stability Panel makes its assessment based on the rankings and on the expertise of the panelists. In difficult situations, the panel may conduct extended evaluations that also can include drawing on additional linguistic expertise.

The likelihood of user confusion presented by a given two-character IDN ccTLD string does not depend strictly on the individual confusability of each character, if considered separately. The assessment of “visually distinct” and “visually confusable” takes into account both the individual features of each character and their combined effect.

In general, a two-character IDN string at rank [4] or higher presents a significant risk of user confusion.

In general, a two-character IDN string at rank [3] or lower does not present a significant risk of user confusion.

What about confusable strings already in the DNS root zone?

Some have argued that we already have TLDs in the DNS root zone that could be considered confusingly similar, so there is no need to prevent future confusingly similar strings from being entered in the root zone as well. There is only one answer to such statement: Just because there are issues today does not mean that we should make it worse for the future!

Finally, thank you to the DNS Stability Panel for all their work in this area and for generating the rankings based on their professional experience and prelaunch training!

None of this information replaces or changes the information available and defined in the Final Implementation Plan for the IDN ccTLD Fast Track Process. It is merely an elaboration of that published information.

First, note that community support for a string is different and specifies different requirements than community support for the IDN ccTLD sponsoring organization.

• Support for the string is required in the String Evaluation step of the Fast Track Process.
• Support for the sponsoring organization is required later, during the String Delegation step of the Fast Track Process.
This separation in process means:

1. Evaluation of the desired string is completely separate and distinct from evaluation of the appropriate sponsoring organization for an IDN ccTLD.

2. The sponsoring organization does not need to be identified until the String Delegation step begins.

3. Only rarely would the same documentation be appropriate to demonstrate support for both a string and its sponsoring organization, as two different types of support are being required and evaluated.

• While the letters requesting string selection and support involve a requester stating preferences for a string, the letters involved in the delegation process are used to corroborate a selection process and a community consensus-building process for the proposed operator.

The community string support requirement specifically ensures that the Internet community takes part in the decision for a string.

This requirement is part of the Linguistic Process Validation in the Final Implementation Plan, as stated here:

That the received documentation of community support for the string(s) is satisfactory.
• This should be demonstrated in a similar manner as required for delegation requests, see Module 5, Appendix 2 for guiding information.

The nature of community support can, and is expected to, vary from country to country and between territories. Differences in cultures mean different ways of consulting Internet users, and hence different ways of gathering the necessary supporting material. Signed form letters are not considered adequate for participants to express their support.

Despite the difference in the approach taken, the selection of a string to represent a country or territory must be in the interests of the Internet user community of the country or territory. Thus, there should be dialogue in the country or territory about what string(s) should be selected to best support the local Internet community.

The following are examples of questions a requester may be asked. They enable staff to successfully complete the Linguistic Process validation.

In particular we are looking for information such as:

1. What kind of dialogue, outreach, survey or other types of events has taken place to select the string requested?

2. How was consensus reached on the requested string during such activities?

3. What alternative strings were considered and why were they rejected?

4. Was any opposition to the requested string received? If yes, which?

In evaluating these information elements, staff will put weight on a process that:

• Allows for people that do not have the same view to participate;

• Is open and consultative; and

• Allows differing points of view to be expressed.

In addition, it is helpful for a requester to provide a chronology or narrative of the process (not just the final decision), and at least a general description of who had access to, or was involved in, the event(s) at which the decision was reached.

• ICANN denying some countries/territories access to the Fast Track Process
• ICANN approving IDN ccTLDs
• The notion of pre-registrations in new TLDs

This blog post is intended to set the record straight on these matters.

Is ICANN denying access to the Fast Track Process?
Let me be very clear: The Fast Track Process for submitting requests for IDN ccTLD strings is available to all eligible countries and territories. Statements like ICANN has refused IDN ccTLDs to some countries are incorrect. ICANN encourages eligible countries and territories to participate in the process and submit their IDN ccTLD requests.

This is an exciting new opportunity for Internet users around the world, and we would like to see as many users being served by these new initiatives as possible and as are deemed useful.

ICANN also has a support function in place at idncctldrequest@icann.org for interested parties.

So far, ICANN has received 17 requests encompassing 10 languages. These numbers will be updated from time to time at http://icann.org/en/topics/idn/fast-track/.

To comply with the confidentiality requirements of the process, ICANN cannot disclose any additional information. We cannot state whether a particular request has been received, or how far along the process a request is. We understand that the public has a great deal of interest in potential future IDN ccTLDs, and therefore some requesting entities have elected to publicly disclose information about their requests.

However, the only time ICANN can make information available about a request is after it successfully passes the String Evaluation step.

What strings are ‘approved’ and what does it mean?
Four IDN ccTLD strings were recently announced as successfully completing the String Evaluation step of the Fast Track Process. These requests are associated with Egypt, the Russian Federation, Saudi Arabia, and the United Arab Emirates. The full announcement is here: http://icann.org/en/announcements/announcement-21jan10-en.htm.

However, passing the String Evaluation step is not the same as saying that ICANN approved these TLDs. These four entities must go through the final step in the Fast Track Process – String Delegation. The String Delegation step must be initiated by the respective country or territory, and that can only be done with requests that have successfully met the String Evaluation criteria. String Delegation follows the same ICANN IANA process that is used for ASCII-based ccTLDs, and thus String Delegation requests are submitted to IANA root zone management.

Only after String Delegation takes place will these TLDs be in the DNS root zone, and only then can resolutions requests against them be performed. In other words, this is when domains can be registered and used.

Has ICANN authorized pre-registration of TLD domain names?
ICANN has not authorized pre-registration of domain names in any potential future TLDs.

The reason is simple: There is no way to be sure that a certain string will become a TLD and hence available for domain name registration until all steps in the associated evaluation and delegation processes are successfully completed.

ICANN has previously posted warnings concerning speculative pre-registrations, and those warnings are still informative. You can review them at http://www.icann.org/en/announcements/icann-pr29sep00.htm

These are associated with: Egypt, the Russian Federation, United Arab Emirates, and Saudi Arabia.

See the full announcement here: http://icann.org/en/announcements/announcement-21jan10-en.htm

So what does that mean?

It means that these may now initiate the String Delegation process, which is the last step before the strings are actually in the DNS root zone and hence available for use.

The remaining 12 requests are still being processed and at ICANN we are very much looking forward to completing more requests as well as receiving additional new requests

Overall, the Fast Track Process has three main steps:

1) Preparation (by the requester in the country / territory). Community consensus is built for which IDN ccTLD to apply for, how it is run, and which organization will be running it, along with preparing and gathering all the required supporting documentation.

2) String Evaluation: incoming requests to ICANN in accordance with the criteria described above: the technical and linguistic requirements for the IDN ccTLD string(s). Applications are received through an online system available together with additional material supporting the process at http://www.icann.org/en/topics/idn/fast-track/

3) String Delegation: requests successfully meeting string evaluation criteria are eligible to apply for delegation following the same ICANN IANA process as is used for ASCII based ccTLDs. String delegation requests are submitted to IANA root zone management.