As of 00:00 UTC today – 4 days after the launch of the Fast Track Process we have new requests coming in.

The total number is 10 requests. They spread over 5 different languages.

Details about the process is at: http://www.icann.org/en/topics/idn/fast-track/

Please keep asking questions. Is there is anything we can explain better? The FAQ will be updated shortly to include everything you ask here as well.

The launch went smoothly. We have since monitored the system and everything is working.

As of 10pm Pacific time (15 November 2009) we have received:

- 6 requests from countries/territories
- representing 3 different languages

Following the IDN ccTLD Fast Track Final Implementation Plan, no additional details will be reported by ICANN – that is, until requests has been successfully processed.

That said, we will be providing additional stats (as the above) updates in regular time intervals.

No countries or territories has reported problems using the system, at this time.

All details for participants and access to the system is available directly from http://www.icann.org or directly at: http://icann.org/en/topics/idn/fast-track/

Inquiries for the system are to be submitted to idncctldrequest@icann.org

A quick note to participants:

When uploading supporting material, please note that each file must be limited to 10MB. If you have larger files, please indicate that in the text box provided, and send the files to idncctldrequest@icann.org We will try to find a better solution to this soon.

We are very much looking forward to receiving additional requests and processing everything, to make IDN ccTLDs a reality for Internet users around the world!

Sections are:

• JPA/Affirmation
• Applicant Guidebook/new gTLDs
• Fast Track/IDNs
• Public comment periods
• Seoul meeting
• And the remainder

JPA/Affirmation
Last Wednesday, 30 September 2009, the Joint Project Agreement with the US government ended and in its place a new Affirmation of Commitments was signed.

This is obviously of enormous significance to ICANN, so it currently sits front and center on the ICANN front page. We have an announcement, the Affirmation itself, a video of CEO Rod Beckstrom explaining its significance, and reaction from the community. The Affirmation has been signed but obviously there is much that the community now needs to discuss, and that conversation will start in Seoul.

Applicant Guidebook / new gTLDs
The third version of the Applicant Guidebook was released today. It’s all out for public comment, as we have done twice before. We are gradually moving forward with the overarching issues and, again, Seoul will be place to have more discussions.

It is worth pointing out that today, Monday 5 October, is the document deadline for Seoul (15 working days before the start of the meeting), which is why so much stuff has appeared in the past few days. The idea is that everyone will now have plenty of time to read the documents and so be in a position to talk about their contents at Seoul.

The full rundown of documents can be found at http://www.icann.org/en/topics/new-gtlds/comments-3-en.htm, including red-lined versions so you can see what has changed.

Fast Track
This is the process for introducing internationalized domain names (IDNs) into the root – but only those that related to territories i.e. ccTLDs. The Fast Track final implementation plan was published last week for public comment, and the plan is to have the Board authorize it at the Seoul meeting (end of this month).

So, this is the last chance to have a look and have your say before it actually happens. You can find all the information you should need for that process at http://www.icann.org/en/announcements/announcement-2-30sep09-en.htm.

Public comment periods
As usual in the build-up to a meeting, we have a raft of public comment periods. Ignoring the ones for the Applicant Guidebook and Fast Track, both of which are mentioned above, we have also opened comment periods on:

• A root-scaling study by TNO
• The use of proxy services for domain registration i.e. people paying to ensure their personal details do not appear publicly as the owner of a particular domain name
• Board review final report i.e. the changes to be made to the Board itself as part of the ongoing independent review process
• SSAC review report – same as Board report above but not as far along in the process
• NomCom review report – same as SSAC above

Seoul meeting
Why we have this glut of material is, of course, the upcoming Seoul meeting at the end of October.

With respect to the meeting itself, there are several other pieces of information:

• The agenda is live - check it out to see what is going on, when and who will be speaking
• If you can’t attend, you can ask questions in the public forum online
• If you haven’t see it yet, the meeting has its own website at http://sel.icann.org

And the remainder
And there’s still more:

• Nairobi fellowship applications
• A new process for registry security requests
• A bulk transfer advisory

