Public participation site

As ICANN staff, it is hard to avoid the news when your organisation is the subject of a hearing held by the United States Congress. This week we saw another such hearing, where the House Judiciary committee discussed the future deployment of new top-level domains.

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.

Last week I attended the “Second International Conference for ccTLD Registries and Registrars of CIS, Central and Eastern Europe”, held in the picturesque lakeside town of Bled, in Slovenia. Bled is one of the most beautiful places I’ve had the pleasure to visit and the conference, despite its rather cumbersome title, was similarly rewarding.

Picturesque Bled - location for the ccTLD meeting

I’ve been around the domain name industry for a while and have attended a few ICANN meetings, but this was only my second regional ccTLD-focussed conference. I’ve also had some exposure to Eastern Europe but my exposure to Central Asia and the Caucasus is almost zero, limited to watching a picture of a plane following a red line across a map of the area on overnight flights between Australia and Europe.

I therefore wasn’t entirely sure what to expect, though my background research suggested that it was likely to be an interesting affair. The attendees list indicated a healthy turnout of ccTLD Managers, representing everyone from EU member states to Central Asian Republics. As my role at AusRegistry International is to build relationships with ccTLD managers around the world, this looked promising.

The conference itself was organised (very well, it should be said) by the Coordination Center for TLD RU (ccTLD.RU – Russia’s ccTLD manager), with local assistance from ARNES (the Slovenian ccTLD manager) and the Slovenian chapter of the Internet Society.

Each of the countries represented at the conference (with the exception of guest speakers, such as myself) share similar histories and so cultural perspectives and I was curious to see to what extent this, and Russia’s historically dominant position in the region, impacts on how ccTLD managers see their role in the Internet.

Many of the attendees spoke better Russian than English so a significant proportion of the conference was conducted in Russian. This was my first experience listening to a translation, which took a little getting used to, but the translator was really very good. Trying to watch a presentation in Cyrillic though was a reminder of just how spoilt I normally am as a native English speaker in today’s world, and of how critically important IDNs are to this (and other) regions.

It was fascinating to hear some very different perspectives than I’ve been used to in the past. As I come from an English-speaking country that is politically closely aligned with the United States and well represented within the ICANN community, it’s easy to forget that there are groups of people who are much less comfortable operating within the ICANN process, especially when it comes to the role the US government plays with respect to the agreements and contracts it has with ICANN.

A number of ICANN staff attended the meeting and did their best to allay some of the concerns expressed, particularly the idea that the US government has ‘a big red button’ that can be used to turn off the Internet at will. While this at first seemed ludicrous, even paranoid to me, it was a view earnestly held by a number of my colleagues and it was instructive to hear their views and arguments.

For example, some of the countries in this region do not send representatives to the GAC, because (as I understand it) they feel that this would be interpreted as recognition of the US government as the controlling body of the Internet. Others feel it is better to work from inside the tent, rather than outside – and there was also much encouragement to join and participate in the ccNSO. I hope I was also able to provide them with some of my, Australian, perspective.

This conference therefore plays an important regional role as an event that allows ccTLD managers (and others in the industry) to share their experiences and to support each other, without becoming entangled in the political issues that make ICANN a problematic space for some of them.

From a personal perspective, it was great to have the opportunity to meet with ccTLD managers from a range of countries, and to hear about the various challenges that they face in an increasingly competitive market and an increasingly challenging security environment.

I also enjoyed the chance, as part of the Marketing panel, to present some of the experiences that we have gained during our time as Registry Operator for the dot-au ccTLD and from our work with other ccTLDs, especially our clients in the Middle East.

I should also mention the local hosts’ hospitality: we were treated to two excellent dinners – the second one being a particularly special affair held in Bled Castle with spectacular views over the lake and the mountains beyond.

The only real complaint I have is in relation to the extremely flaky wireless internet connectivity in the conference hall. I have a suspicion though that this may have been a deliberate strategy on the part of the organisers to get people to actually listen to the presentations. A strategy to be considered for future ICANN meetings perhaps…

Jon Lawrence is Business Development Consultant at AusRegistry International

I’ve previously written about the problem with IPv4 /8s which have been used to number IP networks in an unofficial and improper way.

The problem is that the unofficial usage makes it more difficult for ISPs to bring these addresses into use when they are officially allocated and so less desirable. But we have to allocate IPv4 addresses to the RIRs as long as we still have them and they still request them. We just need to implement a mechanism to select which /8 is allocated to which RIR.

