Read the report in full here [pdf]

The report includes information on the three major initiatives ICANN undertook last year (and which continue this year): the process for introducing new generic top-level domains (gTLDs) to the Internet; the introduction for the first time of internationalized domain names (IDNs); and an extensive Improving Institutional Confidence consultation, to enable the conclusion of the Joint Project Agreement (JPA) with the United States government in September 2009.

Reports from the chairs of ICANN’s Supporting Organization and Advisory Organizations are included alongside detailed rundowns of each department by the organization’s staff.

Additionally, since it is 10 years since ICANN’s inception a brief history of the organization, split into its 33 international public meetings, is included, alongside a special memorial note to Jon Postel, one of the Internet’s pioneers, from former ICANN chairman Vinton Cerf.

Further contents include:

• Biographical details on each of the Board of Directors
• Highlights of the organization’s Strategic and Operating Plans
• An in-depth look at the New Delhi, Paris and Cairo meetings
• Messages from the CEO and Chairman
• The audit report for ICANN, 2007-2008
• ICANN’s compensation practices and salary structures for the corporate officers

Here’s what the chairman had to say in the official announcement: “I am delighted to announce the release of our third annual report,” said Peter Dengate Thrush, ICANN’s Chairman of the Board of Directors. “In this our tenth year ICANN and its community either accomplished or made significant progress toward many goals for the Domain Name System.”

“The Internet is growing and evolving at an accelerating pace,” Dengate Thrush continued. “The next billion users will demand more innovative products and services, will access the Internet largely through mobile devices, and will expect to be able to do so in their own languages and language scripts. ICANN’s efforts are geared towards developing policies and technologies that will satisfy this next-generation Internet.”

The complete annual report is available at: http://www.icann.org/en/annualreport/annual-report-2008-en.pdf.

You can find all of those videos posted on the Cairo site at http://cai.icann.org/video, and we also post ICANN videos on the main site under the main tab “Videos”.

This video features two of ICANN’s project managers – Tina Dam and IDNs, and Karla Valente and new gTLDs – talking about the sessions they were due to run on the first day of the conference where introductions were given to their two topic areas.

Below is a transcript of the video and off to the right is the video itself.

* Domaine.info and ICANN Present
* ICANN CAIRO Egypt November 2008
* Introduction to New gTLDs & IDNs (Sunday 2 November 2008)
* Hi. My name is Tina Dam. I am the IDN Program Director at ICANN.
* Hi. I’m Karla Valente and I am the Director of the New gTLDs Program.
* So we are in Cairo and its Sunday and there is a lot of IDN stuff going on. We have actually had IDN gTLDs in the room for a year
* and look at all of the activities that are going on.
* We just recently posted New gTLDs Applicant guidebook, so if you go to the ICANN website,
* you will be able to find the guidebook, download, and learn everything about new gTLDs if you want to be an applicant.
* And you can have IDNs as gTLDs as Karla talked about or you can have IDNs as ccTLDs, and there is a ccTLD program available as well.
* And that’s online also.
* And right now the guidebook is open for public comments, and this is a very important step in the ICANN process.
* We are going to be looking at the feedback and continue developing until we reach the final version.
* The final version should be published sometime in Q2 next year and we expect all the applications for gTLDs to be ready Q3 next year.
* So we encourage you to participate. We want to hear from you.
* You can take a look at all of the sessions today and tomorrow. There’s going to be multiple sessions on IDNs and ccTLDs.
* Different sessions that we have today and tomorrow are going to be in English and in Arabic.
* The session today is an introductory session for someone who has never heard of new gTLDs.
* Tomorrow we are going to cover the applicant guidebook, talk about the structure, what to do with it, how to read it and so on.
* A lot of this is about policies, but there’s a lot of technical stuff to.
* One thing that Karla and I worked together on is making sure that IDN gTLDs and IDN ccTLDs technically are working
* and are validated in the same way. So if you want to apply for an IDN string, it has work in the same way.
* First of all, thank you for all the work you have done to help us make these implementations and all this work available.
* And we’ll see you next time. Karla is going to say this in Arabic…[laughs]
* We are looking forward to hearing from you, either through the public comments or maybe the next ICANN meeting.
* Copyrights Domaine.info 2008 Tous droits reserves
* Your comments and reactions are welcome Vos commentaires et reactions sont les bienvenues participate@icann.org

