These regional meetings are a chance for ICANN staff and representatives from gTLD registries and ICANN-accredited registrars to meet informally to discuss topics important to our industry and business relationships. They happen regularly in different locations (regions) around the world. Previous meetings, for example, took place in Shanghai, Prague, New Orleans, and Rome.

Although the meeting is tailored to regional ICANN-accredited registrars and gTLD registries, other registrars and registries located around the globe that may have a regional or business interest also attend.

At this regional meeting staff is planning to introduce a new feature dedicated to newcomers to the ICANN process on the morning of the first day.

The agenda is not final yet, however some of the anticipated agenda items are:

• Registrar/Registry Onboarding with new gTLDs
• RAA Amendments
• Developments in Contractual Compliance
• Policy updates
• ICANN restructuring update
• Internet Security Developments

The joint registrar and registry regional meeting model was introduced in 2006 as an educational opportunity for ICANN and its contracted parties to share information about registry and registrar operations within the domain name industry. The model has evolved over time based on feedback received and changes in the domain registration environment. The meetings largely focused on the policies and procedures registration service providers are obligated to implement and enforce as a result of either their contract with ICANN or with one another.

These regional meetings are distinguished from the regular international ICANN meetings in that they are not structured, for example, to influence policy development. If you are interested in the policy development and a broader interaction with ICANN stakeholders, please join the upcoming ICANN Meetings in person or through remote participation. The next international ICANN Meeting is scheduled for Beijing in April 2013.

All presentation materials will be published on the ICANN website after the meeting.

The space to attend this meeting is limited and interested registrars and registries are asked to pre-register. Other parties who may be interested in becoming an ICANN-accredited registrar or gTLD registry and wish to attend as observers should contact regionalevents@icann.org for further details.

We look forward to seeing you in Amsterdam!

ICANN is actively taking part in conferences and events, with a focus on applications and usability of new technology on the Internet. This is to spread information about IDNs and how they work in order to obtain a more streamlined user experience across applications.

We will continue to make more information, such as the examples below, available for users and everyone interested in IDNs. We very much appreciate any feedback you might have, pointers to what type of information you think might be lacking, and suggestions for online forums, seminars, or other type of events where information about IDNs would be good to include.

This first post is focused on how IDNs work and where registrations can be made.

What are IDNs?

The acronym “IDNs” stand for Internationalized Domain Names. IDNs are domain names that include characters used in the local representation of languages that contain one or more characters other than the twenty-six letters of the basic Latin alphabet “a,b,…z”, “0,1,…9” or “-“. An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese.

Example: ñandú.cl

Since the Domain Name System is not capable of communicating with these characters, a system is made so that the domain name stored is actually:

xn--and-6ma2c.cl

This “xn--and-6ma2c.cl” is referred to as the A-label for the IDN and does not make a lot of sense for users and was never intended for users to see – however, in some instances you will see this – see below for more explanations and examples.

Why are IDNs introduced?

Historically domain names could only consist of characters from “a,b,c…,z”; “0,1,2,…,9” and “-“.

The geographic expansion of the Internet and the corresponding increase of use by various linguistic groups or communities resulted in the need for domain names also to consist of characters from all scripts used in the world today. Content written in various languages has been around for a long time.

The fact is that for example websites where the content is all in Hindi should also have a web-address in Hindi. Web content in various languages has been around for a long time. The matching addresses are now here.

IDNs are about your choice

Let’s be clear: IDNs will provide opportunities for more people to have easier access to the Internet. Some people are concerned about IDNs dividing the Internet because they are not able to read or type some of these languages.

But it’s all about user choice. The choice of effectively being able to select which script or language a domain name should be based on. In this way you can brand yourself better and in that way target the market you want more effectively. Printed material can have web references in the same script as the material is written in. And keep in mind that a website can for example have more than one address….which now can be a choice between different scripts and languages.

Another aspect of this that is important to realize it that by introducing IDNs in the Internet/single root today means that we hopefully have avoided a fragmentation with various “internets” based on different scripts. That would be a situation where communication between these “internets” would be difficult if not impossible. Introducing IDNs in the Internet today effectively ensures the global interoperability of the Internet.

How can I make registrations of IDNs?

ICANN is not in the business of offering the domain names registrations. The registrations can be made through registrars or their resellers, and for some ccTLDs directly via the TLD registry manager. As such, for information about how to register domain names in the new IDN ccTLDs should be sough via the IDN ccTLD managers.

All current TLD managers and operators are listed at http://www.iana.org/domains/root/db/

This will be updated shortly to include the three IDN ccTLDs that were made available yesterday http://icann.org/en/announcements/announcement-05may10-en.htm

Until then you can find the main points of contacts at: http://icann.org/en/topics/idn/fast-track/string-evaluation-completion-en.htm

IDN registrations under some of the existing (ASCII) TLDs (e.g. .com, .org, .gr, .cn, etc) have been available since as early as 2001. The registry managers or your preferred choice of domain name registrar or reseller will be able to assist you with more information about these IDN registrations under existing ASCII TLDs. Domain names under the gTLDs (generic top-level domains such as .com) can be registered through ICANN accredited registrars or their resellers. A list of all ICANN accredited registrars is available here: http://www.icann.org/en/registrars/accredited-list.html

Note that some IDN ccTLD managers have decided to take pre-registrations before their requests for IDN ccTLDs have been completed. ICANN is not endorsing this as it is not possible to guarantee a certain TLD for availability until it has passed through all steps in the processes successfully.

How do IDNs work?

IDNs have been around for years at the second level (the “icann” portion in the address http://www.icann.org ) and as a result, browsers and other application software started updating their systems years ago. Today the newest versions of all major browsers can handle IDNs. They have implemented IDNs slightly differently, which will give slightly different user experience, but those that are IDN capable will get you to the right and same site. So what’s the difference?

Well due to the different ways that IDNs are implemented, different options are made available by the different browsers. Some examples as follows:

In all of these examples, you will get to the actual site. What does not always display as entered is the address in the address-bar. The examples explain how users can overcome this fact.

Internet Explorer:

The screenshots below is from IE v8 accessing: http://παράδειγμα.δοκιμή (this is the Greek version of the ICANN wiki and the address means “example.test” in English).

You will note two things:
1) The address in the address bar is displayed as:

http://xn--hxajbheg2az3al.xn--jxalpdlp/%CE%91%CF%81%CF%87%CE%B9%CE%BA%CE…

2) There is a small pop-up stating that the address cannot be displayed with your current language settings.

If you click on the pop-up and select the change language settings you will get the following options, where you can add languages to your settings:

Adding, in this example, Greek to your language settings will effectively display the address as in the following screenshot, where the address is displayed in Greek:

It is noticeable that the path in the web address contains “%CE%91%CF%81%CF%87…”. The path should effectively also be internationalized.

Mozilla Firefox

The screenshot below is from Firefox v 3.5.5 accessing: http://उदाहरण.परीक्षा (this is the Hindi version of the ICANN wiki and the address means “example.test” in English).

It is noticed that the address (and the path) in the address-bar is displayed correctly in the Devanagari script: http://उदाहरण.परीक्षा/मुख्य_पृष्ठ

The implementation of IDNs in Firefox is based on a white-list of those TLDs/extensions that Firefox considers ‘safe’. All the “.test” TLDs has been added to this white-list. If you are accessing a site and the address is displayed in the http://xn--p1b6ci4b4b3a.xn--11b5bs3a9aj6g format then this is because that particular TLD or extension is not in the Firefox white-list.

If you trust these addresses and wish them to display in the address-bar as the local characters then you can make changes to the white list manually. A detailed explanation on how to do this is available here: http://idn.icann.org/Firefox_Information

The screenshot below gives you an indication of what to look for, but please be careful when making changes so that you do not damage the functionality of the browser.

Opera Browser

The screenshots below is from Opera 10.53 accessing: http://בײַשפּיל.טעסט (this is the Yiddish version of the ICANN wiki and the address means “example.test” in English).

The Opera browser supports the “example.test” names either directly, or after updating as described in a separate article on the Opera Browser: http://idn.icann.org/Opera_Information

As is noticed in the above, the address in the Hebrew script displayed as http://xn--fdbk5d8ap9b8a8d.xn--deba0ad/הויפּט_זײַט – in order have it displayed as: http://בײַשפּיל.טעסט updates need to be made.

Another example where Opera is supporting the IDNs directly is displayed below, which is the Chinese version of “example.test” – i.e. http://例子.测试/首页

Are you using a different browser than those examples provided here?

Please try things out either live under any of the IDNs that are available, or in the IDN wiki at http://idn.icann.org and let us know how this works for you. The IDN wiki also contains a lot of additional information related to fonts etc. Please feel free to add and share your IDN expertise and experiences on the wiki.

The next IDN topic blog post will be on IDN & Security. Meanwhile, please make sure to let us know any topics you would like to see covered.

Internationalization of the internet means that the internet is equally accessible from all languages and scripts

More information about IDNs can be found at: http://www.icann.org/en/topics/idn/

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

All of us involved with producing the podcast are grateful for that robust welcome (which, candidly, exceeds our expectations). We will keep working hard to make the show worth your time.

Here on this blog (and elsewhere) one of the first requests we heard was that we should transcribe the episodes. Lots of people like the idea of an ICANN resource that provides basic orientation, but not all of them find it convenient to listen rather than read.

We’ve heard your request, and are scrambling to comply. The April episode that just got posted has the transcript right next to it. Transcripts for the older episodes are on the way and will go up as they’re available, with all of them up by next week. From now on, our target will be to have the transcript accompany each monthly episode as it’s posted.

The new April episode features Margie Milam, Senior Policy Counselor. It turns out that a seemingly vanilla term like “consensus policy” has a technical meaning in ICANN, packed with connotations. Margie explains what consensus policy means, and along the way clarifies the difference between a registrar and a registry. If you’re reading this, you probably know all of this stuff — but the podcast or the transcript might turn on the lights for a new volunteer in your constituency or committee or At-Large Structure. Consider sending ‘em the link, which is http://icann.org/en/learning/podcasts.htm. (And if you want to listen in, we won’t tell anybody.)

What else can we do to make the show more useful to you? Are we covering the topics you want to hear about? Let us know by sending an email to start@icann.org.

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!

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.

Not having been to an ICANN event, I didn’t know what to expect from the “Regional Gathering of ICANN-Accredited Registrars and gTLD Registries” when it came to Toronto last week. A check of the agenda had me wondering if some of the material would be over my head. The subject matter included security, compliance, data escrow and the Registrar Accreditation Agreement among other things. As I said, I try to stay up on what’s happening with ICANN, so at least I was familiar with most of topics being discussed.

The first session I attended was probably not the best introduction to the inner workings of ICANN. I had heard that there was a tendency to use acronyms to excess, so I came armed with a BlackBerry and the link to the ICANN website glossary. Despite my efforts, I still found myself leaning over on a number of occasions to ask my more experienced neighbours what the ALAC was and why the New gTLD AG3 was all about.

Once I got past the acronyms and got some background on some of the issues, I began to see in the room a group of people, each representing different interests, struggling to come to a consensus on how best to proceed. There was most definitely differing viewpoints presented, and a clear belief of being right about the best way to proceed. However, there was also a clear passion shared around the room (and around the world via phone) for ensuring that the eventual solution, or direction taken was the best for the Internet community as a whole.

Outside of the discussions around issues like the new Registrar Accreditation Agreement and the New gTLD Program which get a lot of press around the Internet industry, the gathering provided a good introduction to the work of some other areas of ICANN.

A presentation by Yurie Ito, Director, Global Security Programs for ICANN provided an excellent introduction to the kinds of challenges that the industry faces in terms of criminal activity and other abuse on the Internet. Presentations from representatives from .MOBI and .ASIA were valuable in understanding how different registries are working to market their domain extensions to the public.

The discussions about how the de-accreditation process was and wasn’t working revealed some of the differing challenges faced by ICANN, registries and registrars when a de-accreditation was undertaken. While the process is clearly not yet perfect, it was also clear that each of the stakeholders was committed to doing right by the registrants and was willing to give and take to ensure the best possible outcome was achieved.

