The lives of country code domains

by Kim Davies on September 19, 2007

ICANN made a little piece of history in three countries a few days ago when it approved the delegation of the .KP domain for North Korea, the .RS domain for Serbia, and the .ME domain for Montenegro. For the former it marks a further step in their efforts to connect their country to the Internet. For the latter, it gives these two new countries the ability to shrug off their historical designation of .YU, and use something that better reflects their countries on the net.

With the transition of Serbia and Montenegro to using .RS and .ME comes the task of migrating users from the .YU domain. As we have talked about before, ICANN uses an international standard for determining country codes for use on the Internet. This standard, known as ISO 3166-1, indicates when new countries codes are created, changed or removed. As Yugoslavia, the predecessor country to Serbia and Montenegro, is now a piece of history – so too is its YU country code.

Recognising the need to transition from the .YU domain, the new operators of .RS and .ME have proposed a transition plan that will see .YU registrants having some time to arrange for their replacement domains in their new country. After this transition is complete, the .YU domain will be decommissioned. It is envisaged this transfer will take a couple of years, and ICANN will monitor the progress to ensure everything is on track.

“But—”, you may ask, “I have been reading in the media lately that the Soviet Union’s .SU domain still exists. Why is that?”

Traditionally when country codes have been retired, it has been left to their local Internet communities to determine the most appropriate way to arrange for a transition. This is in line with the general principle that country code domains are operated within countries for their local Internet community, in the way that best serves them. As such, domains like .ZR (Zaire) have been retired, and the transition from .TP (Portuguese Timor) to .TL (Timor Leste) is progressing.

We recognize though that the .SU community has had difficulty reaching agreement on how best to transition away from the .SU domain. We have recently been in talks with the .SU operators, helping them identify their options so that their community can decide the best approach. Our major concern is that registrants are not aware of the caveats associated with registering in .SU given that it is marked for retirement. This lack of understanding was underscored by a number of responses we received during a public consultation we conducted late last year. We have urged the current .SU operators to make it clear to the .SU registrants the issues surrounding the domain, as well as to freeze new registrations until its future is clear.

To retain .SU, under current policy they would need to successfully apply for the code to be re-instated into the ISO 3166-1 standard, either as a regular two-letter country code, or as an “exceptionally reserved” code like UK and EU. (ICANN permits uses of codes that have been exceptionally reserved by ISO in certain circumstances.)

This standard is administered by ISO under guidance from the UN, not by us. ICANN believes it should not be in a position of deciding what is, or is not, a country. This is why we rely on an independent third party standard.

There are other issues that will need to be addressed for .SU to be a viable ccTLD designation, but recognition by the appropriate standard is a prerequisite.

If .SU is not retained by meeting these policy criteria, the domain needs to be transitioned into retirement. For .SU users, this would either mean migrating to its successor domains like .RU and .UA, or applying to ICANN for a replacement new generic top-level domain. This could be similar to domains like “.CAT” that was created for the Catalan-speaking community. These domains are not two-letter ISO 3166-1 codes, and therefore do not need to align with existing countries in the same way country codes do.


Bret Fausett 09.20.07 at 10:43 am

I know that it’s long been policy (first Postel’s and then ICANN/IANA’s) to use the ISO list as the guide for whether to *create* a ccTLD, but when did it become policy (or is it) to use the list to *retire* a TLD against the will of the TLD operator? Curious.


Veni Markovski 09.20.07 at 11:16 am

What would have happened if the .cs was not retired, and Serbia and Montenegro did not decide to split (rather, Montenegro didn’t decide to to independent)? ISO has assigned .cs for Serbia and Montenegro, but if the .cs ccTLD has “decided” to keep it, would certainly bring instability to the Internet? I actually remember such a discussion some time ago, about the .cs, and one of the arguments to wait with the shut down of .yu and moving to .cs was exactly that – the expected independence of Montenegro.
btw, for the .SU you can read also this letter (PDF) to Paul Twomey.

check also my blog:

The opinions expressed above are those of the author,
not of any organizations, associated with or related to
the author in any given way.

Kim Davies 09.20.07 at 2:40 pm

Hi Bret,

The reliance on ISO 3166-1 as an independent arbiter of what is, and what isn’t, a county code can’t effectively function in the long term if it is not adhered to when codes are removed. Otherwise it will diverge, and you will have collision issues (as highlighted by the recycling of CS). The documentation about ccTLD neither say a domain must be created when a new code is added to ISO 3166-1, nor do they say it must be removed when a code is removed. However it has been consistently interpreted by IANA to mean that codes can be applied for once in the standard, and need to be retired once removed.