During the Cairo meeting in general, ICANN together with Domaine.info produced a number of videos covering the main sessions and topics, with each video fronted by a member of either the staff or a chair of the relevant supporting organization or advisory committee.

You can find all of those videos posted on the Cairo site at http://cai.icann.org/video, and on the ICANN main site under the “Video” tab.

This video features consultant Patrick Sharry talking about the AC/SO session, which he helped moderate. This joint session will be repeated in Mexico City on the first day of the meeting with a slightly different format following feedback from the community on the first meeting.

Below is a transcript of the video and off to the right is the video itself.

# ICANN and Domaine.info
# ICANN, CAIRO Egypt- November 3, 2008
# Open Joint Session, GNSO,ccNSO, GAC, ALAC Domain.Name.Space
# Hello, my name is Patrick Sharry
# Today I facilitated a very important meeting.
# For the first time at an ICANN meeting,
# we had the chairs of the SOs and ACs.
# organize themselves together for a joint meeting of those groups.
# There were two topics discussed, we talked about the President’s Strategy Committee and
# the Improving Institutional Confidence work
# and we also talked about new gTLDs, IDN ccTLDs, and the issues around those things.
# It was a meeting that ran very well,
# and not least because people recognized how important it was,
# to bring these groups together to talk about issues of such importance.
# During the PSC session. we started with a presentation by the chairman, Peter Dengate Thrush.
# Peter outlined the recent work that the President’s Strategic Committee had been doing,
# and ran through a few slides that talked about the relevant areas that we needed to consider.
# We then got some views from the Supporting Organization and Advisory Committee chairs
# who were seated at the top table.
# And from there, we began a conversation with the community as a whole with an open mike session.
# There were a number of comments on many different aspects of that work.
# As the conversation proceeded, I tried to capture on the white board, some of the key topics of those conversations.
# That list of topics, will then be presented to staff and to other parts of the organization for further consideration,
# as we move into the next phase of the improving institutional confidence project.
# In the second half of our session, we concentrated on new gTLDs, IDN ccTLDs and the issues that surround that.
# We began with comments from each of the Supporting Organization and Advisory Committee chairs,
# They told us what was important in these areas from their own SO or AC perspective,
# And also why those things should be of importance to the community as a whole.
# We interspersed conversations from the SO and AC chairs, with comments from the floor,
# and in particular, we had a particularly productive session at the end where we looked at the issue of geographic names.
# This conversation produced interesting interplay between a number of people in the ICANN community,
# about the issue of what was a gTLD and was a ccTLD
# How should the process run and who should be involved.
# Again, as we had this conversation, I collected on the white board the main topics that people were covering.
# This list will be put into the process of one of a number of items that have been collected this week,
# to help the team who are working on IDN ccTLDs and new gTLDs to further their work,
# as part of the community consultation that they are doing in order to come up with the next phase of that for our next meeting in Mexico.
# Thank you for listening to all of this. It was a very important meeting for the ICANN community,
# as we work forward, I’m sure that we’ll find better ways of running these meetings,
# and that means by the time we get to Mexico and beyond, we’ll actually have even more productive ways
# of bringing these important parts of the ICANN community together. Thanks again for your time. Bye bye.
# Copyrights Domaine.info 2008 All Rights Reserved
# Your comments and reactions are welcome Vos commentaires et reactions sont les bienvenues participate@icann.org

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.

You can find all of those videos posted on the Cairo site at http://cai.icann.org/video, and we will also be posted all ICANN videos on the main site under a new tab “Videos”.

This video features Senior Vice President of Services, Kurt Pritz, talking about the session he ran on the recently released Applicant Guidebook, going through it with attendees and taking questions and comments.

Below is a transcript of the video and off to the right is the video itself.

