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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Session goals and outcomes:

The public forum is the community’s opportunity to make comments on the main topics in front of ICANN at each meeting directly to the Board and in front of the rest of the community.

The goal is to give a public and open forum for issues to be raised toward the end of the meeting and draw the community and Board’s attention to anything important.

The public forum is split up into the main topics of the Seoul meeting with a time alotted for each subject (see below). Attendees are encouraged to be brief and concise to enable as many people to speak as possible. A microphone is placed near the front of the room and commenters line up behind it to take their turn in asking a question.

Answerable questions are much preferred to comments, and both are preferred to statements – which can be incorporated into the official record without the need to read them out. If there are a large number of commenters, a two-minute clock may be introduced.

The ideal outcome of the public forum is that everyone who has an important issue to raise is able to relate it to the Board while also making the community aware of the issue.

The issues for discussion and their time slots are provided below.

Those topics are:

Status reports

• Document deadlines
• Language
• Calendar of meetings

For discussion

• Public comment process
• Public Forum
• Electronic tools for participation

You can download the backgrounder document here, or read the whole thing below. Everyone is encouraged to read it and come along to the meeting to discussion how ICANN can improve its public participation.

Public meeting backgrounder

Wednesday 24 June 2009

This backgrounder document has been prepared in order to promote more efficient and effective dialogue in the limited time available for the public meeting of the Public Participation Board Committee.

The Committee is working on a range of ways to improve public participation, with the expectation that most of them will be in place in time for ICANN’s meeting in Seoul in October 2009.

The Committee also recognizes that this document will not be released within the document deadline it has sought to outline for the organization to enable effective community review before meetings.

However, in order to promote discussion and dialogue with the community on these issues and to encourage participation in the development of these changes, initial thoughts and ideas have been drawn up and are published below.

The Committee will be available on Wednesday 24 June 2009 at 9 a.m., for about 90 minutes, to discuss any aspect of these ideas and proposals, and those individual Board members on the Committee would also like to encourage community members to share their views and opinions with them directly if there is not sufficient time during that meeting or they are unable to attend.

Topics

The Committee has six main issues it is working on at the moment.

Three of them will be covered here in the form of status updates, and they are:

• Document deadlines
• Language
• Calendar of meetings

And the other three will be specific topics of discussion at the public meeting:

• Public comment process
• Public Forum
• Electronic tools for participation

Each is coverered individually below, in this order.

Document Deadlines – Status Update

The issue of document deadlines, i.e. introducing a cut-off date for the production of documents prior to ICANN international public meetings, was raised at the Committee’s previous meeting in Mexico City.

The idea having met with unanimous approval, the Committee moved forward, proposing a specific resolution to the whole Board at its May meeting.

As a result, the Board approved the introduction of two deadlines for Sydney, and charged the Public Participation Committee with developing a fuller policy in time for the Seoul meeting in October 2009.

The relevant resolutions can be found at: http://www.icann.org/en/minutes/prelim-report-21may09.htm , point 8).

Below is a quick summary of the feedback received on this point from the Mexico City meeting. Underneath that is an expanded explanation of document deadlines taken from Committee documents used in arriving at the Board-approved deadlines.

Feedback from Mexico City:

1. Support for idea of document deadlines (Note: This is now instituted)
2. But need to communicate that very clearly to SOs and ACs (Note: we hope to achieve that in Sydney)
3. May be useful to produce zip file of all documents for a meeting (Note: something that will be considered for the Seoul meeting as part of the development of an operational policy)
4. Need agenda and presentations earlier (Note: Again, something that will be considered as part of the operational policy)

Excerpt from Committee working documents:

The need for document deadlines

It has long been a complaint of the community that documents are published too late prior to an international public meeting for there to be full consideration of their contents before the meeting starts.

The Committee recognizes the improvements that ICANN staff has made in this respect and also notes that many documents require the input and review of a significant number of people, both staff and community members, which can make early publication of documents difficult.

Nonetheless, due to the strength of feeling expressed by the community on this issue and the fact that it is clear best practice to provide documents sufficiently far ahead of a meeting for their contents to be properly and fully digested, the Committee is making a series of firm recommendations on document deadlines.