Hopefully that helps breaks down the work into manageable chunks. If you still have queries, please add them as a comment below.

A number of people testified, including my colleague Doug Brent, but it is the testimony of Steve DelBianco I found particularly intriguing. His testimony revolved around the notion the country-code top-level domains are “controlled by governments”, and future IDN fast track ccTLD allocations will be “reserved only for governments”.

I think many in the ccTLD community will be puzzled by these repeated assertions in his testimony.

Let’s set the stage a little. Country-code top-level domains have existed since the mid-1980s — they are the domains that currently end with two-letter extensions like .FI for Finland, and .DE for Germany. Each country has one available for their use, taken from the ISO 3166-1 standard, but at present they are all written in the letters used for English, known as Latin characters. One of ICANN’s key current initiatives is to work on allowing country-codes to be deployed in different scripts, such as those used for Chinese, Russian and Arabic languages. It is not terribly convenient for those who type in these languages to have to switch their computer to using Latin characters just to put the two-letter endings on their domains, and this will address that.

Recognising that coming up with a complete solution for these internationalised country codes will take some time, the community is working on a “fast track” programme which allows countries that have a demonstrated immediate need to get early access to using these domains. Applications will need to show that the strings they would like to use (like .рф, .日本国 or .ελ) are not contentious, in addition to meeting all the existing eligibility criteria we use for assigning the Latin-based country codes.

So what are the criteria we use today?

The criteria we use in large part revolve around the consensus of “local Internet community” — a sometimes nebulous concept, to be sure, but in essence recognising it is the Internet community as a whole in the country that should decide how their domain is run, not just the Government.

IANA Staff wrote in 1994 that we assign country code top-level domains to trustees that “carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job”, and have a “duty to serve the community”. “Significantly interested parties in the domain should agree that the designated manager is the appropriate party.”

With respect to national governments, in 1997 we noted that “an additional factor has become very important since [1994]: the desires of the government of the country.  The IANA takes the desires of the government of the country very seriously, and will take them as a major consideration in any transition discussion.” Subsequent to that, the ICANN Governmental Advisory Committee has also made statements regarding this principle.

Clearly national governments have an important role in country-code top-level domains, but that does not translate to controlling them. It is the local Internet community that we look to to provide guidance on how their domains should be run. We expect governments are an important actor in the local Internet community, and that they are involved in the discussion and decision making. But there is a key difference between that, and them exclusively controlling the domain, or having them reserved for the government’s use. If the top-level domain for a particular country is assigned to its government to operate directly, it is because the local Internet community consensus there has decided that is what is appropriate, versus some other alternative.

A basic description of the evaluation criteria we use are provided in the public summary delegation reports we publish on the IANA website (see here for a recent example). ICANN staff have also been working in recent months on improving the public delegation documentation, in anticipation of the launch of the fast track programme. This documentation will better elaborate our existing processes. It is our hope that this will assist prospective applicants for these domains better understand the evaluation criteria when they submit their applications.

We know that Internet communities in a number of countries are already discussing how best to run a potential fast track internationalised domain, so that they can be ready to present their consensus should the programme be launched. Until then, all countries of the world have their two-letter ASCII code and ICANN continues to receive requests to maintain and transfer these domains in accordance with the community’s wishes.

Picturesque Bled - location for the ccTLD meeting

I’ve been around the domain name industry for a while and have attended a few ICANN meetings, but this was only my second regional ccTLD-focussed conference. I’ve also had some exposure to Eastern Europe but my exposure to Central Asia and the Caucasus is almost zero, limited to watching a picture of a plane following a red line across a map of the area on overnight flights between Australia and Europe.

I therefore wasn’t entirely sure what to expect, though my background research suggested that it was likely to be an interesting affair. The attendees list indicated a healthy turnout of ccTLD Managers, representing everyone from EU member states to Central Asian Republics. As my role at AusRegistry International is to build relationships with ccTLD managers around the world, this looked promising.