# Domaine.info
# Domaine.info and ICANN Present
# ICANN CAIRO Egypt November 2008
# Workshop Understanding the Draft RFP for New gTLDs A NovaMedias Production
# Hi, I’m Kurt Pritz. We just finished a well attended session on the new gTLD applicant guidebook that was originally posted on our website.
# The purpose of the workshop was to describe for potential applicants and those interested in the new gTLD process
# the nuts and bolts associated with applying for a new TLD. The guidebook provides a direction manual for those interested in applying.
# The presentation started with some of the principles associated with the guidebook. The fact that the guidebook and the whole gTLD process
# and the introduction of the new gTLDs into the root zone was really more in ICANN’s mission at its founding…
# and then it was carried through by an intensive policy development process that was carried through by ICANN’s policy making bodies…
# notable the gnsl that provided policy recommendations to ICANN in creating this body of work.
# Its ICANN now implementing those policy recommendations that are going to allow iCANN to open up the domain space
# and provide additional competition and choice for consumers and the internet.
# These TLDs will be introduced with principles of conservatism, both technical and fiscal , the introduction of names in a measured way
# that will provide for the ongoing stability and security of the domain name system.
# So beyond that, the workshop took potential applicants and those who are interested, through the various application
# and evaluation criteria that applicants for new top level domains will be measured against and tried to present a clear road map
# of the applicant guidebook so those that attended or who will attend online later, can look at the guidebook and find the info they wish to find.
# ICANN’s published this applicant guidebook as a draft for community discussion. The clear idea is to garner opinions
# and expert advice from those members on the community that can offer information that will result in improvements to the draft RFP.
# Thus far at this meeting already we have seen several comments that will serve to improve
# the quality of the RFP and the integration into an entire process.
# There was a comment regarding vision for opening the domain space and defining that vision well so that, at the end of the day
# when the round is over, we can measure the results of the new gTLD process to determine if those objectives have been met.
# There are also several specific suggestions regarding individual elements of the applicant guidebook,where that can be improved.
# So already, even though there will be some changes to the guidebook, to the directions for applying for a new TLD
# that will make it more effective. We look forward to carrying on discussions this week and through the next month and a half
# so that those suggestions can be incorporated in the next draft applicant guidebook that will be published in early 2009.
# So as with all ICANN staff and board members we’re delighted to be here in Cairo and we would like to thank our host for hosting such a great meeting.
# I also want the thank the participants in the meeting. Those who attended gave up their time and have spent time looking at all these
# materials in order to provide their advice and expertise so I would like to thank them for that.

How does the DNS work?

The DNS can be considered to be a question-and-answer system. When you type in an address like “icann.org” into a web browser, your computer needs to turn that into a numeric address of the computer hosting that website. To do this, it sends a question over the Internet to a DNS server “Where is icann.org?” The DNS server sends back an answer, “The address is 192.0.2.0”.

How do you attack the DNS?

Let’s say I want to execute an attack on this question and answer exchange, in order to convince the computer to go to the wrong address. When the computer I wish to attack asks a question, my goal is to provide a fake response back to that computer quicker than the real server comes back with the response. By getting my forged answer back faster, the computer will proceed using my answer, rather than the official one.

So, if I send back a fake address to a computer, I can get that computer to go to a different address than the one intended. For example, on that address I might have set up a fake website intended to take someone’s sensitive data, like a replica of a bank’s website.

If I manage to attack one computer why is that a big deal?

A successful attack on one computer in isolation can be problematic for the user of that computer, but it is not that interesting to an attacker to succeed against only one person. Unlucky for us, just one successful attack can very easily have wider consequences. Let me explain.

The DNS is made much more efficient by the use of “caching” name servers. These name servers sit at ISPs, or on corporate networks, and perform DNS lookups on behalf of customers. It then stores the answers it receives in a cache, so for future lookups for the same domain it does not repeat the lookup – it just remembers the previous answer.

This means that if you execute an attack and it gets stored in a cache, it can actually impact many people over and over again, because that answer will be redistributed to everyone that uses that same caching server.

This is why this type of attack is usually called a “cache poisoning” attack, because by poisoning the cache with the wrong data, it creates a much more serious problem.

So I just send back an answer quicker, and that’s it?

It is not quite as simple as just sending a quicker answer back to a computer, you also have to guess certain attributes correctly on the answer that match the question. For example, your answer needs to go back to the same computer the question originated. You also need match the question that was being asked in your answer.

