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.

Since I was quoted briefly in the article, I’d like to share some additional thoughts.

Why so much Public Comment?

Public Comment periods are vital in satisfying ICANN’s goal to be a bottom-up multi-stakeholder policy making body and to provide openness and transparency in its policy development processes. An ICANN core value is to employ open and transparent mechanisms in policy development processes. Such openness promotes well-informed decisions, and ensures that people affected by a new policy can participate and assist in the policy’s formation. That’s why the Bylaws mandate public comment periods (for example, see Annex A, Sections 6 and 9).

The Affirmation of Commitments reflects the same principles, calling for ICANN to provide transparent and fact-based policy development, cross-community deliberations, and responsive consultation procedures. In the Affirmation, ICANN committed to provide detailed explanations of the basis for decisions — including how comments have influenced policy considerations.

Thus, the desire to hear all voices on each policy issue comes right from ICANN’s core. Frankly, we don’t want to limit public comments.

Is ICANN handling too many policy processes at the same time?

The answer is “No!” as soon as you consider the alternatives.

Three Supporting Organizations and a number of Advisory Committees can bring policy issues before the community. To which of them would we say, “Sorry, too busy to care about your issue; check back later”? Obviously, none of them.

An ICANN policy development process takes time to gather all viewpoints. Imagine how long it would take ICANN to address your particular policy issue if there were an arbitrary limit. If the ICANN community only handles seven or ten issues at once, that means all other issues remain parked indefinitely, probably for months. Notable achievements from this year, such as IDNs and DNSSEC going into the root, might still be waiting to happen. Do we want to slow our processes? Obviously, no. (Improve and prioritize better? Yes, indeed!)

Andrew reports that “some people” believe there are too many simultaneous policy issues pending, and are worried (with some justification) about overload in our volunteer community. This perception may be due to several factors, including:

• Our list of open issues initially looks confusing because issues have not been prioritized. The GNSO is about halfway through creating a method for prioritizing projects. Ranking their relative importance will help make them easier to take in all at once.
• Many policy-related reports exceed 100 pages. The GNSO has recently resolved that its reports should begin with an Executive Summary. This will help reduce the reading an individual has to do in deciding whether to comment.
• Our large, diverse volunteer community is avid and committed to follow the growing number of policy issues that reflects the increased global impact of the Internet.

We will also be examining the processes and mechanisms we use to manage the public comment process in hopes of identifying more effective and efficient ways to publicize, collect and organize community comments.

Policy development has an ebb and flow. Recently, we seem to be at high tide. Some of the tide will ebb when the new gTLD program launches and GNSO Improvements Initiative winds down. Five working groups will go away (one already has). Optimistically, the bulk of the GNSO improvements effort may be completed in early 2011.

We shouldn’t set an arbitrary limit to the number of issues evaluated by the ICANN Community. The issues arise from the community, and staff works diligently to support that work. We all recognize that many issues are both important and urgent to different parts of the ICANN community. I do not believe that ICANN is handling too many policy issues.

The ICANN community is also working hard to enhance our collective management of so many important issues, which is not always easy. Yet, if the current situation seems difficult, consider the alternative: Further delays in improvements to WHOIS.  The 65% of Internet users who do not speak English await IDNs in their own languages. Communities still waiting more years for their new gTLDs. Phishers continue defrauding consumers using techniques that DNSSEC can stop. If we must err, it is better for ICANN to handle too much, than for ICANN to handle too little.

Chinese:
With one billion people around the world using Chinese as their primary language, it means that one out of every five people on the planet can have benefit from the introduction of the newly approved Chinese extensions:

• .中国 and .中國 – CNNIC – the China Internet Network Information Center http://www.cnnic.cn

• .香港 – HKIRC – Hong Kong Internet Registration Corporation Limited http://www.hkirc.hk

• .台灣 and .台湾- TWNIC – Taiwan Network Information Center http://www.twnic.tw

This is also the first time that variants are allowed at top-level domains or extensions for the Internet. For CNNIC and TWNIC they each have two variants approved for delegation. Both organizations have over a decade in variant operational experience, and have published implementation plans that describe how the variants are to be managed. We hope to get some good experience in these launches that can be used generally for TLD variant management and help us make this available for others as well.