The conference itself was organised (very well, it should be said) by the Coordination Center for TLD RU (ccTLD.RU – Russia’s ccTLD manager), with local assistance from ARNES (the Slovenian ccTLD manager) and the Slovenian chapter of the Internet Society.

Each of the countries represented at the conference (with the exception of guest speakers, such as myself) share similar histories and so cultural perspectives and I was curious to see to what extent this, and Russia’s historically dominant position in the region, impacts on how ccTLD managers see their role in the Internet.

Many of the attendees spoke better Russian than English so a significant proportion of the conference was conducted in Russian. This was my first experience listening to a translation, which took a little getting used to, but the translator was really very good. Trying to watch a presentation in Cyrillic though was a reminder of just how spoilt I normally am as a native English speaker in today’s world, and of how critically important IDNs are to this (and other) regions.

It was fascinating to hear some very different perspectives than I’ve been used to in the past. As I come from an English-speaking country that is politically closely aligned with the United States and well represented within the ICANN community, it’s easy to forget that there are groups of people who are much less comfortable operating within the ICANN process, especially when it comes to the role the US government plays with respect to the agreements and contracts it has with ICANN.

A number of ICANN staff attended the meeting and did their best to allay some of the concerns expressed, particularly the idea that the US government has ‘a big red button’ that can be used to turn off the Internet at will. While this at first seemed ludicrous, even paranoid to me, it was a view earnestly held by a number of my colleagues and it was instructive to hear their views and arguments.

For example, some of the countries in this region do not send representatives to the GAC, because (as I understand it) they feel that this would be interpreted as recognition of the US government as the controlling body of the Internet. Others feel it is better to work from inside the tent, rather than outside – and there was also much encouragement to join and participate in the ccNSO. I hope I was also able to provide them with some of my, Australian, perspective.

This conference therefore plays an important regional role as an event that allows ccTLD managers (and others in the industry) to share their experiences and to support each other, without becoming entangled in the political issues that make ICANN a problematic space for some of them.

From a personal perspective, it was great to have the opportunity to meet with ccTLD managers from a range of countries, and to hear about the various challenges that they face in an increasingly competitive market and an increasingly challenging security environment.

I also enjoyed the chance, as part of the Marketing panel, to present some of the experiences that we have gained during our time as Registry Operator for the dot-au ccTLD and from our work with other ccTLDs, especially our clients in the Middle East.

I should also mention the local hosts’ hospitality: we were treated to two excellent dinners – the second one being a particularly special affair held in Bled Castle with spectacular views over the lake and the mountains beyond.

The only real complaint I have is in relation to the extremely flaky wireless internet connectivity in the conference hall. I have a suspicion though that this may have been a deliberate strategy on the part of the organisers to get people to actually listen to the presentations. A strategy to be considered for future ICANN meetings perhaps…

Jon Lawrence is Business Development Consultant at AusRegistry International

ICANN’s staff is currently producing implementation plans for both the IDN ccTLD Fast Track Process and the New gTLD Process. What guides that process for the topic of variants, is three things:

1. Following the direction of policy advice already provided
2. Taking broader community needs into consideration, and
3. Ensuring the continued stability of the DNS and the namespace in general

In the course of doing this for the issue of variant TLDs there were two different proposals.

1. Reserve desired variants & block all other variants; and
2. Delegate desired variants & block all other variants

Following public comment periods on both proposed implementation methods (none were agreeable across the community), it was decided during the Sydney meeting this June that ICANN staff would seek implementation assistance from the community. This is usually the case on policies that have technical implications and hence are difficult to implement.

As a result a small team has been asked to volunteer their time (you can read more about that team and another issue the team is looking at in the post Solving the remaining IDN issues).

Community discussion on this topic is very important as we strive to reach a conclusion that works for all involved. Variant TLD management is especially important to make the introduction of IDNs work well for the end-users. The IDN Tables that hold and define the character variants are the most important piece of the management of variants, as these tables are developed to reduce the potential for confusion to end users by the introduction of IDNs.

