Response and summary to the Cairo public forum

by Kieren McCarthy on December 15, 2008

This is a Response and Summary to the Cairo public forum that took place on 6 November 2008.

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

 

QUESTIONS

 

SUGGESTIONS

 

RESPONDENTS



This report has been produced in order to act as both a response to, and a summary of, the public forum at ICANN’s 33rd International public meeting in Cairo.

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.


We urge the ICANN Board to not delay new gTLD application process in order to make changes to the Guidebook (SK, PS, DK, SR, RA, MB, JB, AM, IA, TH)*.

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.


The $185,000 application fee outlined in the Applicant Guidebook is too high (SR, DY, RA, IA)*. Particularly with regard to transliteration i.e. paying the same fee over again for an approved TLD in a different language (RA)*.

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.


The scoring in Module 4.3 is too high and doesn’t account for human fallibility (RA)*.

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.


The current approach taken where every string is seen an independent from any other may cause problems (RA, WT)*. It could create unnecessary fights and problems (RA)*; it doesn’t full account for the realities of other scripts (WT)*.

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.


The four-month awareness campaign for new gTLDs should be brought in earlier so application process can begin earlier (RA)*.

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.


Uncertainly over whether the International Chamber of Commerce is the best place for dispute resolution on questions of morality and related issues (AM, YS)*.

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.


SUBJECT AREA: IDNs and IDN ccTLDs

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.


The three-letter rule for new gTLDs does not work in some scripts where one character can represent an entity (WT)*

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.


SUBJECT AREA: Policy

ICANN’s policy processes do not contain sufficient research and are too based on opinion (MC)*

ICANN Staff response: The concern expressed in this comment is one collectively shared by the community and ICANN Staff. As recently recognized by the Board in the context of the GNSO Review Process, the Bylaws mandated Policy Development Process (PDP) needs to be revised to make it more effective and responsive to ICANN’s policy development needs. It should be brought in-line with the time and effort actually required to develop policy, and made consistent with ICANN’s existing contracts (including, but not limited to, clarifying the appropriate scope of GNSO “consensus policy” development).

The GNSO Council and Staff are currently working to develop new PDP rules for the Board’s consideration and approval that contain more flexibility. The Board has recommended that the new rules should emphasize the importance of the preparation that must be done before launch of a working group or other activity, such as public discussion, fact-finding, and expert research in order to define properly the scope, objective and schedule for a specific policy development goal, and the development of metrics for measuring success. The commenter is a volunteer who is participating in that process.

At the same time, the comment is germane to other policy activities that take place outside the context of the PDP process. It is hoped and expected that the GNSO efforts will provide insights and guidance that will improve those processes as well.


SUBJECT AREA: IPv6

There is no clear consensus about what should be done re: transition to IPv6 (OC)*

ICANN Staff response: We would agree that there is no clear consensus about what should be done regarding transition from IPv4 to IPv6, and it is something that both Staff and community members have been working on for some time. It should be recognized however that ICANN has no direct influence over the network operator community where this is such a key issue.

The problem, as you are probably aware, is that the subject itself is multi-faceted and complex. There is not going to be a single approach or solution that will work, rather a series of parallel and intersecting approaches. IPv6 deployment will be done alongside existing IPv4 networks, so a large issue that is still being resolved is how the two network protocols can work together at the same time to preserve the global, interoperable Internet we experience today.

The problem is also complicated by the fact that the transition issue does not clearly fall under any standard development organization’s remit. Network operators – those who must implement IPv6 – make decisions based on what will improve their companies and their networks. Changes to their network services are often developed when their users request the new service. Any regulations that apply to them are usually developed at the governmental level, not through direct community input.

Certainly the IETF, the RIRs, and local operator groups have done a lot work in this area but that work needs to be picked up and expanded upon by a huge range of other organizations from network operator groups, to businesses and political establishments in order for the IPv6 transition to be effective.

The Regional Internet Registries (RIRs) have been promoting the issue and encouraging adoption of IPv6 through policy and discussion. At the same time, bodies as diverse as the OECD and ITU have also reviewed particular aspects of the transition. Some governments have taken the initiative to offer incentives for IPv6 deployment, and some enterprise users are beginning to request IPv6 services. Many service providers now recognize that the path to continued growth requires the transition to an IPv6-supporting network.