But one of the more interesting issues is that country code domains are unique in that they get almost full autonomy on the basis they operate it in the public interest of a clearly defined nation or autonomous entity, which has laws and a government. Much of ccTLD policy, precedent and practice revolves around the concept that there is local law the governs the domain, and a clearly defined Internet community it is designated to serve. Such concepts don’t exist with non-existent states. For the sake of argument, lets say it is agreed ICANN should no longer follow ISO 3166-1, and allow domains like SU to exist. How should a redelegation request be handled? Which government and local community should agree? Every former country in the former Soviet Union? How can a domain be effectively governed under the laws of multiple states? Ultimately, how can the domain be effectively governed under the ccTLD governance constructs?

ICANN’s concern has to be both for the long term and short term stability of the Internet, and these questions and others would need to be addressed before a deviation from existing policy could be workable.

Bret Fausett 09.20.07 at 3:32 pm

Thanks, Kim. That’s very helpful background. In response to your series of questions, I think the best that can be said for .SU is that when its associated country ceased to be a country, it ceased to be a ccTLD…but perhaps it’s still a TLD.

In his comment, Veni kindly pointed to the correspondence of June on this issue in which the authors described a community of persons united by history and language. Perhaps .SU has become a gTLD, like .CAT or .ASIA. If so, it shouldn’t get autonomy, like you’d give a ccTLD, but what about protecting the registrants’ interests in their names by allowing the registry operator to sign a sponsored gTLD contract with ICANN (binding it to consensus policies and obligating it to fund ICANN). SU makes as much sense as .CAT, and it already has a user base.

Food for thought?


Kim Davies 09.20.07 at 4:04 pm

A new ICANN consensus policy that explicitly recognised former country codes as potential gTLDs could solve many of the issues, but of course doesn’t address ISO 3166-1 divergence. Imagine if in the future Southern Sudan obtains independence, which it is reportedly seeking, and is allocated the “SU” code in ISO 3166-1. If SU was in use as a gTLD it would presumably deprive a country of having its own country code domain. By reserving two-letter ASCII domains purely for country codes, it ensures there is no contention for future country codes – something the Reserved Names Working Group supported recently.

Ultimately if there is a change of policy, that is for the ICANN community to decide. For now the options seem to be limited to those I described in the blog post.

Dave 09.20.07 at 8:17 pm

I can see the .me extension being VERY popular.

Bret Fausett 09.20.07 at 8:47 pm

Thanks. .SU is still on the ISO transitional reserved list, so Southern Sudan won’t get that code anytime soon, but the point is still well taken.

— Bret

CarlB 09.21.07 at 4:47 am

The .su should be exceptionally reserved for much like .eu was exceptionally reserved for the European Union.

The first step should be for the national standards association (whatever is the Russian equivalent to ANSI in the US and CSA in Canada, eh?) to request the exceptional reservation from ISO.

Threatening to “nuke the Soviet Union” from the Internet is more disruptive than useful. As much as one code per country seems to be desired, no one blinks when the US is given .as .gov .gu .mil .pr .um .us .vi and the lion’s share of .edu – quite the extensive collection of TLD’s.

Patrick Jones 09.21.07 at 12:48 pm

What about offering to transition .SU to a Cyrillic version of SU once the IDN evaluation is complete?

Veni Markovski 09.22.07 at 2:44 am

Problematic. It’s the current ccTLD for Cyprus :)

Patrick Jones 09.22.07 at 3:26 am

Thanks for the clarification Veni. So the problem is complicated then.

CarlB 09.22.07 at 7:57 am

If .su were to be moved (in its entirety) to another TLD, then .cis (or its translated equivalent, Содружество Независимых Государств – СНГ) would be the more obvious candidate.

The problem with moving an entire ccTLD is that every site in it needs to be renamed and reconfigured, breaking all inbound links to that site. It’s difficult enough to move a tiny place like Timor-Leste… so now I have to rename everything .tl? How many .tp sites are still active, and how many of those don’t match the content of the corresponding .tl domains which are provided to registrants as a replacement? By comparison, .su is huge – so, for technical reasons, having to rename every domain in it is undesirable.

Leaving things as-is isn’t a solution, as .su is only “transitionally reserved” in ISO 3166, that status will expire eventually – it usually lasts for five years or so. What needs to happen is that ISO mark .su as “exceptionally reserved”, much like .eu

Elisabeth Porteneuve 09.24.07 at 3:28 am

I am worried by Kim’s approach to have automatic considerations given to the ISO3166-1 codes (“a county code can’t effectively function in the long term if it is not adhered to when codes are removed” etc).

It is not that simple, and cannot be, as shown by the past record of both UN statistic division and ISO3166/MA. It happens that sometimes (very scarcely, but not never) some problems in rules of both organizations are discovered to have side effects, and are changed, and it has also impact on ISO3166-1 table.