It is our belief that these deadlines will make possible greater and more effective participation within ICANN processes.

Community feedback

At the Committee’s public meeting in Mexico City, there was widespread support for the production of document deadlines prior to international public meetings.

Among those who specifically supported the idea were: Chuck Gomes of VeriSign; Ayesha Hassan of the International Chamber of Commerce; Marilyn Cade, a member of ICANN’s President’s Strategy Committee; Zahid Jamil, a GNSO Councillor; and ICANN’s President and CEO, Paul Twomey.

ICANN CEO Paul Twomey publicly stated his comfort with the Board Committee for Public Participation recommending to the Board deadlines for the future production of documents for international public meetings.

The issue of document deadlines was also raised by the Governmental Advisory Committee both during its meetings in Mexico City and formally in its communiqué.

The communiqué states: “In order to facilitate better GAC input to ICANN policy making, the GAC proposes that all documents to be considered at ICANN meetings, be posted not less than 15 working days before the meeting. In the event that this is not possible, the GAC may need to defer discussion until the subsequent meeting.”

In light of this community feedback, the Committee is recommending to the Board in this memorandum the introduction of two document deadlines for international public meetings. A 15-working-day deadline should stand for documents intended for GAC review and for final approval by any of the Advisory Committee or Supporting Organization councils, and a 10-working-day deadline for all other documents intending to be provided to the community.

The Committee checked on the definition and intent of “working days” with General Counsel and was informed that the wording referred to week days i.e. Monday to Friday, and that public holidays were not exempt i.e. they are counted as one of the working days.

Sydney and beyond

The system outlined above provides the following deadlines for the Sydney meeting:

• All documents: Monday 8 June 2009, 07:00 UTC
• GAC and final approval documents: Monday 1 June 2009, 07:00 UTC

As this process started only recently, it is expected that a significant number of documents will not meet the deadline set for Sydney. Requesting explanations for late documents, however, should serve to inform the community and staff about the Board’s intentions, and inform the Board about the processes behind the production of documents.

If adopted prior to Sydney, the deadlines should have a significant impact by the time of the Seoul meeting in October, and if successfully implemented and adopted, represent a norm for the meeting in Africa in March 2010.

The need to communicate with ACs and SOs

The Committee was advised by a number of Board members, staff members and members of the community that document deadlines will need to be clearly communicated to the Advisory Committees and Supporting Organizations.

Most of the work produced by ICANN staff for meetings is community-driven and in many cases progression on documents is reliant on review by one or several advisory committees or supporting organizations. As such, it will be crucial that deadlines be clearly communicated, and their implications fully understood, by the ACs and SOs before becoming effective across the organization.

It will be necessary in many cases for community members and staff to set a series of deadlines over a number of months in order to reach the main meeting document deadline.

Adequate time and consideration will therefore need to be given to ensure that the document deadlines are seen as a valuable assistance rather than being perceived as an unreasonable expectation or an attempt to rush community deliberations.

Exceptions, where warranted.

The Committee acknowledges that there will be occasional exceptions to these deadlines, particularly for the first few meetings after they are adopted. In some cases it is not possible to prepare documents in time, either because of the last-minute nature of the subject or because of unforeseen or unavoidable delays.

However, it is the Committee’s position that these should be exceptions that become increasingly rare over time. Furthermore, in order to understand the various factors that may contribute to late document publication, the Committee will be asking for a full explanation from the relevant staff member for each and every document that is produced late, starting at the Sydney meeting in June 2009.

Exception explanations should be provided to the Committee a minimum of five working days before the first Committee meeting that follows the relevant international public meeting (the Committee’s first meeting after Sydney is held on Tuesday 21 July, so all explanations should be provided to the Committee before Tuesday 14 July).

Going forward

The Committee recognizes that in the production of an operational policy, a wide range of issues need to be reviewed, because of the impact that document deadlines are liable to have.

As such, a small and incomplete list of questions are produced below for discussion:

• What does the deadline apply to? Every document? What about agendas and presentations?
• Is a single 15-working-day deadline the right approach and figure?
• What implications does a deadline have (less time for work between meeting, for example)?
• How do we deal with exceptions?