On ICANN’s part, the Board resolved last year to do what it could to work with other bodies to promote and educate about the IPv6 transition issue. One of the challenges that ICANN faces is that its efforts to assist with IPv6 transition discussions often causes public concerns to be raised that the organization is stretching beyond its limited technical remit.

We believe however that through the many conversations had over the past year in a wide range of different fora and with a wide range of different organizations, that a consensual working approach is gradually being discovered that will see the issue given its due prominence.

One commitment ICANN itself has made has been to act as a leader in making its services available through IPv6. This project is well underway and will be continued as new services are brought online.

There is, of course, some way to go and ICANN Staff appreciate the urgency of the situation being reiterated by community members.


SUBJECT AREA: Board review

ICANN should set CEO term limits (MP)*

ICANN Staff response: Thank you for this response and please also provide it directly to the Working Group that is managing the Board review.

We should note with respect to this specific suggestion, however, that the Chairman rejected the suggestion at the Cairo public forum, as well as a very similar one in the previous public forum in Paris.

The Chairman’s firmly stated view is that it is for the Board to decide on the CEO’s employment status and that this is consistent with industry best practice.

As such term limits on the CEO of the organization is a suggestion that is unlikely to be adopted in the Board review unless there is significant community feeling that such a departure from corporate norms would benefit the organization.


Agreement with the suggestion that Board members should be compensated (JZ)*

ICANN Staff response: Thank you for this response, it is duly noted. But please also supply it directly to the Working Group that is managing the Board review.


SUBJECT AREA: ICANN meetings

Please take travel time into consideration when deciding on meeting locations (DC, LY)*

ICANN Staff response: The issue of accessibility to particular venues, cities and countries is indeed already one of the many factors taken into account when deciding the location of an ICANN meeting.

One of the reasons behind the fact that ICANN rotates its three annual meetings around the globe is to ensure that at least once every two years the global community will not have to travel too far to attend (as the meeting will be held in each of the five geographic regions).

However it should be noted that ICANN has twice reviewed this approach in the past two years (in a paper from the Board Meetings Committee and in an ICANN Staff paper) due to changed circumstances.

The two main suggested changes in both of these papers were that ICANN reduce the number of meetings it holds per year from three to two, and that one of those meetings is held in a “hub” location to make travel easier for attendees.

It is increasingly likely that ICANN will at some point have to change its approach to meetings. However, such is the significance of physical meetings to the organization’s functioning, as well as the wide diversity of views on them, that it has so far been difficult to forge a consensus over changes, leading to a continuation in the status quo.

Thank you for contributing to this ongoing discussion.


Please uphold transparency and regional diversity when it comes to deciding on meeting locations (JS)*

ICANN Staff response: The issue of regional diversity has been answered above and was also answered by the Chairman in the public forum itself. Just to reiterate: ICANN rotates its three annual meetings between the five geographic regions. You can see this rotation from the full list of historic and future meetings on ICANN’s website here: http://public.icann.org/meetingarchives.

Over the past ten years and 33 meetings, the five regions have been represented in subsequent meetings, with three exceptions: Los Angeles in November 2007 (an Asia meeting in Delhi was held immediately after in February 2008); Amsterdam in December 2002 (a Latin American meeting was held in Rio de Janeiro immediately after in March 2003) and Melbourne in March 2001. A further exception may happen in October 2009 where a Europe meeting is postponed until after an Asia meeting.

With regard to transparency, ICANN has traditionally kept all bids for international public meetings confidential. This is mostly because many bids contain sensitive material with regard to venues, hotels, pricing and endorsements and so on. It is also an approach that a number of local hosts have valued over the years.

There is currently no review of whether the bids, or parts of the bids, can or should be made public. It was nevertheless clear from the public Board discussion at the public forum in Cairo that the process by which the location of meetings is decided needs refining.

Since the Board ultimately has to approve the budget of each ICANN international public meeting, this issue of greater transparency is one that rests with them.


SUBJECT AREA: General

It is an uphill struggle with the International Telecommunications Union (ITU) to get them to recognize civil society (AI)*

