The voting procedure needed 60 percent of both of the new houses – contracted and non-contracted – to vote in favour. A first round vote with Chuck Gomes and Olga Cavalli saw Chuck Gomes win 100 percent of the contracted house vote and 50 percent of the non-contracted house; a second round with just Chuck on the ballot saw him win all but one Council votes.

Chuck will be helped by not one but two new vice-chairs under the new system: Olga Cavalli (interim) and Stephane van Gelder. Chuck mentioned in his acceptance speech that he intends to follow the same pattern that he himself had as vice-chair, where they are included in all decisions.

So congratulations new GNSO chair Chuck Gomes and congratulations to the new Council, which has been formed after years of hard work balancing the various stakeholders’ interests.

Outgoing chair Avri Doria was given a standing ovation on standing down and we captured the moment:

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

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

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

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

So what are the criteria we use today?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As such, the term “variant” designates orthographic equivalence on the character level, such as that between “æ” and “ae” in “encyclopædia” and “encyclopaedia”, but not in the broader sense that pertains to the variant spelling of words, as “encyclopaedia” vs. “encyclopedia” or “color” vs. “colour”. The IDN Tables that define variant characters are useful because they enable TLD registries to develop registration policies that will reduce the potential for confusion that could result from typographic similarities in domain names.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ICANN is a public benefit not-for-profit company and we recognize that you, as a community, need to be kept informed about our finances so that we remain accountable.

So here is a rundown of what we have produced with respect to finances. The hope is that you can follow the budget process all the way through from the strategic planning to the draft budget stage and through to seeing where the money comes from and where it goes to.

You should also, by the time you reach the end of this post, know how and when you can provide input into that process and so directly influence the budgeting process.

The dashboard

First up, because it has simple graphics and because it is constantly updated is the dashboard. The dashboard is a compilation of a wide range of data across the organization designed to be easy to review by the community. There is a big button on the front page on the left-hand column that links directly to it, otherwise you can find it at: http://www.icann.org/idashboard/public/

As you enter the dashboard, the opening page is our unaudited financial information. Here you can see the year-to-date expenditure of the organization, alongside what we have budgeted. You can also see where the money comes from plus what we have budgeted for. This year we will be showing more detailed functional budgets as the expenditures to date for each organizational activity.

General info

Next up is the part of the website in which we keep financial information for ICANN. You can find by clicking Documents and then Financial Information, or just click here: http://www.icann.org/en/general/financial.html

There are three sections of financial information. One section is for general financial information, one for the current fiscal year, including the budget, and the last section is for historical financial information on ICANN, that goes back each year to ICANN’s inception.

Under “general financial information” you can find general financial policies such as ICANN’s disbursement policy, the ICANN Investment Policy, Travel Support Guidelines, tax exempt status documents, and so on.

The next section is for current year financial information. It includes the current year’s adopted operating plan and budget, the IRS tax form 990, payments made to directors, travel support reports, and audited financial statements.

The last section is for historical information. It contains the same types of information as the current year.

Operating Plan and Budget

It is worth noting here that every year, the operating plan and budget that we produce is put out to public comment. We also always run public sessions at ICANN meetings where members of the community are allowed to ask questions and raise queries about any aspect of either the plan or the budget.

For example, the most recent public comment period for the FY2010 budget – which has since been approved – can be found here: http://www.icann.org/en/public-comment/public-comment-200906.html#draft-opplan-budget.

Comment periods

A number of people commented – as you can see by clicking on “comments”. And a summary of those public comments is posted to the same list and is available here: http://forum.icann.org/lists/op-budget-fy2010/msg00021.html. That summary is then used to make changes to the budget.

So the budget for the financial year we have just stepped into has been finalized, but what about next year FY11 for the financial year from 1 July 2010 to 30 June 2011?

Strategic Plan

Well, we are just about to start on our strategic planning sessions – where the community itself gets to decide what the priorities are for the organization and so where it should spend it money.