In the most recent paper [pdf] published on this topic, a variant is defined as follows:

“Variant characters are two or more characters that are similar in appearance and result in two domain names to be visually confusing.

As such the resulting “variant strings” that are obtained by replacing the original characters with the variant characters, are visually indistinctible and, if used for separate purposes, could create user confusion. In some cases this could result in visually similar strings having the same meaning.

As such, 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”. The IDN Tables that define variant characters are useful because they enable TLD registries to develop registration policies that will reduce the potential for confusion that could result from typographic similarities in domain names.

Recent discussions have suggested that the definition might be better if more technical stringent (for example by following the definition in the JET Guidelines: “One conceptual character can be identified with several different Code Points in character sets for computer use”) and then add various examples of variants, where some are confusingly similar visually and others are not.

The same paper proposed the following way of managing IDN TLD variants:

“ICANN understands the need expressed in the community for enabling allocation of variant strings, in particular for locations where some users will key in one string and other users will key in the variant string when accessing for example a website. ICANN urges the community to continue to discuss and develop a technical solution that will enable the allocation of variant strings in the root zone in a stable manner. Until then IDN ccTLD Fast Track requesters will need to select one string per script or language only or alternatively wait until a technical solution has been found.

“In order to reserve the possibility of allocating variant strings to the appropriate entities, ICANN will ensure that all variant strings are reserved or blocked for allocation for now. Blocked strings will be considered as “existing strings” when incoming requests are checked for conflicts with existing TLDs. Therefore, any later request for the same string will be denied.”

The reservation of desired variants was thought to be the safest way of securing adequate variant management until a solution has been found on how to manage them at the top level. The community response to the temporary solution was mixed. There is a concern in certain regions that a blocking of variants will disfranchise certain user communities. However, at the same time the response received stated that solving this problem should not in any way slow down the Fast Track introduction.

While we continue work on the subject with the industry experts, one thing seem to be clear: variant TLDs will be identified using of the IDN Tables that are required in either a Fast Track request or an IDN gTLD application.

This means that for the sake of the end-users, the usability of IDNs globally, and therefore the adoption of IDNs across applications on the Internet, we better get these tables right!

I have previously blogged about what could be the worst case scenario. We really want to avoid this. We are in the last step of making IDN TLDs a reality for users globally which will be an amazing step for all involved.

For example, current practice dictates that gTLDs contain at least three characters – two-character Latin TLDs are reserved for country-code top-level domains (ccTLDs). However, in certain languages (you probably can think of more than one) one or two characters commonly express a complete word – and they would not be confused with present-day ccTLDs.

Prohibiting the registration of names of less than three characters in certain languages may hobble IDN use in certain languages but it is difficult to fashion a uniform set of rules to govern a potential relaxation of this requirement that works universally.

ICANN’s approach to this issue is similar to its approach on many issues regarding implementation of the policy for the introduction of new gTLDs.

1. Get expert advice on the matter. The use of experts allows ICANN to obtain experience and skill economically outside its core competencies and develop material for public discussion in a timely manner.
2. Use that advice to formulate some sort of model.
3. Then conduct public discussion on the issue (the discussion is clarified by existence of a model).
4. Iterate the model and hold another round of public discussion.
5. Iterate the model, and so on.

This process has been used effectively thus far in the new gTLD implementation. ICANN has consulted with: technical, DNS, risk management and linguistic experts, dispute resolution providers, and others.

In this case of character limits and IDNs, ICANN is engaging a small team to evaluate this problem and provide expert advice from both sides of the problem: that IDNs must be effectively engender regional participation and that the rules must provide stability, i.e., that the domain name system (DNS) work in a way predictable to users.

Given the importance of the issue, we saw a large number of volunteers – all of them competent to take part – but from which only a few of which were chosen for the team so initial advice could be developed relatively quickly.

That not to say that those not in the team can’t participate effectively now and in the future. Right now, there are a number of comments on the issue but no jointly developed advice or model. The small working group is intended to move the discussion forward — but not conclude it. Rather, it will provide additional material for all those who are interested in ensuing discussion in ICANN meetings and public comment fora.