ICANN Staff response: While it is hardly ICANN’s position to reflect on the policies of other international organizations, we would note that our multi-stakeholder approach – where all those affected by changes in the Internet space are given full participation rights – is precisely what we believe makes ICANN and the ICANN model most suited to the task of assigning names and numbers that it has been given.

We would hope that the community continues to recognize that fact and to support both ICANN and the ICANN model where appropriate.

If the community wishes the ITU to recognize civil society, it should raise that directly with the ITU.


Country code registry managers are urged to listen to their individual Net users (AI)*

ICANN Staff response: This is certainly something that the ccNSO – the supporting organization within ICANN that represents country code registry managers – takes seriously. In principle, the ccTLD managers have their own organizational structures to ensure that the voices of users are heard (again, a symbiotic multi-stakeholder approach that proves extremely effective when dealing with Internet issues).

However, if you feel this interaction can be improved with subsequent benefit to the country code registry owners, then you should seek to persuade those within the territory the particular ccTLD serves over what practical changes can be made.

Additionally, the At Large Advisory Committee (ALAC), which represents ordinary Internet users, may be interested in hearing concerns over individual users being listened to when it comes to Internet policies.

Both of these organizations hold open meetings with question-and-answer sessions during ICANN international public meetings specifically in order to allow people to raise such concerns.


There is a lot of mistrust and suspicion at ICANN meetings, the community needs to work together more (R1)*

ICANN Staff response: Just as the attendees to ICANN meetings are broad and diverse, so are the range of behaviors and emotions that can be found at any ICANN meeting.

The ICANN model was designed to allow for the engagement of all stakeholders and as a result it is always going to be noisy. This is only to be expected when different groups of people, representing different and often opposing interests from different cultures, speaking different languages, come together in an effort to find a way forward.

However, the mistrust and suspicion referred to is only one part of a much larger picture. Those that have been to ICANN meetings over a number of years will note that alliances are constantly forged and broken as different and rapidly changing topics enter into discussions and efforts are made to arrive at consensus positions across all groups.

Alongside the negative emotions and tensions also come positive equivalents and it is ultimately these that drive the ICANN model. As the model has matured, the degree of interaction between groups has noticeably increased (as made clear by the number of joint sessions now carried out each meeting) and this in turn has increased trust and the willingness to work together across the organization.


The organization needs to have more international staff, particularly in Asia (YL)*

ICANN Staff response: The statistics presented in the public forum were not accurate, but the point was that ICANN has an over-abundance of English-speaking staff, particularly from the United States, and it needs to hire more people from different regions.

Today, ICANN has about 100 staff. Its largest office is in Los Angeles in the United States and there are hub offices in Brussels, Washington DC and Sydney, though they are today small in comparison to the Los Angeles office (these offices are newer, and with fewer support functions). Generally, the Los Angeles office houses most of the IANA function, business support functions (Information Technology, Human Resources, and Finance) and most of the staff dealing with registries and registrars. So far this year, more than half of ICANN’s hiring has been outside of its Los Angeles hub.

Looking at the staff that actually deal directly with the community, the geographic spread is much broader. The Global Partnerships team – which deals with the community in different regions of the world – contains individuals from those regions exclusively. Likewise the Policy team is highly international.

With the Asia region representing a significant area of the world’s population and Internet growth, we recognize that it is essential for ICANN to have additional regional representation in Asia. There are already several staff openings specifically for this region and several are anticipated in the next fiscal year.

A global diversity of views is essential for ICANN’s success, however the organization’s staff isn’t big enough to accomplish this by hiring from all parts of the world. Broad outreach, diverse meetings, multiple language consultation, and other mechanisms provide a background for good decision making in our diverse community. Still, finding opportunities to broaden ICANN’s staff diversity is one welcome way to incorporate these diverse views.


The organization should stay out of operational issues i.e. running .int and .arpa registries, and a root server (MP)*

ICANN Staff response: Clearly, this is not a simple question of ICANN performing operations functions or not, but a matter of degree.

Some of the operational elements that ICANN is involved in relate directly to the IANA contract. The IAB has directly entrusted the operations of .arpa and other infrastructure zones to the IANA function. Elements such as providing a top-level Whois service are also part of the IANA function. And ICANN has made a proposal to compile and sign the root zone. These functions are operational, and considered to be part of ICANN’s core mission.