It is simple, however, to guess most of the attributes. As you know which computer you are trying to attack, you don’t need to guess that. As you know which domain you are trying to impersonate, that is also a given. Conventionally, there are only two variables. One variable is you need to guess which server the answer is coming from. The average domain on the Internet has around two or three name servers, only one of which will respond to any given query. Therefore you have about a one in three chance of guessing that correctly. The second variable is a unique reference number (formally, a “transaction ID”), that has about 65000 possibilities. Therefore you have about a 1 in 65000 chance of guessing that correctly.

Earlier this year, security researcher Dan Kaminsky found that it is devastatingly simple to exhaust all those possibilities in a very short amount of time by performing an attack in a certain way. How short? Well, British DNS researcher John Dickinson did some tests and found that on average he could successfully attack a server in just 1.3 seconds.

How do you fix the problem?

The sad news is there is no real solution as far as the regular DNS is concerned. It is not like a security hole in a piece of software that can be repaired with an update. This is an architectural flaw in the DNS protocol itself. There are patches for DNS software, but these only attempt to make executing an attack more difficult, they don’t solve the problem.

Some of the short term approaches to make attacks more difficult are as follows:

1. Randomise the “source port”. One of the attributes in the packet that an attacker needs to guess is called the port number. For architectural reasons, this needs to be port 53 on the way to the server — this is how the server realises it is a DNS query as opposed to a different type of query. However, the port number that a response is sent back to doesn’t need to be port 53. By randomising this, you make it harder for an attacker to guess. Much of the software updates to this problem in mid-2008 related to adding source port randomisation.
2. Block open recursive name service. If you provide access to a caching name server to the whole Internet, then it is very easy for the whole Internet to execute an attack against your server. If you limit access to just those who need it (i.e. your local network), then you reduce that risk.
3. Experimentation with capitalisation of domains. Domains in practice are not case sensitive – if you type ICANN.ORG or icann.org, it means the same thing. However, inside the DNS protocol itself, the encoded transmission between computers actually is case sensitive. This property can be used to add some more randomness to transmissions. If my computer sends off a question asking about “iCaNn.OrG” and gets back an answer for “icann.org”, it can throw it away as untrustworthy. This approach is still experimental and being discussed.

The net effect of these attempts to reduce the risk of attacks primarily involve adding more randomness for the attacker to guess. These approaches approximately double the number of “bits” of randomness. To be clear though, they only make an attack harder, but an attack is still viable. Furthermore, we know that both network speeds and computer speeds get faster and faster each year. These are the two things that slow down an attacker. Therefore, we know that successful attacks will just be easier and easier into the future.

If there is no short term solution, what is the long term solution?

While the DNS itself can’t be properly fixed for the security problem, a new protocol that overlays the DNS called DNSSEC does. DNSSEC uses a system of certification to show that a DNS answer has not been modified. If someone tries to execute an attack, the certificate won’t validate, and the incorrect answer will be thrown away.

DNSSEC is difficult to deploy. It requires upgrades in DNS servers, it changes the way domain name holders manage their name servers, and it adds extra complexity. However, with the knowledge that DNS attacks are so simple to execute without it, there is growing consensus that the pain it will take to deploy is less than the pain of a DNS that you can no longer trust.

More information

You can view the presentation slides used in Cairo.

Why Compliance with IDN technical requirements are a necessity on a global scale

Overall compliance with technical standards are important for TLD registry operators in order to keep their TLD stable and secure and in that way function and work well for their consumers and communities. Per ICANN Bylaws, interoperability of the Internet is a core value, which requires that technical standards are complied with. In some instances failure to comply with technical standards will only affects the corresponding TLD in isolation and does not interfere with other TLDs – when moving to the topic of IDN TLDs however this fact changes very quickly.

The following will demonstrate how non-compliance with IDN technical standards in one country or territory has a negative effect on the entire Internet community and not solely on that country/territory.

What history has shown us is that when IDNs are implemented in a manner not consistent with the IDNA protocol and IDN Guidelines it has a very negative effect on the community in general. For example, initially, under some TLDs, IDNs were implemented in a way that allowed the individual users and registrants to pick among characters across scripts when making their . registration. This resulted in visual confusability and phishing attacks.

One specific example of this is paypal.com, where the “a”‘s are Cyrillic characters and the rest are Latin letters. This address is visually the same as paypal.com (all in Latin letters), but physically, to the computer, these are two different addresses. This is damaging the uniqueness principle of the DNS – probably the most important principle of the DNS and what makes it work in a stable manner.