This process will kick off soon – it will be announced on the front page when it is. In the meantime, you can view the 2008-2011 Strategic Plan here: http://www.icann.org/en/strategic-plan/

And an explanation of how that process works is given here: http://www.icann.org/en/planning/

I hope this is helpful in understanding both the financial information that we make available to you as well as the the entry points for community feedback. We take ICANN’s commitment to accountability and transparency to heart.

If you have any questions, if you feel we are still not providing enough information, or the right information, or if you want to know more about how you can respond to the budgeting process, please just post a comment below and we’ll review it and get back.

Thanks

Kevin Wilson
Chief Financial Officer, ICANN

The idea was to find a formula for open communication that was more than a repeat of existing open microphone sessions. The chairs also wanted to create a forum that could break through the silos of discussion and communication in which ACs and SOs often operate. And, lastly, they wanted the opportunity to discuss topics of mutual interest and importance, and to have those topics suggested by ACSO members.

Click here to jump to the meeting agenda

Each time, feedback has been taken from the community and the session adjusted to reflect that. For Sydney, the decision has been taken to reduce the time taken on Monday to just one session of 90 minutes and to concentrate on a single topic (albeit with multiple arms).

The colored cards used by the audience to express agreement, disagreement and either neutrality or uncertainty are back by popular demand, and a whiteboard will be introduced so that the discussions that take place can be captured and something tangible produced as a result of the conversation.

The ACs and SOs will again be represented by anywhere between one and four representatives and the session will be moderated again by Patrick Sharry. More details on the precise format will be run through at the start of the session.

For the dedicated ACSO session webpage, please visit: http://syd.icann.org/acso

AGENDA

The ACSO session will have as its focus the following topic:

Institutional Improvements

The roles and responsibilities of ACs, SOs, Policy Staff and Board in ICANN’s processes: current situation and possible evolutions

This topic will be explored within the current context of where ICANN is an organization, particularly: current practices and their contribution to transparency and accountability; ongoing independent reviews of the ACs and SOs and the subsequent reorganizations; the Improving Institutional Confidence (IIC) consultation that followed the midterm review of ICANN’s Joint Project Agreement (JPA) with the US government; and the current review of the JPA that is underway.

The Chairs of each of the ACs and SOs would like to note that discussing the current systems in place does NOT imply any implicit criticism of either the community or the staff. The aim of the discussion it to identify areas of improvement.

Instead, the Sydney meeting provides a unique opportunity to take at look at some of the practical aspects of ICANN’s continuing internal effort to improve institution confidence.

Current community topics that the conversation is expected to touch upon include:

• The ongoing independent reviews of the different parts of the ICANN model
• The Improving Institutional Confidence consultation and recommendations
• The conclusion of the Joint Project Agreement with the US government in September

Specific questions that will be explored include:

1. Roles and responsibilities of the ACs, SOs and Policy staff:

a. What should these roles be? 
b. What is the right balance between volunteer activity and policy staff activity?
c. Is the current balance correct or should it be altered?
d. Does the current balance lead to volunteer exhaustion?
e. Would shifting the balance diminish the degree of private bottom-up policy making?

2. Policy staff as Board intermediary:

a. Should all communications between the SOs be moderated by Policy staff?
b. Should there be direct communication between the Councils and the Board?

3. Board communication with Advisory Committees:

a. Should all ACs have the same rights in terms of recommendations and response by the Board to their issues?

4. Transparency of communications:

a. Should staff communications to the Board be confidential? 
b. Should communications regarding AC or SO activities be confidential?
c. Which other communications need to remain confidential?
d. What would be the effect of making most communications between staff and the Board open to community review?

Toutes ces entités sont regroupées en collèges afin de leur donner une représentation officielle au sein de l’ICANN.