Traditionally, IANA has also had responsibility for other operational elements (including .int), and ICANN took responsibility for operating the L Root some years ago.

There are also technical and community benefits in ICANN performing these operational functions. For example, Staff are able to run a double-check that changes made to the root zone through the IANA process appear correctly by consulting the L Root. By running such infrastructural elements as registries and a root server, Staff are also brought into regular contact with other operators at an operational level.

That said, it is always a fair strategic question to consider the extent of the organization’s operational activities. Board members regularly consider the extent to which ICANN should be performing operational functions, and this question should be an ongoing consideration in ICANN’s strategic planning process.


Concern about top-level domains for a single user i.e. .companyname. Responsibility to a community is the appropriate consideration for a TLD – not right or ownership (WS)*.

ICANN Staff response: Staff is working to implement the consensus opinion of the community as arrived at through ICANN’s policy making processes. In this case, the philosophical approach to top-level domains suggested was not reflected in the policy decisions made by the overall community.

If the concern is that ICANN’s policy processes appear to be more business focused than when the Internet was originally built and conceived by engineers, that is a simple reflection of the Internet as it is today.

It should be noted however that the Applicant Guidebook clearly and explicitly recognizes the value of community-led top-level domains to the extent that two types of application are specifically planned for: open and community.


There needs to be more representation of different groups in the GNSO e.g. families, consumers, victims of cybercrime (CP)*

ICANN Staff response: The ICANN model offers opportunities for all stakeholders to play a part in its processes, and the GNSO is a prime example of that effort. As the organization continues to implement the GNSO Improvements recommendations approved by the ICANN Board in June 2009, there are more opportunities for new constituencies to be formed to serve the interests of various interest groups.

As the sponsor of the potential new constituency, the commenter knows that the Staff is available and interested in providing assistance and support to groups of stakeholders who express an interest in forming a new constituency.

Individuals or groups who are interested in learning about the opportunity to form a new constituency should consult the GNSO Improvements Information web site at http://gnso.icann.org/en/improvements/.


You should make public comment a greater priority at ICANN meetings (AM)*

ICANN Staff response: We believe that public comment is already given a very high priority at ICANN meetings. There are always two public comment sessions: one at the start of the week, and one at the end, with the entire ICANN Board in attendance and addressed directly.

On top of that, every general session has, as a default, a question and answer element. Most supporting organization and advisory committees hold open question-and-answer sessions. And organizationally, ICANN puts out every piece of substantive work to public comment. Many sessions at ICANN meetings exist solely to elicit feedback from the community on particular papers.

What this comment most likely refers to is the limited time that existed for a public forum in Cairo. To be clear: the introduction of two guests speakers into the Thursday schedule greatly reduced the time normally available for public forum.

In response to this shortage of time, and having noted the long line of people queuing up to raise points, the Chairman adjusted the afternoon schedule, reducing an hour-and-a-half session to just half-an-hour in order to recover the time lost.

That said, ICANN Staff recognize that the situation caused significant disquiet among the community and in response will block out a time slot at future meetings for the public forum, as well as write in sufficient time buffers both before and after the session in order to ensure the situation does not occur again in future.


Can ICANN encourage more mechanisms to increase the geographic mix of participants at ICANN meetings (YL)*

ICANN Staff response: This query has been partially answered above with regard to the way ICANN moves its meetings around the five different regions of the globe, and the Chairman also explained this approach at the public forum itself.

But there are other ways in which ICANN tries to increase the geographic mix at meetings. There is the fellowship program where between 20 and 30 individuals have their costs to attend a meeting covered by ICANN each meeting. And there is the Global Partnerships team who works to improve global engagement as well as work directly with the regions.

There is a large translation program that hopes to involve more non-English speakers in ICANN’s processes online. And interpretation is provided for a large number of sessions during an ICANN meeting, including all those in the main room.
As it is, ICANN meetings are pretty diverse affairs already: a total of 3,420 people attended the 2008 meetings. In New Delhi, there were 720 attendees representing 76 countries; in Paris, 1,672 attendees representing 166 different countries; and in Cairo, 1,028 attendees representing 144 different countries. The top five countries by citizenship represented at the Paris meeting were USA, France, Germany, United Kingdom and Spain; and at Cairo, USA, Egypt, United Kingdom, Germany, and France.