Again, that process for reaching implementation: identify issues, get expert advice, create a model for public discussion, discuss, iterate the model, and so on.

The idea is that the experts crystalise the discussion in a timely way and therefore encourage meaningful participation.

We are at step number two of this process that will include all interested parties. The process for developing a preliminary set of assumption will be publicly reported so the ensuing public discussion can be informed and timely.

Everyone at ICANN appreciates the comments made on this particular issue and other IDN issues – all going toward an effective way to increase effective regional participation in the Internet.

One of the more interesting insights involved looking at network diversity. We want top-level domains to keep functioning no matter what is happening — any conceivable disaster shouldn’t knock a top-level domain off-line. One thing we ask is that top-level domains’ name servers be hosted in at least two distinct networks, so it is guarded against a failure (be it a technical failure, or some other business failure event).

Here is a map of all the country-code top-level domains, and one possibly measure of diversity — the number of “autonomous systems” their name servers are hosted in. Countries marked red are reliant on a single network, and if that network failed it could be disastrous for its users without alternatives. Those orange through green have increasing amounts of diversity in the networks that host their name servers:

If we take a minimum of two networks as our baseline requirement, we can look at how TLDs have met this criteria over a period of time — say the last five years:

The blue line shows IPv4 connectivity and it is pretty good, and rather consistent. But if we judge IPv6 connectivity against the same diversity requirement, shown as the green line, not even 50% of ccTLDs have this level of diversity. If we look at TLDs with any IPv6 it is a little better, but there is still about a third of all ccTLDs with no IPv6 connectivity at all!

The good news is the IPv6 trend lines are heading in the right direction, with the growth of IPv6 deployment even accelerating a little recently. Lets hope this continues so that these critical resources are stable not just for existing Internet users, but for future Internet users as well.

Here is the current answer to all of those questions.

Restrooms are just past the elevators on levels 2 and 4.

As these events occur, ICANN invariably receives requests to recognise new sovereign entities. In some cases we see very inaccurate press reports by “experts” on how country codes will be assigned. Thankfully, we have a very clear process for this that it is worth repeating.

I said in a blog post a couple of years ago the following:

Another thing ICANN is not involved in is deciding the actual codes, or what constitutes a country eligible for a code. Valid country codes are defined by the ISO 3166-1 standard, which is used internationally not just for domain names — but for physical mail routing, currency codes, and more. The ISO 3166 Maintenance Agency is responsible for keeping the list of codes up to date, taking advice from the United Nations Statistics Office on what constitutes a country eligible for a country code.

By ensuring ICANN is not tasked with deciding what country codes are valid, ICANN can focus its coordination role by ensuring the country-code domains in the DNS root zone match those allowed by the ISO standard. When new countries are formed, new ISO codes are created, and ultimately they can be added as new country code domains. Similarly, countries disappear, their codes are revoked, and they are retired from the DNS root zone.

It is as true today as it was when this policy was introduced in the mid-1980s. We have a more formal description up online, but fundamentally recognition of a new entity that might be granted a country code originates with recognition by the United Nations. Once that occurs, it will kick off a chain of events that will see a new two letter code added to the ISO 3166-1 standard. Once it is in that standard, IANA will accept applications from suitably qualified candidates to operate the country code domain (see our delegation process described here).

This is what happened most recently in the case of Montenegro. In June 2006 it declared independence, was recognised by the United Nations, and added to the ISO 3166-1 standard in September 2006. Some time after this, the Government of Montenegro approached ICANN for delegation, and once the formal process was concluded, .ME was added to the DNS root zone in September 2007.

As at this time, Abkhazia, Kosovo, Transnistria, Somaliland, South Ossetia and others are not in the ISO 3166-1 standard, so ICANN is not in a position to grant any corresponding country-code domain for them. By strictly adhering to the ISO 3166-1 standard, we ensure that ICANN remains neutral by relying upon a widely recognised and impartial international standard.