At lot of people are of course asking the obvious question: when will we be able to make registrations and what are the registration rules? They should be available shortly, but please go to the respective organization for the IDN ccTLD management for more details about registration rules, launches and timelines.

At the ICANN meeting in Brussels, where the ICANN Board approval took place on 25 June 2010, it was followed by a CDNC event. Everybody celebrated the newly approved Chinese IDN ccTLDs, with music and food – pictures to come.

Singapore and Syria:
This month’s IDN ccTLD string evaluation completions included Singapore and Syria, with:

Syrian Arab Republic: سورية (Arabic)
Singapore: 新加坡 and சிங்கப்பூர் (Chinese and Tamil)

This means that the two organizations now can submit their requests to have these strings delegated as new top-level domains for use in the Internet.

IDN ccTLD Fast Track Status:
All in all we have now received 31 requests for IDN ccTLDs from countries and territories. Together they represent 19 languages. Details can be found at: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

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.

The corresponding countries are:
United Arab Emirates, Saudi Arabia, Russian Federation, and Egypt.

This essentially means that we have started seeing domain names where the top-level/extension is either: امارات. السعودية. .рф مصر.

Congratulations to the teams behind:

• United Arab Emirates: امارات.
• Saudi Arabia: السعودية.
• Russian Federation: .рф
• Egypt: مصر.

The simultaneous delegation of the three Arabic based IDN ccTLDs was completed last week, and the delegation of the Russian IDN ccTLD was completed this week in conjunction with the Russian Internet Governance Forum: http://russia2010.intgov.net/eng/program.php

This is an history milestone and an achievement reached due to years of hard work by so many people across the world, including: technical developments with the core group in the IETF’s IDNA protocol working group; development of the policies and procedures; application development to ensure IDNs work across browser and other software; and so forth.

ICANN would like to thank everyone involved in making IDN TLDs a reality, and we look forward to seeing how IDN TLDs are embraced by users globally, and to the introduction of the next group of IDN ccTLDs. The full list will continue to be updated and can be found here: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

Some of the milestones leading to the last week’s great IDN result:

12 May 2010: Delegation of the Russian Federation IDN ccTLD

5 May 2010: Simultaneous delegation of the three first IDN ccTLDs for United Arabic Emirates, Saudi Arabia, Egypt.

22 April 2010: ICANN Board approval of the first four country delegations, for Saudi Arabia, United Arabic Emirates, Russian Federation, and Egypt.

21 January 2010: ICANN announces the first four IDN ccTLD requests as having completed step 2 (of 3) in the Fast Track Process, thereby the requested IDN ccTLDs have been approved.

16 November 2009: ICANN launches the IDN ccTLD Fast Track Process thereby opening up for countries and territories to submit requests for IDN ccTLDs.

30 October 2009: ICANN Board approves the Final Implementation Plan for the IDN ccTLD Fast Track Process, and announces the launch.

Oct 2008: First draft implementation plan for IDN ccTLD Process

Feb 2008: First report from the IDNC WG leading to IDN ccTLD Fast Track Process

Jun 2003: IDNA protocol, IDN Guidelines, initiation of browser implementation

An area of the ICANN website is dedicated to IDN resources, and includes links to all the milestones and news announcements: http://www.icann.org/en/topics/idn/

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.

The ICANN Board also took actions that are expected to expedite Chinese characters in top-level domains as part of the IDN ccTLD Fast Track. This will be the first set of variant IDN ccTLDs to be introduced – under special circumstances. More work is underway on the subject of variants, including policy-procedural analysis and technical definitions and plans for testing.

In addition, last week, a new IDN ccTLD request was announced as having passed the String Evaluation stage – for the country of Jordan. This means that Jordan now may enter the String Delegation step, which is the last step in the Fast Track Process. As such Jordan joins 13 other countries/territories having succesfully passed String Evaulation. The full list can be seen here: http://www.icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

The total number of received requests in the Fast Track Process is: 21
The total number of languages represented is: 11

To read more about the IDN ccTLD Fast Track, go here: http://www.icann.org/en/topics/idn/fast-track

If you only see boxes in the above IDN ccTLDs, then you may need to download the necessary font: http://idn.icann.org/Fonts – or perhaps you are experiencing a problem with IDNs that is not rendered correctly when viewed in various applications. Either way we’d love to hear about it

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!