However we do recognize that we can do more and a newly created Board Committee on Public Participation is likely to look at this very point and try to devise more ways to encourage more people from different countries to attend. The Global Partnerships team also continues to look at greater opportunities for remote participation and engagement from their respective regions.

If community members have ideas or suggestions, please do email them to participate@icann.org.


Thanks to ICANN Staff on: the clear wording of the Guidebook (RA, AP, AVC, MB, TH)*; its transparency and outreach work (AM, JS, SK)*.

ICANN Staff response: We thank those who thanked us. As many in the community will appreciate, not only was creating the guidebook an enormous challenge but then producing it in clear, simple language was something that we worked very hard on. It is very satisfying to have that hard work noticed and appreciated.

With regard to transparency and outreach, this stems largely from an increasingly systemic approach to the way that ICANN approaches its work. We have introduced systems that cause those deeply involved in a particular issue to reflect on whether the community is being informed about progress at various points. At the same time, we have started to develop working methods that provide information as a default, rather than require a request for information.

Again, it is satisfying to see this work noticed and appreciated by the community that we seek to serve.


QUESTIONS


SUBJECT AREA: Applicant Guidebook

Who are the panelists that decide on applications? Will they understand business issues of applications? (AVC)*

ICANN Staff response: We will have an open process for deciding panelists that will be outlined in due course. Only potential evaluators who have requisite experience and skill to fully understand the requirements will be retained. The approval criteria will not be applied so that fine judgments act as the difference between an application being approved and turned down.


Will IDNs and gTLDs be available at the same time? (R2, AM)*

ICANN Staff response: Staff is working as fast as possible to get both processes implemented and currently it looks like they will go live at the same time.

However, should one of the processes be delayed then this will not slow down the launch of the other process, as was suggested in earlier comments. As of today there is no specific launch date for either process.

The situation is complicated by the work being done by the IETF on an IDNA protocol standard. We sincerely hope that the IDNA protocol will be finished in time for the rollout of gTLD applications (which will include IDNs) but we are preparing to go ahead without the protocol being finalized.

If you are confused about the introduction of IDNs through the so-called Fast Track and how that relates to the new gTLD process, please see an earlier answer above for more context.


How much will the refunds be and in what cases will refunds happen? (AP)*

ICANN Staff response: The issue of refunds is still being reviewed – and so we would welcome community feedback on it. However, current thinking points to a percentage refund based on how far an application proceeds through the stages outlined in the guidebook.

There are three obvious points in which an application may be halted as part of the review process and current thinking is that a diminishing percentange of the application fee based on which stage an application has reached would be the fairest way to proceed. That approach is tentative at this change however and we welcome and encourage community feedback on the issue. You can email your comments on this issue directly to: gtld-intro@icann.org.


SUBJECT AREA: Improving Institutional Confidence

How can ICANN get over the legal obligation it has that it cannot trade with states identified by the US government? (YS)*

ICANN Staff response: This question was partially answered by Board member Jean-Jacques Subrenat in the public forum itself. Mr Subrenat is also a member of the President’s Strategy Committee (PSC), a committee that has been wrestling with this question as part of the Improving Institutional Confidence consultation.

As the consultation has progressed, the idea of creating a second legal presence for ICANN has grown in stature in order to help deal with a number of issues that ICANN faces as it internationalizes.

A paper outlining various legal presence possibilities, as well as what issues such a presence would help ICANN deal more effectively with and what, if any, impact that would have on the current ICANN structure, will be released in the coming months for community review and consideration.


SUGGESTIONS

If a new registry makes under $1million it should be waived the annual fees under the Applicant Guidebook (MF)*

ICANN Staff response: Thank you for the suggestion. As you can see in an answer above, the issues of the registry fees was one raised by a number of people and we have asked for facts, figures and suggestions from the community in order to navigate a way forward.

The idea of waiving fees under certain circumstances is certainly something that will be looked into. Any real-world or projected figures that the community is willing to share with ICANN Staff – confidentially if needs be – in order to help us make such determinations is greatly appreciated.

Please email gtld-intro@icann.org on this topic.