La pyramide organisationnelle de l’ICANN est ainsi faite : les collèges remontent vers des “organismes de soutien (le “SO”)” comme le GNSO (il y en a deux autres : le ccNSO regroupe les gestionnaires d’extensions nationales et l’ASO les registres d’adresses IP régionaux). Comme leur nom l’indique, ces organismes servent de soutien direct au Conseil d’administration de l’ICANN.

Un exemple concret : le programme des nouvelles extensions. Depuis plusieurs années, ces grandes lignes ont été développées par le GNSO. Une fois prêtes, elles ont été présentées au Conseil d’administration. En juin 2008, lors de la réunion internationale de Paris, il les approuvé. Depuis, les équipes de l’ICANN travaillent avec le GNSO et le reste de la communauté pour en peaufiner les modalités d’application.

Le GNSO est donc actuellement sous les feux de la rampe et c’est une période très intéressante pour rejoindre son Conseil. J’y ai été élu par le collège des registrars pour remplacer Tom Keller, en fin de mandat. Le collège des registrars a trois représentants au Conseil, un pour l’Asie Pacifique (Adrian Kinderis), un pour l’Amérique du Nord (Tim Ruiz) et un pour l’Europe (moi). Mon mandat, de deux ans, a commencé juste après la réunion internationale du Caire.

Alors qu’ai-je vu ou appris depuis un mois ?

En une phrase : être au Conseil du GNSO, c’est une charge de travail incroyable et une implication de tout instant. Il est sans doute utile de rappeler que les conseillers du GNSO sont des volontaires non rémunérés. Chacun a une vie professionnelle (et accessoirement personnelle) en dehors de l’ICANN. Bien souvent, ce sont leurs employeurs qui supportent la charge financière du travail qu’ils réalisent pour le GNSO, y compris les voyages.

Bien entendu, le temps que ces conseillers passent à s’occuper du GNSO est autant de temps qu’ils ne donnent pas à leurs employeurs. De combien de temps parle-t-on ? J’ai voulu l’évaluer “au doigt mouillé”, juste pour me faire une idée. En un mois, c’est un petit millier d’emails dans ma boîte de réception en rapport avec le GNSO. Disons 10 minutes de traitement par email en moyenne, cela donne presque 7 jours de travail ! Voilà qui s’ajoute à ma fonction “officielle”, celle de gérer l’entreprise dont je suis l’un des fondateurs.

Mais lire des emails ne suffit pas. Il faut aussi comprendre les très nombreux sujets sur lesquels l’ICANN et sa communauté se penchent. Car pour être efficace et prendre les bonnes décisions, un conseiller se doit non seulement de maîtriser les dossiers directement en rapport avec son propre “SO”, mais aussi ceux des autres. Jetez un rapide coup d’œil à la une du site de l’ICANN et vous verrez parmi les sujets en cours : les relations registres/registrars, les nouveaux TLDs, les IDNs, le WHOIS, les activités du NomCom ou encore le plan stratégique de l’ICANN !

Il y a aussi les comités et groupes de travail sur lesquels un conseiller peut se retrouver. Un exemple rapide : une réforme importante du GNSO est en cours. Pour la mener à bien, deux comités de pilotages ont été créés. Je représente le collège des registrars sur l’un d’entre eux, l’OSC (pour “Operations Steering Committee”). A la clef, une réunion téléphonique de deux heures toute les semaines, un plan d’action à construire, des groupes de travail à constituer… tout cela s’ajoutant déjà aux réunions téléphoniques du Conseil, du bureau exécutif du collège des registrars, des séances d’information organisées par le GNSO ou l’ICANN directement…

Mais être au Conseil du GNSO ce n’est pas que du temps passé en réunions. C’est aussi être au contact de personnes dont le niveau de connaissance et de compréhension des processus de l’ICANN est tout simplement époustouflant. Alors que j’ai encore du mal ne serait-ce qu’à comprendre les règles de fonctionnement du Conseil, je suis entouré de personnes qui maîtrisent le moindre détail de dossiers allant du contrat des registrars ICANN aux règles d’application des régions géographiques utilisées pour nommer les nouveaux membres du Conseil d’administration.