For example today there is a rule that to get into ISO3166-1 table an entity must have obtained UN statistic division numeric code. Today the UN statistic division does not allocate numeric code to inhabited territories. In the past the inhabited Heard and McDonald Islands – HM, got to the ISO 3166-1 main table and remain there, the similar for Bouvet Island – BV.

What ICANN/IANA intends to do with such a horrendous discrepancy? Instruct ISO3166/MA to put HM and BV on transitionally reserved code element list? Instruct UN statistic division to not disrupt automatic scripts of ICANN/IANA? Instruct inhabitants of those inhabited islands they should not be on the Internet?

My opinion on SU did not change, the registry is in Russia, operates under Russian rules, it is not a TLD, it is a ccTLD. I do not see the slightest reason why Russian organizations or individuals who registered domain names under .SU and have been using it for many years shall stop it, or shall move their contracts under US law. That is a matter of stability of Internet, whether we like it or not.


See also my other comments re SU posted to the ICANN forum in December 2006, cf.

smarkovic 09.25.07 at 2:51 am

“Much of ccTLD policy, precedent and practice revolves around the concept that there is local law the governs the domain, and a clearly defined Internet community it is designated to serve. Such concepts don’t exist with non-existent states.”

This statement for the most part is not true, because, under international law, it is always known (or it is decided by the relevant international bodies) which government is the ‘legal successor’ of the former state’s assets and legal responsibilities (including the ccTLD).

In the case of .SU, the legal successor of the former Soviet Union is the Russian Federation and they are effectively the government contact for .SU ccTLD.

David Conrad 09.25.07 at 11:14 pm


The approach you mention is not “Kim’s” approach, it is the approach used by the IANA since the inception of the domain name system in 1983.

Your comments about HM and BV appear to be irrelevant. ICANN does not instruct ISO-3166/MA, rather we listen to what they say. They have not moved HM or BV to transitionally reserved, so there is no issue. They say that uses of transitional codes should cease “ASAP” and that puts us in a bit of a bind with SU since it does not appear they are interested in ceasing “ASAP”.

You are implying we cease using ISO-3166-1 as a determinant for ccTLDs. That’s fine if that’s what the Internet community desires, but it would be helpful if you would suggest an alternative.


David Conrad 09.25.07 at 11:19 pm


The decision as to whether SU is moved to “exceptionally reserved” is one made by ISO-3166/MA, not ICANN.

To my knowledge, no one at ICANN has “threatened to ‘nuke the Soviet Union’ from the Internet”. We have asked the community what we should do about the issue of codes, including SU, YU, and TP, that have been moved off ISO-3166-1 by ISO-3166/MA. In all cases but SU, agreements have been reached that allowed for a graceful transition to a new code. The question we face is what to do when a graceful transition is not possible.


Wibblemeister 10.05.07 at 12:15 am

Why should .bv and .hm (and others) not be included in ISO 3166-1? Bouvet Island is a dependency of Norway and not an integral part of the Kingdom, and whilst the Heard and McDonald Islands are a dependency of, rather than an integral part of the Commonwealth of Australia.

If France wishes to integrate its various territories into France proper, that’s entirely its business, but equally it’s the business of other nations how they define their relationships with their dependent territories.

David Conrad 10.05.07 at 12:22 am

That would be an issue to raise with the ISO-3166 Maintenance Agency, not with ICANN.

Andrey G. Sergeev 10.06.07 at 7:46 am

If .su were to be moved (in its entirety) to another TLD, then .cis (or its translated equivalent, Содружество Независимых Государств – СНГ) would be the more obvious candidate.

Nope. In fact CIS as an interstate entity is more dead than alive so they should first develop the .CIS.INT TLD rather than request a new one.

Vasily 10.06.07 at 9:19 am

I, as well as many Russians, for closing ICANN in Russia. Also I consider, that ICANN strikes at my rights. Yours faithfully, Vasily.

Wibblemeister 10.12.07 at 1:57 pm

BTW – when can we expect to see ccTLDs delegated for the new ISO 3166-1 codes of BL and MF?

Elaine 10.27.07 at 8:46 am

“How many .tp sites are still active, and how many of those don’t match the content of the corresponding .tl domains which are provided to registrants as a replacement?”

This is a problem the registrant must resolve. During re-delegation all .tp names were mapped to .tl. By example, the exact record for was copied and mirrored to Registrants of .tp names have been instructed to move content to their new .tl names. Existing .TP domains are expiring or have expired and cannot be renewed. When a registrant seeks to renew their .tp name, it is not possible. Instead they are instructed to move web content to the .TL version. It is neither a short-term project nor a difficult problem.

Comments on this entry are closed.