The mechanism we have implemented reserves two of the /8s showing the least unofficial use for each of the newest RIRs. AfriNIC and LACNIC have fewest IPv4 /8s and service the regions with the most developing economies. We decided that those RIRs should have four of the easiest to use /8s reserved for them.

The other /8s are split between two pools and when APNIC, ARIN or the RIPE NCC qualify for additional IPv4 address space they will be allocated one /8 from each pool, with the /8 being chosen using a verifiable random selection mechanism. The mechanism is based on the “Publicly Verifiable Nomcom Random Selection” mechanism described in RFC 2777.

The sources of randomness used are the prices of the FTSE 100, Dow Jones Industrial Average and Hang Seng Index from midday at the exchange site the day after the request is received, as published on the Yahoo! Finance web site.

The pool of /8s which have been used to number IP networks in an unofficial and improper way is larger than the other pool. So when the smaller pool runs out, all allocations to APNIC, ARIN and the RIPE NCC will come from the larger pool until it too is empty. Then, if any of the /8s reserved for AfriNIC and LACNIC have not been allocated they will become part of a single pool used for all RIRs.

Of course, when all of this is done, there are still five /8s set aside for the implementation of the Global Policy for the Allocation of the Remaining IPv4 Address Space. Very little use of those /8s was detected in our 2008 research.

???????? ???????????????? ?????? ?????? RU ?????? ?????????? ?????? ? ????????? ??????????? ????????? ????? ???? (GNSO Council).

? ????? ??? ??? ???????:

1. ?????? ?? ????? ?????? ???? ??????????? ? gNSO Council?
??????? ? ????? ???? ??????????? ? ccNSO council ? ??????, ??? gNSO ??? ???? ?????????. ? ????? ? ???????????????? ???????, ???? ????????? ????? ?????? ? ccNSO, ??????? ? ????? ?????????????? ? gNSO.

2. ???? ?? ? ?????? ??????? ?? ??????? ????? ???????? ??????? gTLD?
?????????? ????. ?????? ? ???? ????? ?? ?????? ?????????? ?? ?????? ??????????. ??-?????? ? ??? ???? ????? ??????? ? ????????? ??????. ????? .gazprom ? .??????? ? .???????? ????? ?????? ????????? ??? ???? ????????. ??-??????, ???? ????????? ??? ???????. ???????? .??????.

3. ????? ????? ???? ????? ? ?????? GNSO?
? ???? ???? ???? ? ?????? ?? ????????? IDN gTLD ? ??????, ??? ????? ???????????? ??? ?????? ??? ?????????? ????? ???????? ? ??????????????? ????? gTLD ? ccTLD ????????? ? ????? ?????????? ?????????, ??????? ???????? ?????????????? ??? ???? ????? ???????. ???????? ??????
???????? ?????, ???????? ????????? ????-??????, ???????? ???????? ???????????????, ???? ???????? ??????? ??????? ????????. ????? ??? ?????? ????????? ???? ??????? ????????? ????? cc ? g ?????: ???????? ?????? ??? ??????????? ??????????? ?????? ?????? (?????? – ????????? ? ??????) ? ?????? ??? ??????? ??????? (.??????, .??????)

At the joint meeting of ICANN’s advisory committees and supporting organizations in Sydney, a number of core issues and corresponding possible solutions were discussed and pulled into a summary document.

We have put that document out in a radically different public comment period to allow for as much community discussion and collaboration as possible.

The comment period uses Jive software which allows for simple interaction and discussion between community members. It is an experiment we are running from now until 24 September. You can view everyone’s responses, clearly broken down into different areas, and if you register post your own thoughts and responses. As well as vote in polls, write blog posts, and so on.

The AC/SO summary drew out six main issues as well as seven suggested solutions to fix those issues. The top two issues were frustration and exhaustion at the huge volume of work, and the lack of visibility of the impact of volunteer input on decision-making.

The top three suggested solutions were: prioritization of the workload; better scoping of issues at the start of policy processes; and improving accessibility to issues by providing summaries.

Now we need you as the community to flesh out these broad points into specific ideas and suggestions.

The discussion space will be shut down after 30 days as the experiment closes and a report will then be written covering what happened as well as the feasibility of using Jive or similar software for future community discussions.

So if you want to make your voice heard not only about how ICANN can improve but the ways in which those improvement discussions are held, then please login on today and start interacting.

You can log-on to the collaborative space at: https://jive.dev.icann.org/community/acso.