Il y a là de quoi être impressionné, voir même intimidé.

Alors qu’ai-je appris en un mois au Conseil du GNSO ? Pour résumer : à respecter toujours plus ceux qui, dans toutes les différentes structures de l’ICANN, du plus petit groupe de travail jusqu’au Conseil d’administration, donnent sans compter pour faire avancer l’Internet.

Each issue covers the latest news and events, plus outlines how you can interact with the organization. This month, alongside the usual policy rundown, compliance summary, Board meeting precis, public comment digest, and blog complendium, is a briefing note for the recent Paris meeting and some early details about the Cairo meeting.

The hope is that, no matter which part of ICANN you are interested in, this magazine will act as an entry point and make people more aware of the other work that the organization carries out every month.

Feedback, as ever, is welcome. If you wish to receive the magazine automatically to your inbox, there is a very simple sign-up box above the magazine on the main magazine webpage at http://www.icann.org/magazine/.

In it, we provide updates on three policy areas: translation, SSAC, and new gTLDs. It also provide summaries of all 2008 Board meetings so far; interviews with the CEO and NomCom chair Hagen Hultzsch; the history behind ICANN’s efforts to deal with domain tasting; and sections covering recent blog discussions, public comment periods, and other ICANN-related news.

We hope you enjoy it – feedback, as ever, is welcome. If you wish to receive the magazine automatically to your inbox, there is a very simple sign-up box above the magazine on the main magazine webpage at http://www.icann.org/magazine/.

First some background and clarifying information. Having your script/language represented in the wiki is not a pre-requisite for eventually getting an IDN TLD in the root. These 11 languages/scripts are merely being used to evaluate usability of IDNs in applications. The “example.test” strings in the wiki were translated into the specified languages and then represented by the associated scripts.

There are no other strings but the one for “example” in each of the zones. To answer another question that often comes up — there are no registrations available and there is also no associated registration policies, nor are there variant tables. Variant tables across scripts can be quite a challenge to develop, especially when there are similarities with other scripts supported under the TLD (mixed or not). For more on this, see for example all the work related to Indian languages and scripts at http://del.icann.org/node/88 (the presentations will be posted asap).

What this all means is that having clear rules for how these tables and policies should be developed are very important factors as we move towards introduction of IDN TLDs. While the IDN Guidelines provide an initial overview of this, the details of it will be important in the implementation of the processes and policies related to the introduction of IDN TLDs (regardless of it being on the ccTLD or gTLD side).

So in other words, inclusion in the wiki does not indicate whether or not a script/language combination is safe to deploy and as such can be used directly in the root.

So back to the original question – what does the wiki then do? It is an online tool so all interested users can try out fully localized domain names (IDN both before and after the dot) in, for example, web addresses or email addresses. Interested users could be registrants, general users of domain names in some capacity, registries or companies that are thinking about becoming IDN TLD operators, application developers who either have or are going to implement IDNs for use in their products. As such there can be many different reasons for participating in the wiki. But in general it should provide a good overview of what IDNs solve and what the difficulties are around usage – the problems that users face. They will also help highlight other limitations in solutions (keyboards or software to type and also to display scripts, application support and difference in implementation, content, etc).

Historically, when new TLDs have been included in the DNS, there have been some cases with some usability problems. The hope is that the wiki in addition will demonstrate to any potential IDN TLD operator what some of the acceptance or usability problems are around IDNs. As such this will give a good up front indication of what user complaints may arise when the day comes that IDN registrations are purchased and moved into operation (under IDN TLDs).
The wiki provides some suggestions about how participants can test along with other IDN relevant IDN information. It can be accessed at http://idn.icann.org and functions like any wiki where you can set up an account and create pages and participate in discussion forums.

Note: while much of this work is related to IDN TLDs it is important to keep in mind that a lot of the experience and knowledge we have today to supply at the TLD level is coming from the implementations at the second level. IDN at second level have been around since 2001.