What further happened as a reaction to these kinds of implementations of IDNs is that application developers that need to implement the IDNA protocol in their application software in order for IDNs to work (for example in order for IDN based web addresses to resolve in a web-browser) did not follow the technical standards either. The reason behind this non-compliance has been an attempt to protect users from issues such as the above mentioned phishing attacks. For example, some browser developers have implemented white-listing of TLDs that have implemented IDNs, where the browser developer decides which TLDs are have implemented IDNs in a safe manner based on criteria set by the browser developer.

As a result the end user is presented a variety of different implementations that aim at introducing security levels that really only can be implemented and need to be implemented at the root and TLD registry level. As a consequence if two TLDs support the same language and script, they also can accept the same 2nd level domains, and vice versa, if one lookup a domain name in Unicode in one TLD then one should be able to use the same software to look up the same Unicode domain name in a different TLD – however this will not always be possible. In other instances application developers have introduced mechanisms that prevent domain names in certain scripts from resolving or otherwise functioning adequately.

If IDN implementations continue down a road of non-compliance with IDN technical requirements, such as those present in the IDNA protocol and the IDN Guidelines, it will not be possible to determine what the level of damage will be for the end-user. The worst scenarios could be one of the following two: either that IDNs will be filled with phishing attacks that IDNs will be of no use and users will be scared of using them, or restrictions in the application layer will be so strict that IDNs will for example not resolve in an adequate and at least not in a stable and secure manner. Either way, this does not provide the community what they have asked for and what we are attempting to provide them with the implementation of IDNs, namely, equal access to the DNS by all languages and scripts.

Other examples can be provided on request. These relate to reasons why the IDNA protocol is under revision and are further documented in RFC4690.

In summary the above demonstrates why compliance with the IDN technical standards are of outmost importance, and why we need to find a way of ensuring that such compliance is in place and kept in place for TLD operators with IDNs implemented, regardless of whether it is a second level or top level.

We’re always trying to improve the quality of remote participation at ICANN meetings and tomorrow in Cairo will see a first trial of the most interactive session we have ever run.

The SSAC meeting at 11.15am local time, Monday 3 November, will be run over Adobe’s Connect software and by clicking on a simple link, in one window in your browser you should be able to:

* Watch live video of the meeting
* Hear the meeting
* Read real-time text scribing
* View the presenter’s slides as he/she goes through them
* Ask questions online, and
* Send chat messages to others online

This is an experiment so we would encourage all of you to try it out and report back with what happened at your end. If it proves successful and people like it, we will roll it out further at the next meeting in Mexico City.

So, here’s the link [link now dead]: http://icann.na3.acrobat.com/r40667447/

And here is the archive of the session: http://icann.na3.acrobat.com/p88047362/.

Hopefully see you all tomorrow at 11.15am Cairo time.

There have been pluses and minuses to each approach. With some, slow responses times; others, heavy server loads. We have tried different types: PHP, Flash, ICQ. In each case some people can’t get into them whether because of technical knowledge or operating system or browser software.

Last time around, people told us that having to go to a particular webpage in order to get into the chatroom for that meeting was adding a step and so reducing their likelihood of joining.

So we are testing another approach in Cairo for the Improving Institutional Confidence session on Thursday 6 November at 2pm: embedded chatrooms.

This time, we have used a third-party provider that runs the chatrooms on its servers, and allows people to embed Flash code on people’s sites that point to the same chatroom. So, the idea is that ICANN sets up chatrooms, provides the community with the code and you can all embed the chatroom wherever you wish online – our main hope is your blogs.

This means multiple entry points to the same chatroom. Which would ideally mean that particular meetings that people are interested will see them posting that meeting’s chatroom to their own pages. We don’t know if this will work well, or if people will find it valuable, it’s an experiment. But for anyone interested in improving remote participation, please do try it out and get back to us.

You should be able to see the chatroom for the IIC session below. To grab the code for the chatroom to embed into your site, just click on “Embed Chatroom!” on the bottom left of the chatroom below, and it will show up. Incidentally, the Cairo meeting page for the IIC meeting is here: http://cai.icann.org/en/6nov08/iic.