Language – Status Update

The issue of language, with respect to both the use of terminology and the provision of materials in languages other than English – is something that the Committee continues to review and work on.

With respect to the translation and interpretation provided by ICANN as an organization: the amount, timeliness and quality of both has increased significantly over the past two years and continues to improve. The organization now has a full-time Translations Manager, we are moving toward a multilingual website, and have introduced a new system for community-requested translations.

Additionally, we will soon have new translation software at the back-end and this may soon enable ICANN to give the community a way to directly input translations into our system. ICANN also provided the online Question Box – where any community member is able to ask the Board a specific question – in Arabic, Chinese, English, French, Spanish and Russian – for the Sydney meeting.

Nevertheless, the issue of translation remains a barrier to participation for a global audience and the Committee will continue to address how, organizationally, ICANN can improve.

Feedback from Mexico

• Attendees need to be able to speak and express themselves in different languages. (Note: Interpretation continues to be provided in all the main sessions and many of the smaller sessions when it is requested. We do note however that the use of headsets remains limited, raising questions about the level of demand for interpretation, and the costs involved.)

• Overuse of acronyms and lingo (Note: Since ICANN’s work typically concerns very specific issues with the domain name system, it is inevitable that a certain degree of lingo will be used. However to the extent that the use of such languages impedes effectives participation, the Committee will continue to examine ways to encourage communication in plain English.

• Translation expensive: so may only need translation of executive summaries. (Note: The Committee will shortly be addressing how best to provide executive summaries of all ICANN documents and the use of plain English as far as possible will be a key component of that process.)

Going forward:

• A new announcements process being developed will enable routine translation of announcements and public comment periods
• A multilingual front page – so people can find information in their language – is under development
• Increased translation. The Translations Manager has been very effective in reducing translation costs so that more translation is possible within the same budget. The translation budget will increase for FY2010; future increases will likely depend on evidence of community demand.
• ICANN is pioneering the use of interactive video transcripts in multiple languages so recordings of ICANN’s work (almost all of which is carried out in English) will be accessible to speakers of other languages.

Possible issues for discussion:

• A very high percentage of the ICANN community remains English-speaking: is this simply the reality of the work ICANN undertakes, or is use of language self-selecting participants?
• Does ICANN’s approach favor those from particular cultures? For example, the use of open microphones and email lists for raising and discussing issues.
• How does ICANN strike the balance between plain language and the fact that much of its work is quite technical in nature?

Calendar of Meetings – Status Update

In deciding on precise meeting dates for the future, ICANN gives careful consideration to international and religious holidays, as well as avoiding overlap with other large conferences, while allowing for adequate time between ICANN Meetings.

The dates for 2010 meetings have already been fixed and the Committee is reviewing the dates for 2011, 2012 and 2013. Staff prepared a calendar of other events occuring through those years in order to help guide and explain the dates put forward.

The Committee is publishing that document so the community has an opportunity to highlight any events or dates that may have been overlooked.

The recommended dates for the 2011-13 are given below:

2011

13-18 March
19-24 June
09-14 October

2012

11-16 March
24-29 June
14-19 October

2013

07-12 April
14-19 July
17-22 November

Possible issues for discussion:

• Have any important dates or holidays been missed that would require review of the above dates?

Public comment process – For discussion

The public comment process – where the community is invited to review and comment on all substantive work that ICANN produces – is a crucial element of the way the organization works and helps ensure both transparency and accountability in its processes.

Despite ongoing improvements to the public comments system – including the provision of a public comment page and summary/analyses of all comments to individual periods – overall it still remains far from optimal.

Staff are currently reviewing three new software solutions that would greatly improve the comment process, and the Committee will soon examine ways to provide executive summaries for most documents, but there remain issues with the public comment process that needs to be addressed by the whole community in order to make the process more effective.

The issues:

• Public comment overload.

ICANN as a whole is producing more comment periods than ever before, leading some to complain of overload and an inability to keep track.

The problem is particularly acute close to ICANN international public meetings. Last month (May 2009), no less than 12 comment periods were opened; in June, so far, there have been a further six. At any given time, an average of eight comment periods open for review.

Does the community believe this is the most effective way for ICANN to do its business while retaining openness and accountability? Are there alternative solutions?

Should there be prescribed spacing out of comment periods? Should comment periods be longer to give more time to respond? Are there some issues or documents that do not need to go through the formal comment system?

• Approach taken.

Currently, all public comment periods are announced on the front page of the ICANN site, and all open and recently closed comment periods are placed on a dedicated public comment page, linked to several times on the front page of ICANN’s main website.

Nevertheless, ICANN continues to receive, on average, under 20 comments per comment period. And if you discount the very large comment periods (Applicant Guidebook versions), there are, on average, just over seven comments per comment period.

Is this a sufficient response to publicly posted documents? Are people being made sufficiently aware of the comment process? Should there be required outreach to identified affected stakeholders?

Is it possible to effectively participate in a comment period? For example, do large documents posted with an email address for comments hinder effective participation? If so, what changes could be made? Would advance notice of comment periods have an impact? Would online polling of particular questions be effective or misleading?

• Feedback.

Every person sending in a comment receives receipt of that comment along with an explanation of ways in which to participate within ICANN’s processes. But, typically, there are no more targeted updates after that point.

Should respondents be kept up-to-date with progress of the particular area? How does ICANN show the impact of public comments on progress of an issue? Should there be required discussion of comment summaries when the topic is discussed next by the relevant group?

• Rules and procedures.

Those within the community know and expect that all revised versions of documents will be put out for public comment for, typically, 30 days. There are also a set of consultation principles that ICANN abides by (http://www.icann.org/en/accountability/frameworks-principles/community.htm#d ).

However, those are very few stated rules and procedures attached to comment periods. Should there be? For example, who may start a comment period, how it is formatted, which topics require public comment and which do not, how are late comments dealt with, and so on.

The Committee wants to review this crucial process to make sure it is meeting both the organization’s and the community’s needs.

Public Forum – For discussion

The public forum session typically held on Thursday at ICANN’s international public meetings is a crucial point of participation for the community. Anyone may put a question directly to the Board in the long open microphone session.

For Mexico City and for Sydney, there has also been the option to ask a question through an online Question Box – allowing for those that are not physically at the meeting or who prefer not to publicly address the whole room to have their say.

However, the Committee feels that the public forum is not fulfilling its desired purpose which is to act as a place where there can be open and active dialogue between the community and the Board.

The Committee will be recommending a number of changes in the format of the public forum in an experiment and in an effort to improve the session.

Those changes reflect closely what the Committee was told by the community itself at the Committee’s public meeting in Mexico City, namely:

• That the public forum is dominated each time by the same few individuals
• That the current format is not effective at encouraging discussion on particular topic but rather encourages a series of unrelated statements to be read out

The Committee has also recognized that:

• There is not enough two-way interaction between Board and community
• The opportunity for effective remote participation is not being used well
• The Board should be seen to be paying more attention to the room

Suggestions for change to public forum:

• Have the start of forum led by questions sent in remotely (and also, where possible, to give remote participants priority over those in the room)
• Have two microphones and two queues – one for new topics, one for comment on topic currently being discussed.
• Give precedence to those who have not asked a question in a public forum before
• Request that Board members engage more with the room and spend less time looking at their laptop screens

Other feedback from Mexico City:

• Use of colored cards may be useful (Note: The Committee remains uncertain whether this would be a useful system to introduce.)
• Announce issues to be discussed on website earlier (Note: The Committee wonder how effective this would actually be to pulling people into the forum.)

Excerpt from Committee working documents:

This memo represents the deliberations of the Committee with respect to the Public Forum held at the most recent ICANN meeting in Mexico City, as well as the previous international public meetings in Cairo and Paris.

1. Purpose

What is the public forum appropriate for and what is it not appropriate for?

Many hours are given over to the public forum/open microphone at each ICANN meeting and while its purpose is clear – to give the community a clear voice to raise questions or concerns – it is not clear that that purpose is being effectively realized with the current arrangements.

Too often, the public forum is not used as a forum to ask questions but rather as a way for individuals to make statements on the record. This greatly reduces the interactive nature of the forum and also consumes considerable time.

Also, the statements or views expressed are frequently the summation of views already expressed in a number of different fora during the previous days of the meeting.

There needs to be a trade-off between the one-way provision of (often repetitious) information to the Board and a more interactive two-way dialogue between Board and community. It may be worth exploring different avenues for the provision of official statements.

One suggestion is a second standing microphone which is used only for follow-up questions and statements on the particular topic currently being discussed.

2. Participants

It is notable that among approximately 1,200 attendees that the public forum/open microphone is dominated by a very small number of the same individuals at each meeting. The Committee would like to see broader and wider participation of the community during the public forum.

One suggestion put forward during the Board’s own session in Mexico City, and supported by some Committee members, is to reserve the start of the public forum for those that have not asked a question before in the public forum.

3. Remote Participation

The forum is an ideal venue for effective remote participation. However it needs to be recognized that effective remote participation can only be achieved if remote participants are given priority over those physically present.

The Committee wonders whether to recommend that the first hour of the public forum (or appropriate time period) is given over entirely to remote participants. It may be possible to take a number of questions provided by remote participants as the start point for further discussion within the room.

4. Board interaction

It is a consistent complaint that the Board does not interact sufficiently with the community during the public forum. In particular the sight of Board members on stage peering at open laptops rather than looking at the audience has been identified as a source of some consternation.

From the Board’s perspective there are two main issues in this respect. Firstly, much of the information is one-way – with Board members expected to listen to several hours of position statements. Secondly, during the public forum much of the flow of information – which is particularly high due to the session’s nature – is done electronically.

Despite that situation however, the Committee feels that all Board members on stage should demonstrate their attention to the debate during these public discussions. Glancing at the scribe feed on the screens in front of them is understandable, even advisable, but only modest attention should be paid to chat and email while the public forum is going on.

Electronic tools for participation – For discussion

Since ICANN is an Internet organization, it has always sought ways to use the Internet’s unique ability to communicate, to achieve effective participation.

Typically, such participation is carried out in two ways: firstly, through the provision and sharing of information on ICANN’s main website; and secondly, through remote participation tools while a physical meeting is going on.

The Committee is taking a particular interest in the use of electronic tools for remote participation, since it believes effective remote participation is essential to ICANN’s future and also represents significant future cost savings. As such, it recommended to the Board at its meeting in May that the organization take a more formal approach to determining what systems may be best suited to public participation in the context of ICANN.

The Committee’s Charter states that it should identify and encourage the development of effective tools, strategies, and methods for Public Participation activities, and it also agrees with the Chairman’s publicly stated view that ICANN should become a world leader in remote participation.

With this in mind, the Committee is working with staff to assess the suitability for use and best practices for remote participation tools, technologies and approaches in an effort to enable the community to enable greater participation (while also accounting for remote participation capabilities in developing countries).

Possible issues for discussion:

• What tools that ICANN currently uses are most effective, and which are least effective?
• Are there limits to what can be achieved through remote participation? If so, what are they?
• What type of tools does ICANN not currently use that might be useful?
• How can we foster participation from people in countries and regions with limited technical tools (access, connectivity, bandwidth, cost…)?
• What improvements could be made to existing systems?
• Will remote participation become more or less important over time?

Website usability study

ICANN’s website is the main entry point for the community to follow the work of the organization, but it remains far from optimal.

The Committee notes, and will follow with particular interest, a usability study that staff are carrying out with respect to the ICANN.org website where the community is being encouraged to provide its views on the website and where it can be adjusted or improved.

The Committee encourages all community members to fill in the online survey form opened prior to the Sydney meeting to gather information, and would like to discuss input into that process, the issues that people have with the current website.

Possible issues for discussion:

• What do people expect from the ICANN.org website?
• How easy is the navigation on the site?
• What features would be useful on the website?

This approach means for more effective remote participation plus increased participation from attendees who prefer not to address a room directly – something that I have consistently heard is an issue at ICANN meetings.

In total, 96 questions were asked and below ICANN staff has provided answers to each and every one.

We’re going to repeat the whole approach for Sydney but with two main changes. For one, I’m going to put a limit on the number of questions that people can ask. The idea of the question box is that it is an online version of the public forum i.e. you don’t have to physically stand up at the microphone.

However, it is very rare that anyone gets to ask more than two questions during a public forum, and so I think it makes sense to apply the same logic to the online version. Looking at the use of the question box this time around, all but 4 of the 36 commenters asked two questions or less.

There were also a small number of people that felt the 30-word limit on the question was a little too restrictive. And so we’ll increase it to 50 words, which should give plenty of room to comment and question.

Anyway, posted below, as well as on the Mexico City website and the main ICANN website are the responses to the 96 questions. Enjoy. And feel free to comment on the process or any of the questions below.

Kieren McCarthy
General manager of public participation, ICANN

Response and Summary

Mexico City online Question Box, March 2009

Questions are split up according to topic:

• ICANN as an organization (26)
• Registrars / RAA (23)
• Applicant Guidebook / New gTLDs (19)
• Public Participation (6)
• IDNs / Fast Track (6)
• Accountability and Transparency (2)
• Others (14)

ICANN as an organization

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Michael Berkens, Worldwide Media, Inc.

Asked by: Josh Broland, Skenzo

Asked by: Max Menius, Menius Enterprises, Inc. (USA)

Asked by: Karlene Francis, Ministry of Mining and Telecommunications, Jamaica

Registrars / RAA

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Steve Barclay, individual

Asked by: W Kelley, individual

Asked by: Not Amused, individual

Asked by: Alfredo Fregoso, individual

Asked by: Scott Reed, individual

Asked by: David Filiatrault, individual

Asked by: Jaime Echeverry, Dinahosting S.L.

Asked by: Jaime Echeverry, Dinahosting S.L.

Asked by: Raul Rodriguez, individual

Asked by: Eduardo Rodriguez, Private organization

Applicant Guidebook / New gTLDs

Asked by: Chantal Lebrument, Eurolinc

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Danny Younger, Registrants

Asked by: Lori Hament, individual

Asked by: Jaime Echeverry, individual

Asked by: Raymond Marshall, NuMedia Concepts, LLC

Asked by: Raymond Marshall, NuMedia Concepts, LLC

Asked by: David Castello, CCIN.com

Asked by: Artsiom Vapniarski, individual

Asked by: Raymond Marshall, NuMedia Concepts, LLC

Asked by: Nikolay Pavlov, individual

Asked by: Ksenia Golovina, Brights Consulting Inc.

Asked by: Robin Gross, Non-Commercial Users Constituency

Asked by: Raymond Marshall, NuMedia Concepts, LLC

Asked by: Arlene Paredes, Netpia.Com, Inc.

Asked by: Lebrument Chantal, Eurolinc

Asked by: Daniel Millbank, individual

Public participation

Asked by: George Kirikos, individual

Asked by: Raymond Marshall, NuMedia Concepts, LLC

Asked by: Danny Younger, registrants

Asked by: Steve Crean, individual

Asked by: Karlene Francis, Ministry of Mining and Telecommunications

Asked by: Karlene Francis, Ministry of Mining and Telecommunications

IDNs / Fast Track

Asked by: Danny Younger, registrants

Asked by: liana Ye, Y&D Infor. Sys. Group

Asked by: Raymond Marshall, NuMedia Concepts, LLC

Asked by: Petko Hristov, individual

Asked by: Kristian Hristov, individual

Asked by: Nikolay Filipov, individual

Accountability and transparency

Asked by: Edward Hasbrouck, individual

Asked by: Edward Hasbrouck, individual

Others

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: George Kirikos, Leap of Faith Financial Services Inc.

Asked by: Danny Younger, registrants

Asked by: Michael Berkens, Worldwide Media, Inc.

Asked by: Danny Aerts, ccNSO member

Asked by: Ivonne Muñoz, individual

Asked by: Falk von Bornstaedt, Deutsche Telekom

Asked by: Juan Yanez Carrera, Tyloon.com Multilingual Search Engine

Asked by: Rafik Dammak, individual

RESPONDENTS

All those who asked questions are listed below, by number of comments (in parentheses) and then alphabetically:

• Danny Younger, registrants (41)
• George Kirikos, Leap of Faith Financial Services Inc. (10)
• Raymond Marshall, NuMedia Concepts, LLC (6)
• Karlene Francis, Ministry of Mining and Telecommunications (3)
• Michael Berkens, Worldwide Media, Inc. (2)
• Lebrument Chantal, Eurolinc (2)
• Jaime Echeverry, Dinahosting S.L. (2)
• Edward Hasbrouck, individual (2)
• Danny Aerts, ccNSO member (1)
• Not Amused (1)
• Steve Barclay, individual (1)
• Josh Broland, Skenzo (1)
• David Castello, CCIN.com (1)
• Steve Crean, individual (1)
• Rafik Dammak, individual (1)
• David Filiatrault, individual (1)
• Nikolay Filipov, individual (1)
• Alfredo Fregoso, individual (1)
• Ksenia Golovina, Brights Consulting Inc (1)
• Robin Gross, Non-Commercial Users Constituency (1)
• Lori Hament, individual (1)
• Kristian Hristov, individual (1)
• Petko Hristov, individual (1)
• W Kelly, individual (1)
• Max Menius, Menius Enterprises, Inc (1)
• Daniel Millbank, individual (1)
• Ivonne Muñoz, individual (1)
• Arlene Paredes, Netpia.Com Inc (1)
• Nikolay Pavlov, individual (1)
• Scott Reed, individual (1)
• Raul Rodriguez, individual (1)
• Eduardo Rodriguez, private organization (1)
• Artsiom Vapniarski, individual (1)
• Falk von Bornstaedt, Deutsche Telekom (1)
• Juan Yanez Carrera, Tyloon.com Multilingual Search Engine (1)
• Iiana Ye, Y&D Infor. Sys. Group (1)

The box should appear below (you may have to click on “[read the rest]“). If you have trouble viewing the box, you can access it directly on the web using this URL: http://icann.wufoo.com/forms/mexico-city-question-box/.

If people are really keen, I can explain why that came about, but perhaps more importantly, we have ensured that there is plenty of time available at the Mexico City meeting next month for “public forum”.

In fact, there is four-and-a-half hours dedicated forum time: 90 minutes on the Monday solely covering the Applicant Guidebook; 30 minutes at the end of the Joint ACSO meeting; and two-and-a-half hours open-mic time on the Thursday.

Click here to visit our new online Question Box for Mexico City

Just to be clear: this is more open-mic time than at any ICANN meeting since Vancouver in 2005, and that meeting was marked out as being where both the dotcom contract and the .xxx application were discussed. We are also starting to separate out the delivery of reports (AC/SO chairs, staff and Board Committees) from “public forum” time, meaning open microphone time. That means that open microphone time is not dependent on anything else and stands alone as dedicated time.

Aside from the time issue, the other big concern the community has had is the ability to ask questions. Not everyone likes queuing up behind the public microphone and having to wait their turn to address an entire room of people.

Equally, the public forum has always been the most contentious meeting in terms of remote participation. In my role as general manager of public participation, I introduced and have followed chatrooms for the public forum in every meeting since Lisbon (March 2007), reading out questions and comments directly into the microphone.

This approach works, but not that well: chatrooms do not lend themselves very well to asking questions. So, in order to make things much easier for the community, there is now a very simple online question box.

Go to the Question Box

You type in your name, affiliation and email address. You give the broad area that the question is covering. You type in your question and then hit “Ask Your Question” and it is then in the system and we will make sure you receive an answer either in the forum itself, or in a response that we will produce in the weeks following the meeting (the hope of course is that everything will be answered on the day).

I hope that this online question box is self-explanatory, but it case you have any questions or queries, that is why this blog post exists – to enable you to raise them where others can see them, and to allow for responses to those queries to be easily found.

So, in summary – please use this question-box system. It is only as good as the use made of it. And I hope it will make for more enjoyable, informative and interesting public forum sessions in Mexico City.

You can visit the Question Box by clicking here.

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.