That said, what I found most valuable was simply being a part of it. Lunch meant a chance to meet and converse with counterparts at other registrars, partners at registries, and even some long-time customers of Tucows. The evening activities, including a fantastic night at the baseball game (thanks to Afilias) allowed everyone to unwind and walk away from the issues that have the potential to overwhelm and burn out those who are front and center in the process.

Adam Eisner mentioned to me after day one that the most rewarding part of being involved in ICANN was that you were a part of the process that leads to changes that have a real impact on the Internet and how it works. It was a chance to be one of the people making it better.

The perception some have, and I confess that included myself, is that ICANN is a mess of bureaucracy and that nothing ever gets done. Sure, ICANN can be a frustrating experience at times – that was made clear in some of the discussions that took place. But I think that those involved have an unequivocal understanding of the task they have taken on and the challenge it represents.

There is little room for error when you start changing the very structure of the Internet. Second chances are hard to come by with a global network of such immense value to society. What’s amazing to me is that those involved are willing to work to make it better as opposed to being frozen in the fear of messing it all up.

The net result of attending the gathering is both a fuller understanding of just what is involved in nurturing and stewarding of this amazing thing called the Internet. I’ll definitely pay more attention to what’s happening, both through the remote access that ICANN provides and hopefully also in person in the future.

The Conflicker/Downadup worm infects computers running Windows operating systems variants. The infected computers can be remotely controlled (i.e. forming a botnet) and the infection propagates through a number of different routes. The worm has been estimated as infecting as many as 10 million hosts and data from the security community indicates the number is at least 1.5 million. One mechanism the worm’s code uses to enable control is to download commands by accessing specific date-based domain names.

In mid-January, security community researchers began to understand which future domain names that the botnet would seek to utilize. These researchers sought cooperation from these registries to protect the names that would potentially be utilized. ICANN has worked with the registries, the security researcher community and Microsoft to share information, discuss specific mitigation steps and reach out globally across all involved parties to block the spread of the worm and formation of a massive botnet. This type of collaborative response is a model for dealing with distributed, evolving threats to the Internet’s security and resiliency.

We believe that malicious code using the DNS to enable propagation of worms and establishment of large botnets is likely to continue, even increase, in the short term. We are continuing our collaboration in response to the Conflicker/Downadup worm/botnet. DNS registries, the security community, and ICANN staff have agreed to initiate a working group to establish how ICANN can enable timely and effective responses to such worm/botnet situations that involve abuse of the DNS and threaten Internet security and resiliency.

Greg Rattray

ICANN Chief Internet Security Advisor

What was it?

ICANN’s 33nd international public meeting was the third held this year to conduct policy development and outreach. It was hosted by ICANN (the Internet Corporation for Assigned Names and Numbers) and the Government of Egypt.

The meeting was opened by Dr. Tarek Mohamed Kamel, Egypt’s Minister of Communications and Information Technology. There were 1,702 attendees from 144 different countries. The participants engaged in a wide range of discussions about the Internet’s domain name system and related issues.

Further information about the meeting, including presentations and transcripts, is available at http://cai.icann.org/. A number of videos summarizing the key parts of the meeting can be found at: http://cai.icann.org/en/video.

ICANN’s next international public meeting will take place in Mexico City, Mexico, beginning on 1st March, 2009.

What happened and what are the next steps?

Many meetings, workshops, public forums and informal discussions were held over eight days by the different stakeholders of the ICANN model:

• Business interests
• Civil society
• Governments and government agencies
• Internet service providers
• Registrants
• Registrars
• Registries
• The technical community

• New gTLDs
• IDNs and IDN Fast Track
• Improving Institutional Confidence
• Independent Reviews
• DNSSEC and Security
• Business Access Agenda
• Special guests: Dr Hamadoun Touré and Meredith Atwell Baker
• Other matters

A draft Applicant Guidebook was released a week before the meeting for those wishing to apply for a new generic top-level domain. A number of meetings and workshops were dedicated to explaining the guidebook and receiving input and feedback from the community on its contents.