Allow non-profits to pay a percentage of the annual registry fee for the first two years of running a new gTLD (TH)*.

ICANN Staff response: A second suggestion for dealing with an annual registry fee that some said was too high. The Chairman responded to this suggestion directly during the public forum, stating that he expects the Board to review the idea of flexible financing for gTLD applications. This suggestion will also be reviewed as the Applicant Guidebook is revised in light of public comments.

Again, we would encourage the community to provide more information – facts and figures – in support (or against) this suggestion in order to help ICANN Staff arrive at a well-informed solution.


Create a special cross-constituency working group to identify what ICANN could do to promote IPv6 update (OC)*

ICANN Staff response: This is potentially a useful idea as ICANN as an organization can bring together many different stakeholder groups to identify the different sectors that need to participate in order to bring about large-scale IPv6 use. It should be kept in mind though that ICANN has no remit regarding the operational community that must drive implementation and uptake of IPv6 (see also the reflections on this issue above).

In terms of making such a group a reality, a cross-constituency working group is something that would need to come from the community. If such a working group is seen as important to ICANN as a whole and there are sufficient members that either self-organize or encourage the Board, or one of the SO/AC Councils, to call for a group’s creation, then Staff will do what it can to support and guide it.


Lower the scoring in Module 4.2.3 of the Applicant Guidebook from 11 out of 12 to 10 out of 12 (RA)*

ICANN Staff response: Please refer the answer given above on this issue.


Move Guidebook awareness campaign forward to January 2009 (RA)*

ICANN Staff response: Please refer the answer given above on this issue.


Fund an outreach effort to reach groups such as families, consumers, victims of cybercrime to encourage them to form new constituencies in GNSO (CP)*

ICANN Staff response: Please refer the answer given above on this issue. It is also something that the new Board Committee on Public Participation may have an interest in addressing.


Fix more time for public comment into the meeting schedule (AM)*

ICANN Staff response: Please refer the answer given above on this issue. Short answer: we agree and it is already done.


Introduce metrics for ICANN Staff performance (JZ)*

ICANN Staff response: As you noted during the public forum, ICANN has introduced a series of new metrics to inform the community about the work it is doing (click on the “dashboard” button on ICANN’s front page). We can reveal that there are many more in the pipeline that cover different aspects of ICANN’s work.

It can be expected that many of the new metrics will give an indication of the work that ICANN Staff are performing, and hence the level of performance. If after those metrics have been compiled and released (to do so requires consistent and reliable mechanisms for gathering the data periodicially), the community feels that there is a need for more metrics in order to help it assess how ICANN is performing, we will look at introducing them.


RESPONDENTS

All those who raised points in the public forum are listed alphabetically below and represented by their initials in the text above (in parathenses after the relevant comment):

AI – Aizu Izumi, outgoing ALAC representative
AM – Annette Muehlberg, individual
AMa – Andrew Mack, individual
AP – Arlene Paredes, Netpia (Korean registrar)
AVC – Anthony Van Couvering, .nyc
CP – Cheryl Preston, CP80.org and Brigham Young University
DC – David Cheung
DK – Dirk Krischenowski, dotBerlin
DY – Danny Younger
IA – Iratxe Esnaola Arribilloga, dot eus
JB – Jordyn Buchanan, individual
JS – Dr Jae-Chul Sir, NIDA
JZ – Jonathan Zuck, Association for Competitive Technology
LY – Lento Yip, individual
MC – Mason Cole, Oversee.net
MB – Mickey Beyer-Clausen, Pervasive Media
MF – Marcus Faure, CORE
MP – Mike Palage
NQ – Nii Quaynor, AfriNOG
OC – Olivier Crepin-Leblond, individual
PS – Paul Stahura, eNom
R1 – Respondent 1, .ng
R2 – Respondent 2, unknown affiliation
RA – Ron Andruff, individual
SK- Stephen Kelly, Far Further
SR – Susan Reynolds, dot gal
TH – Tony Harris, Latin American Federation of the Internet
WS – Werner Staub, individual
WT – William Tan, individual
YL – Young Eum Lee, .kr
YS – Yassin El Shazly, ICANN fellow

{ 0 comments… add one now }

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*
To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image