The first were two introductory sessions on the Sunday before the meeting’s official opening, held in English and Arabic. That was followed by a dedicated hour-and-forty-five minute workshop in the main room on the opening day, Monday (http://cai.icann.org/en/video#tue). Further discussion on the subject took place at a joint session of the chairs of the Supporting Organizations and Advisory Committees in the afternoon.

Discussion and updates were then presented to different parts of the community, including the GNSO and its constituencies, ccNSO and GAC over the course of the following two days. A community-led discussion on “Additional Solutions for a Successful gTLD Launch” took place on the Wednesday afternoon.

Much of the two-part public forum on Thursday was taken up with comments and questions on the guidebook specifically and the new gTLD process generally, and an update on the process was given to the Board during its public meeting on Friday morning. Transcripts from most of these sessions are available on the Cairo meeting site (http://cai.icann.org/en/transcripts).

More information is available on ICANN’s new gTLDs page (http://www.icann.org/en/topics/new-gtld-program.htm), including the draft Applicant Guidebook and accompanying explanatory memoranda, as well as an FAQ, and additional resources.

The new gTLD update provided to the Board can be found at: http://cai.icann.org/files/meetings/cairo2008/new-gtlds-06nov08.pdf

Next steps:

The draft Guidebook will be published in five additional languages. A public comment period on the guidebook will run until 8 December (http://www.icann.org/en/topics/new‐gtld‐comments‐
en.htm), after which public comment will be analysed and used to revise the implementation model.

In 2009, ICANN will procure evaluation services for certain aspects of the process, embark on a global communications plan to make as many people as possible aware of the new process and then launch the introduction of new gTLDs.

More information:

See the new gTLD webpage at http://www.icann.org/en/topics/new-gtld-program.htm
An overview video of the Monday session can be found online at http://cai.icann.org/en/video#tue

Just prior to the meeting, the draft implementation plan for the IDN Fast Track was published. The Fast Track would allow a limited number of IDN ccTLDs to be introduced before the formal policy development process is finalized (IDN ccTLDs are country code, as opposed to generic, internationalized domain names at the top level of the Internet).

Public comments on the draft document are being received until 8 December (see http://www.icann.org/en/public-comment/public-comment-200812.html#plan-idn-cctlds).

In Cairo, the Fast Track document was the focus of much of the discussion related to IDNs. The issue of internationalized domain names that may be applied for through the new gTLD process (as opposed to the Fast Track or the subsequent ccTLD policy development process) was also a main topic of conversation. There was also some discussion about the timing and possible overlap of the two different tracks for IDN top-level domain applications.

There were also two introductory sessions (one in English and one in Arabic) on the subject of IDNs.

The Fast Track and the introduction of IDNs was also discussed in two joint sessions of the chairs of the Supporting Organizations and Advisory Committees on Monday afternoon and Thursday morning. Updates on both, as well as progress being made by the IETF on the IDNA protocol revision (an important step for the process) were provided to ICANN’s different bodies and constituencies over the course of the week.

An update on the process was provided to the ICANN Board at its public meeting on the Friday, complete with some discussion of the issues surrounding IDN implementation issues necessary for the Fast Track process to be implemented. Transcripts from most of these sessions are available on the Cairo meeting site (http://cai.icann.org/en/transcripts). See also: http://cai.icann.org/files/meetings/cairo2008/idn-pf-cairo-06nov08_0.pdf

A meeting of interested parties on the introduction of Arabic script at the top level of the Internet took place on the Saturday after the meeting.

Next steps:

The draft implementation plan for the Fast Track process is out for public comment until 8 December, when it will be evaluated with respect to the comments. At the same time, an IETF working group is finalizing an IDN protocol that ICANN hopes to see completed before the introduction of IDN top-level domains.

Outstanding issues remain including: the relationship between an IDN ccTLD operator and ICANN, both in the type of agreement or framework entered into and the provision of funds; the issue of contention between existing top-level domains and ones applied for through the new gTLD process; and a few technical requirements. Some of these issues will be addressed or resolved at the next ICANN meeting in Mexico in March 2009.

Staff will provide an updated version of the draft Fast Track implementation plan prior to the Mexico meeting, with a specific focus on these issues:

More information:
IDN index page: http://www.icann.org/en/topics/idn/
The Fast Track draft implementation plan: http://www.icann.org/en/topics/idn/fast-track/idn-cctld-implementation-plan-23oct08-en.pdf
An overview video of IDNs and new gTLDs can found online at: http://cai.icann.org/en/video#mon

The IIC consultation was formally launched at ICANN’s Paris meeting in June and has since been the subject of two public comment periods and a global outreach campaign. In Cairo, the meeting was used to give the community an update on the process and also to gather more feedback on the issues it has raised.

The IIC consultation is based on successive drafts of a set of three documents – an Improving Institutional Confidence in ICANN document; a Transition Action Plan; and a Frequently Asked Questions document. These documents have been updated to reflect community input from a special session in Paris,, the two public comment periods and a series of five public meetings in Montevideo, Christchurch, Geneva, Washington DC and Dakar between August and October 2008.

A special joint session of the chairs of the different Supporting Organizations and Advisory Committees considered the IIC documents on Monday afternoon. A session dedicated to the consultation was also held on Thursday afternoon. Transcripts from these sessions are available on the Cairo meeting site (http://cai.icann.org/en/transcripts). The consultation was also one of the main topics discussed by the Governmental Advisory Committee (GAC) over the course of the week.

The consultation’s aim is for the community to discuss possible changes to ICANN in the lead-up to the completion of the JPA in September 2009. This work has been led by the President’s Advisory Committee (PSC) whose role is to provide advice to the Board.

Next Steps:

Work will soon begin on an implementation plan with details about the issues identified by the community as needing attention. That plan will be published in early 2009 in time for review prior to the next ICANN meeting in Mexico City in March.

In the meantime, two further outreach meetings, at Afrinic in Mauritius later this month (November 2008) and at the Internet Governance Forum (IGF) in Hyderabad, India in December will take place to build more awareness and gather feedback.

More information:

Full information about the documents, the public comment periods, the regional meetings and the consultation itself can be found on dedicated IIC webpages in ten languages at: http://www.icann.org/en/jpa/iic/
The update on the process, as given at the special IIC session on Thursday can be found online at: http://cai.icann.org/files/meetings/cairo2008/iic-workshop-06nov08.pdf

The independent review process requires each of ICANN’s Supporting Organizations and Advisory Committees to undergo review every few years to make sure that the organization as a whole continues to serves the needs of the global Internet community.

There are several independent reviews currently underway or soon to be launched. The Board of Directors is also undergoing an independent review. The Cairo meeting saw a number of updates and workshops on the current reviews, and an update on the various reviews was also provided to the Board at its public meeting on Friday. A new staff member dedicated to overseeing the reviews process was also publicly introduced.

GNSO
The review effort to improve the structure, operations, communications and outreach of the GNSO has now moved into the implementation stage, but there are two outstanding issues still being considered by the ICANN Board: how the GNSO Council elects members of the Board; and the role of individual users within the GNSO.

Staff is actively soliciting input on the first issue, and the second has been put out to public comment until 28 November (see http://www.icann.org/en/public-comment/public-comment-200811.html#gnso-users).
In the meantime, charters and work plans are being developed for steering committees and operations work teams to enable the GNSO to move into its new two-house structure by June 2009, and to develop implementation proposals for a new policy development process as well as a new working group methodology for addressing policy issues.

Nominating Committee
Currently in “improvement stage”. The Board Governance Committee (BGC) is reviewing a report from a special BGC working group formed to review the independent report produced earlier in the year.

ALAC
Following discussion of the independent reviewer’s report at the Paris meeting in July, a working group on the ALAC review has produced a mid-point report on its findings so far and held several sessions in Cairo seeking input from the community. A final report is expected for the Mexico City meeting in March 2009.

Board of Directors
The independent reviewer’s report was published at the Cairo meeting and a special session held on the Monday evening. A special working group will seek input from the community and produce an initial report for the Mexico City meeting.

RSSAC
The independent reviewers started gathering information at a special session on the Wednesday morning. A draft report is expected for the Mexico City meeting in March 2009.

SSAC
The independent reviewers started gathering information at a special session on the Wednesday morning. A draft report is expected for the Mexico City meeting in March 2009.

Others
The ccNSO and ASO reviews are in their preparatory stages, with the terms of reference for the ccNSO to be published for public comment before the end of the year, and the terms of reference for the ASO expected in early 2009.

Next Steps:
The progress of each review can be followed online, with further details on each given in the staff update provided to the Board on Friday.

More information:
The independent reviews webpage can be found at: http://www.icann.org/en/reviews/
The presentation provided to the Board can be found online at: https://cai.icann.org/files/meetings/cairo2008/organizational-reviews-06nov08.pdf
Transcripts from most of these sessions are available on the Cairo meeting site at http://cai.icann.org/en/transcripts.

Following the issue of an exploit in the domain name system discovered by security researcher Dan Kaminsky, a number of security briefings on this issue and other related issues were given to ICANN’s various supporting organizations and advisory committees.

In particular, the DNSSEC protocol – long promoted by ICANN’s Security and Stability Advisory Committee (SSAC) – was explained and its use in closing down the Kaminsky hole outlined, alongside other short-term measures.

A special workshop on DNSSEC was held on the Wednesday, and an open meeting of the SSAC on Monday also covered the issue.

The SSAC meeting was also used for an experiment in improving remote participation. Through Adobe’s Connect software, participants were able to see and hear the meeting in progress (as well as view the live scribe feed), see the presentation slides as the presenters went through them, and ask questions in a dedicated chatroom.

More information:
DNSSEC Workshop full details and presentations: http://cai.icann.org/en/5nov08/dnssec-workshop

For the second time, a specific agenda and series of targeted meetings and discussions were held for business leaders in an effort to engage business more effectively within ICANN’s processes.

The agenda included briefings on the most significant topics facing ICANN at the moment, including new gTLDs and IDNs, and a meeting with board directors, including the Chair.

Two special guests visited the Cairo meeting on the Thursday.

Dr. Hamadoun Touré is Secretary-General of the International Telecommunication Union (ITU), and Meredith Atwell Baker is Acting Assistant Secretary for Communications and Information at the US Department of Commerce and responsible for the relationship ICANN shares with the US government.

Both gave speeches and Dr. Touré answered questions from the audience. Dr Touré stressed the importance of collaboration between the ITU and ICANN and Acting Assistant Secretary Attwell Baker acknowledged ICANN’s institutional progress in the 10 years since its creation and stressed that proactive contribution from the community is vital to the organization as the Internet continues to evolve.

Both Touré and Atwell Baker then held a number of separate sessions with various members of the ICANN community.

More information:
Transcripts of both speeches can be found online at:
https://cai.icann.org/files/meetings/cairo2008/toure-speech-06nov08.txt and https://cai.icann.org/files/meetings/cairo2008/baker-speech-06nov08.txt respectively.

• ICANN signed an Exchange of Letters with the managers of .eg, Egypt’s country-code top-level domain (see a video of the occasion at http://cai.icann.org/en/video#sun.
• The .mobi and .coop registries were authorized to make single-letter domains available e.g. www.c.mobi.
• A new working group will study and review the issues related to the definition of the ICANN Geographic Regions, and submit proposals for community and Board consideration. The Board asked all interested Supporting Organizations and Advisory Committees to nominate two individuals to serve on the working group.
• Sydney was chosen as the location for the June 2009 meeting and the Board asked Staff to review the possibility of Seoul as the host for the October 2009 meeting, with the European meeting deferred until a later date.
• Since it was ICANN’s annual meeting, the Board was reformed with new members Katim Touray (NomCom appointee), Thomas Roessler (TLG liaison) and Ram Mohan (SSAC liaison). Previous SSAC chair Steve Crocker became a voting member of the Board following his selection by the Nominating Committee.
• Peter Dengate Thrush was re-elected as chairman; Roberto Gaetano was re-elected as vice-chairman.

A PDF version of this document is available at: http://www.icann.org/en/participate/cairo-public-forum-response.pdf

Note from the Chairman:

One of the most significant features of ICANN meetings is the Public Forum, where members of the ICANN community are able to present their views on issues of concern to them to the ICANN Board, in public session. The fact that we rotate meetings through each of the geographic sectors of the world enhances the opportunity that people from every region to present their views to the ICANN Board, in the presence of Staff and the whole ICANN community.

As a long-time participant from the floor presenting views, in my case from the ccTLD community, I am well aware of the time, effort and expense that goes into the preparation of such statements. As a board member, I have valued hearing those submissions, from individuals, governments and constituencies. I am determined as Chair to continue this tradition, and to maximise the opportunities for information sharing it represents.

I have been concerned, however that we have not always captured the inputs from these sessions, so in Cairo I asked Staff to review the comments made in the open microphone sessions of the Public Forum, and to provide responses to comments, and answers to questions that, in the interests of hearing from everyone wishing to speak, were not given on the day.

Those comments and answers are given below. I hope members of the community find this a useful process, and one which is worth continuing, after future Public Forums.
Thank you to those who contributed in Cairo. Please accept the Staff invitation to continue to contribute through the mechanisms they identify in the paper below.

Peter Dengate Thrush
Chairman, ICANN
15 December 2008

CONTENTS

COMMENTS

• Applicant Guidebook
  • Don’t delay process
  • Registry fee is too high
  • Application fee is too high
  • Scoring in Module 4.3
  • Independent string approach will cause problems
  • Start awareness campaign earlier
  • International Chamber of Commerce wrong for deciding morality claims

• IDNs and IDN ccTLDs
  • Government "control" over ccTLD IDNs
  • Three-letter rule wrong for IDNs

• Policy
  • Policy based too much on opinion

• IPv6
  • No consensus on what to do for IPv6 transition

• Board Review
  • Set CEO term limits
  • Board members should be compensated

• ICANN meetings
  • Take travel time into account when deciding on location
  • Uphold transparency and regional diversity when deciding on location

• General
  • Difficult to get ITU to recognize civil society
  • Country code manager should listen to their individual Net users
  • A lot of mistrust and suspicion at ICANN meetings
  • The organization needs more international staff
  • The organization should stay out of operational areas
  • Concern over a .companyname top-level domain
  • More representative groups needed in GNSO
  • Public comment should be a greater priority at ICANN meetings
  • Increase geographic mix of participants at ICANN meetings
  • Thanks to ICANN Staff

QUESTIONS

• Applicant Guidebook
  • Who will be the panelists?
  • Will IDNs and gTLDs be available at the same time?
  • How much will the refunds be and when will they be given?

• Improving Institutional Confidence
  • How can ICANN get over the legal obligation it has that it cannot trade with states identified by the US government?

SUGGESTIONS

• If a new registry makes under $1million it should be waived the annual fees under the Applicant Guidebook
• Allow non-profits to pay a percentage of the annual registry fee for the first two years of running a new gTLD
• Create a special cross-constituency working group to identify what ICANN could do to promote IPv6 update
• Lower the scoring in Module 4.2.3 of the Applicant Guidebook from 11 out of 12 to 10 out of 12
• Move Guidebook awareness campaign forward to January 2009
• Fund an outreach effort to reach groups such as families, consumers, victims of cybercrime to encourage them to form new constituencies in GNSO
• Fix more time for public comment into the meeting schedule
• Introduce metrics for ICANN Staff performance

RESPONDENTS

The forum took place on Thursday 6 November 2008 and came in two parts: between 12pm and 1.15pm; and between 2.45pm and 3.30pm.

This summary seeks to capture the comments made during the public forum and, where possible, provide answers to questions raised. You can view the full transcripts of both sessions on this website at:

http://www.icann.org/en/participate/cairo-public-forum-transcript.html

Or on the Cairo meeting dedicated website at the two following addresses:

http://cai.icann.org/files/meetings/cairo2008/public-forum-open-discussion-06nov08.txt
http://cai.icann.org/files/meetings/cairo2008/psc-public-forum-06nov08.txt

Input can be broadly split into three different areas:

A majority of the input during the forum came in the form of Comments. This input is summarized according to subject area with those individuals who raised the comment identified through their initials and a key at the end of the document.

Second, a number of clear Questions were raised and those questions are restated below, with answers provided where possible. And lastly, a number of Suggestions were made. Where appropriate, feedback on these suggestions has also been included.

While every effort has been made to capture people’s comments as accurately and fully as possible, the production of a workable summary that can be responded to will inevitably see the loss of some of the finer points of argument. ICANN Staff begs the community’s understanding and forgiveness for any resulting oversights.

COMMENTS

SUBJECT AREA: Applicant Guidebook

Explanation: The Cairo meeting saw the release of a draft form of the “Applicant Guidebook” for those interested in applying for new generic top-level domains (gTLDs). The draft was drawn up by Staff following the approval of the process itself by the Board in Paris in July 2008 (and following a number of years of policy work and implementation planning). The community was invited to comment, following the normal ICANN consensus-building procedures, on the draft guidebook in preparation for a revised version.

For more information and to post comments on the Guidebook, please visit: http://www.icann.org/en/topics/new-gtlds/comments-en.htm.

ICANN Staff response: While we understand the frustration of many in the community who have been following this process for a number of years, as many of you will also appreciate, it is a very complex task, made all the more complex by issues raised during the policy development process and the Internet’s increasing importance in global economies.

ICANN is committed to promoting competition in the domain name system and as such has been moving forward with the new gTLD program as quickly as possible. However, the organization is duty-bound to consider other aspects alongside competition when expanding the top level of the domain name system.

Most dominant among these are: the need to ensure the security and stability of the Internet; and the need to move forward through consultation with all of ICANN’s stakeholders.

During the course of the new gTLD program, a multitude of other issues, from trademark and sovereignty rights, to dispute resolution procedures, to technical barriers have arisen. ICANN Staff has sought to work through these as efficiently as possible. The result has been that initial estimates for when applications will be accepted have been put back several times.

While our expectation is that there will be changes to the current draft Applicant Guidebook, we plan to analyse the comments made and make any such changes in an efficient manner. The comment process itself has become an accepted and highly valued part of ICANN’s processes that its work is put out to public comment and review before being put before the Board.

Although the advantages to opening up applications as soon as possible (i.e. by starting the four-month communication process early) were clearly and persuasively articulated at the public forum, it is the view of ICANN Staff that the risks involved in not following the process as outlined through to completion may outweigh the advantages.

The public comment process has both a pragmatic and organizational advantage. Pragmatically, it allows many thousands of eyes to go through the application process to pick out any potential future conflicts and issues. The value of this review cannot be underestimated.

Second, ICANN is a multistakeholder organization where the Staff acts as a facilitator of the consensus view. Without a clear, transparent and open public comment process, the ability of the community to both check on the Staff’s work and to provide implicit approval of the process is lost.

There is also the fact that public comment periods and broader communications bring with them greater awareness of ICANN’s work beyond the small number that follow ICANN closely. In the case of new gTLDs, this awareness will be crucial to the project’s success.

For this reason, it is the Staff’s view that the process needs to continue on its current path, even though that will mean that applications for new gTLDs will not be accepted until the third quarter of 2009.

Staff will continue to update the timetable on the process as it continues.

The $75,000 annual registry fee outlined in the Applicant Guidebook is too high (MF, DK, R1, SR, RA, AP, MB, JB, AM, IA, TH)*. It may have the effect of restricting applicants (MF, DK, R1, SR, AP, IA)*; the costs will be passed onto consumers (RA, AM, TH)*; and it does not account for smaller communities (SR, JB)* or non-profits (TH)*.

ICANN Staff response: The current assumption in the Applicant Guidebook is that a new registry will pay $75,000 or five percent of transaction revenue to ICANN, whichever is higher.

That fee would cover the support ICANN provides to registries: such things as compliance, registry liaisons, and possible increased registrar activity. Currently every registry pays such a fee and this approach provides a highly valued level of stability to the system. It also recognizes the fact that every new registry added to the Internet comes with an associated and ongoing cost.

In the explanatory memorandum to the pricing issue in the guidebook (download it from: http://www.icann.org/en/topics/new-gtlds/cost-considerations-23oct08-en.pdf), it is twice noted (in section 3.5) that there may need to be some flexibility in this fee. First it recognizes there will be “a variety of different models for new gTLDs” and secondly it draws reference to “community or other limited registration uses” that may have different requirements. However, it still suggests the full $75,000 fee for all applicants.

We clearly heard a number of voices during the public forum saying that they felt this figure, although not the notion of such a figure, was too high. One or two suggestions were also put forward, such as allowing smaller fees to be paid for the first two years while a new registry stabilized itself.

This is the purpose of the public comment period: for the community to question and test the assumptions made in the production of the Applicant Guidebook.

The level of the annual registry fee has clearly been flagged as an issue, and as such we urge and encourage the community to now go beyond raising the issue and to provide greater information from which ICANN Staff can define a way forward.

Does the $75,000 level genuinely risk disrupting people’s plans for legitimate gTLDs? Or is it simply a large sum of money that looks foreboding at the start of the process? Can you supply real-world figures to back up the argument?

Are you uncertain that it costs ICANN $75,000 per registry to cover its services? Would a breakdown explanation of those costs alleviate your concerns? Do you have possible solutions that may help young registries find their feet, while maintaining stability across the registry system?

ICANN welcomes all such input. You can email your comments on this issue directly to: gtld-intro@icann.org.

ICANN Staff response: We outlined the reasoning behind the $185,000 application fee in quite some depth in an explanatory memorandum (download it here: http://www.icann.org/en/topics/new-gtlds/cost-considerations-23oct08-en.pdf).

Broadly speaking, we arrived at the figure by:

• Calculating out how much it has cost the organization so far in arriving at the new gTLD process and guidebook
• Using the two previous gTLD rounds to arrive at a cost per application
• Estimating the additional costs and risks associated with the application process this time around
• Dividing a fixed cost figures by the number of applications we estimate will be received – in this case, 500

This approach was taken because it was determined during the policy making process of this project that the whole thing should be “revenue neutral” i.e. that the application fee should cover the costs of the project.

We should note as well that this wasn’t just ICANN Staff drawing up these figures – we hired the services of the world’s third largest insurance broker and risk consultant, Willis Enterprise & Risk Finance (WERF), who looked very carefully at risk aspects of the process and came up with a figure that we adopted.

Of course, we have no way of knowing how many applications there will actually be, but this is the best estimate we have. If there are more than 500 applications, ICANN may have a surplus of money; if there are fewer, a deficit. Either way, the figures will be made publicly available and the community will be consulted about the best path forward once we have a firmer idea of what those figures actually are.

It is also worth noting that the issue of fees, possible reductions and grants was extensively reviewed in the creation to the guidebook. The guidebook notes: “No practical method of ICANN financial assistance or fee reductions was identified for the first round of new gTLD applications, though an appropriate mechanism might be defined for subsequent rounds. If Staff is able to identify sources for potential grants, financial assistance or match-making opportunities for applicants from qualified developing nations, and indigenous and minority peoples in need, the results will be made publicly available.”

So, while we recognize the community concern expressed during the public forum about the application fee, Staff remain confident that the $185,000 application fee is the best figure that we can arrive at, given the decision by the ICANN community much earlier in the process that the whole thing should be revenue neutral.

That said, we welcome review of the assumptions we have made in arriving at that figure. The Board will be reviewing the assumptions, including the extent of past years’ costs to be recovered, and there may well be some changes made in the final guidebook, dealing with, for example, applicants for multiple TLDs.

As time progresses, it may also be possible that more precise figures, for example on the number of applications, become available. As mentioned above, we would also welcome information and suggestions on sources for potential grants, financial assistance or match-making opportunities.

It is possible that ICANN Staff and WERF accidentally overlooked something that may have an impact on the pricing. If so, please let us know as soon as possible.

If you feel you are able to provide this kind of valuable feedback into the process, we strongly encourage you to do so. You can email your comments on this issue directly to: gtld-intro@icann.org.

ICANN Staff response: Thankyou for this input. The main reason behind the public comment process is for the community to question and test the assumptions made in the production of the Applicant Guidebook.

We note that the individual that made this comment at the public forum has gone into greater depth on this issue in an email to the public comment period, and we thank him for that. That email will form part of the review of all comments submitted in the first comment period for the Applicant Guidebook.

We would also encourage any others who would to make their views known on this issue to make them directly into the public comment process by sending an email to: gtld-string@icann.org.

ICANN Staff response: As anyone who has followed this process will no doubt be aware, the issue of related strings, or confusingly similar strings, the issues of trademark rights and usage rights, and the unique issues of internationalized domain names have all been extensively reviewed and debated for a number of years, both in the policy-making and in the implementation planning.

There exists no system or solution that will solve all – or even most – of the issues and problems associated with creating new top-level registries on the Internet.

As a result, the solution arrived at to deal with the multitude of potential issues was to devise a flexible dispute resolution process handled by third-party experts. In this way, ICANN can concentrate on its core functions while providing outside expert decision-making facilities where needed. Or, put another way, ICANN Staff has no desire to become a referee in a dispute over potential ownership of a gTLD.

That said, while the input provided on this point is unlikely to change the dispute resolution systems that the Applicant Guidebook outlines, such feedback may prove valuable to those organizations that will act as the arbitrators of future disputes.

ICANN Staff will see to it that the third-party experts it retains for dispute resolution are made aware of all of this feedback in order to help them devise appropriate systems and solutions and provide them with insight into the intricacies of this work.

We encourage all community members to send their reflections on this issue to: gtld-string@icann.org.

ICANN Staff response: We understand that for many members of the ICANN community, having an awareness campaign for a process that they have closely followed for several years may appear to be a waste of valuable time.

However, the rationale for such a campaign stems from the fact that the ICANN community comprises of only a few thousand people while the introduction of this round of new gTLDs has the potential to impact hundreds of thousands, even millions of people. Press interest in the new gTLD program at the ICANN Paris meeting was so significant and global that we recognized there was a clear need to explain the process and the application procedure globally before we embarked on the actual applications.

The reality is that it is not possible to run such an awareness campaign until the details are finalized. It would be self-defeating for ICANN to be in a position where it ran an awareness campaign that either did not contain all the information, or where the information subsequently changed. As such, the campaign can only begin properly once the guidebook has been through the full public comment process.

Why four months? First, that period was suggested by the GNSO as implementation advice. Second, based on the advice and expertise of a number of communications professionals, four months was seen as the shortest period of time in which ICANN could effectively get the message out.

It is perhaps worth pointing to the positive effects that such an awareness campaign will likely have: the Internet has become the extraordinary force it is today because its open structure has enabled people with ideas to try them out with far lower overheads than were previously possible through any other medium.

While the ICANN community is an extraordinary collection of individuals, no one will claim that we have a collective monopoly on insight into the domain name system’s potential. An awareness campaign will not only make it more likely that the people with the next revolutionary idea hear about the new gTLD process, but it will also bring in new participants to the ICANN model – something that everyone can also agree is a good thing for the organization and for the Internet as a whole.

ICANN Staff response: On the surface, it may appear odd that the International Chamber of Commerce be used to decide issues of morality and public order.

However, the way morality and public order decisions are actually made in this context is through accepted legal norms recognized under international principles of law. In that respect – looking at these issues through legal eyes – the arbitration division of the International Chamber of Commerce is ideally suited and has a wealth of experience and expertise in dealing with these situations.

If the community has recommendations for an alternative dispute resolution provider for this element of the process (or the other two elements: string confusion, and legal rights) then ICANN Staff will review that recommendation.

For any and all input on this issues and related dispute resolution issues, please email directly into the public comment process by using the following email address: gtld-dispute@icann.org.

Giving governments control over ccTLD space may stifle competition (R1, R2)*

ICANN Staff response: We are aware of the concerns that people have regarding the IDN Fast Track – where a limited number of internationalized domain names (IDNs) are approved before a full policy is developed by the country-code names supporting organization (ccNSO).

However, with respect to the fears raised about governments having some form of control over this space, we believe this stems from a misunderstanding of what ICANN is doing with regard to internationalized domain names.

First off, it should be noted that IDN applications will be accepted as part of the new gTLDs process. That means that anyone following the gTLD Applicant Guidebook requirements will be able to apply for a top-level domain in their script or language.

There are additional criteria that need to be considered for IDNs (all of which are outlined in the Applicant Guidebook). However, applications for IDNs will be accepted and will be introduced at the same time as other gTLDs.

The ccTLD Fast Track on the other hand covers a very specific type of IDN – namely, those domain names that represent the name of a country or a territory.

During the course of the policy processes that the community has gone through over the past year or more, both governments (through the Governmental Advisory Committee, or GAC) and country-code managers (through the ccNSO) expressed their concerns about people applying for new top-level domains that represent the names of their countries or their existing top-level domains.

It has long been a rule that new generic top-level domains must be made up of at least three letters. One-letter TLDs are held back for technical reasons; and two-letter TLDs are reserved for use by the countries of the world i.e. .de for Germany; .jp for Japan; .us for the United States (and are based on an international standard).

The addition of TLDs in other languages and scripts complicates this system. Firstly, in some scripts whole words can be produced using a single character. Secondly, taking Japan’s ccTLD as an example, .jp is an ASCII representation for Japan, but Japan has its own script that does not use “j” or “p”. The countries of the world are justifiably proud of their own ccTLDs – many of which represent the Internet itself to their peoples – and so they have asserted that they have a right to have their language equivalent of their ccTLD.

In the same vein, many governments are concerned that individuals or companies will register top-level domains that represent the country. To use Japan again as an example, something like “.japan” or the equivalent of .japan in Japanese script.

It is for these reasons that the ccNSO is embarking on a policy development process to decide how to resolve such applications. Since this process will take some time, and because of the significant demand that has built up for TLDs in other scripts, the ccTLD Fast Track was created to allow for the creation of IDN TLDs that both the GAC and the ccNSO could agree would not be challenged (it should be noted, incidentally, that The Fast Track is based and builds upon the current IANA practices for the delegation of ccTLDs).

This means that those IDNs that come through the Fast Track will, by design, need the endorsement (or non-objection) of the relevant public authority, which in many cases will be a government department. At the same time, it must also meet the need of that particular community and the community must demonstrate that they are ready to implement the IDN ccTLD.

That is very different from saying that governments will have controls over IDNs or even IDN ccTLDs, however. Although it is true that IDNs that denote a specific country will be unlikely to make it through the new gTLD application process (as they are likely to be considered part of the ccTLD Fast Track), the whole world of top-level domains in different scripts is open to those that wish to apply.

So while a Japanese organization will not succeed with an application for .japan, or .jp in Japanese script, it will be able to apply for something that has meaning to Japanese Internet users in their own language. So, for example, cartoons are extremely popular in Japan. If an organization felt there would be sufficient interest in a whole area of the Internet dedicated to cartoons, it could apply for .cartoon in Japanese script.

So the ccTLD Fast Track is not stifling competition at the ccTLD level any more than current practices. While at the same time, the new gTLD process will hugely increase the opportunities for competition for Internet users across the world and in their own languages by allowing IDNs.

ICANN Staff response: Thank you for this feedback and for highlighting the disparity that can be created by applying English-language rules and assumptions onto other scripts and languages.

The example given in the public forum of “.cat” being represented by a single character in Chinese but also being represented by many more than one character in the domain name system itself (all domains in non-ASCII scripts being represented a the technical level by the ASCII prefix “xn--“) was a helpful illustration.

Please be assured that ICANN will carefully review whether and how the three-character rule can be applied with regard to IDNs. As always with IDNs, however, the fact that there are many thousands of different scripts, each with its own attributes, means the issue is likely to be complex.

If it is indeed possible to waive the three-character rules for IDNs, or certain types of IDN, without detrimental impact elsewhere, ICANN will follow that path. As it currently stands, single-letter characters will not be allowed for technical reasons and two-character domains are held back because of the traditional use of the ISO list for defining country-code TLDs. We are waiting on further public comments to guide final recommendations.