Discussion Paper on Retiring Country Code Top-Level Domains

The Internet Assigned Numbers Authority (IANA), a function performed by ICANN in accordance with its obligations under contract with the U.S. Government, is responsible for the delegation of top-level domains in the DNS root.

IANA relies upon the ISO 3166-1 standard, and specifically the alpha-2 codes contained therein, for definition of two-letter codes that may be used for country-code top-level domains (ccTLDs). IANA allocates ccTLD operators based upon their ability to meet delegation criteria, which includes the ability to demonstrate local support, and technical competency requirements.

Whilst this practice is relatively straightforward for the establishment and ongoing operation of assigned codes, IANA has no formally defined process on how to decommission a country-code top-level domain when it is retired from the “officially assigned” state in the ISO 3166 database.

To date, in the case where a code has been replaced by one or more new codes, IANA has advised the relevant operators that the old code would need to be retired and that they should develop plans to do so1. However, IANA has not aggressively pursued the affected operators to conclude the decommissioning process.

IANA is seeking to review its practices associated with top-level domains which have been revoked from the officially assigned list, and more specifically, top-level domains which have been replaced by a new country code.

A select list of ISO 3166-1 alterations that help illustrate the dimension of the issue are:

Zaire's ("ZR") renaming to the Democratic Republic of the Congo ("CD").

The breakup of the Soviet Union resulting in the code "SU" being replaced with codes for the independent states, such as "RU", "BY", and "UA". Every former soviet state has a new code, which been allocated to an operator by IANA.

The remaining components of Yugoslavia ("YU") becoming Serbia and Montenegro ("CS"). Following a referendum, in September 2006 Serbia and Montenegro further split into two independent identities Serbia (“RS”) and Montenegro (“ME”).

The ISO 3166 standard also has codes which are "exceptionally reserved", in essence meaning they are special allocations that may be used under certain circumstances. In that category, IANA presently has delegations for three of these codes:

The United Kingdom ("GB") have elected to use the exceptionally reserved code of UK as its primary ccTLD.

The European Union have been delegated the exceptionally reserved code of EU.

Ascension Island is delegated the exceptionally reserved code of AC.

Whilst IANA has overseen the successful transition of "ZR" to "CD", domains such as "SU" and "TP" still exist in the DNS root.

Some of the relevant issues to consider:

In the event a code is not revoked in a timely manner, there is a risk that its continued use would deprive its new user of a valid country code should it be reallocated. This is highlighted by the case of "CS", which served Czechoslovakia, and later Serbia and Montenegro.

Broadly speaking, each country or autonomous territory has a single top-level domain at their disposal. It may be considered inequitable that certain countries have more than one such domain available. This is highlighted by East Timor (TP and TL) and the United Kingdom (GB and UK), although it should be noted that GB is effectively inactive.

The global policy surrounding the operation of ccTLDs heavily emphasises the role of the local Internet community, local government, and local law. Should a code represent an area that does not align to a present-day country, the matter of which government and law has jurisdiction becomes unclear.

With these issues in mind, we are seeking community input on how IANA should handle top-level domains that are no longer ordinarily assigned codes in the ISO-3166.

Guiding questions:

Should IANA adhere to the ISO-3166 standard and remove top-level domains from the DNS root that become transitionally reserved (i.e. retired)?

If so, by what process should this be conducted?

What implementation timeframes for removal should be specified?

If removal is test-based, what specific milestones should signify removal from the root zone?

What pre-emptive right, if any, should existing operators have toward a new code that covers an area previously serviced (in whole, or in part) by another code?

In the event there is more than one code for a particular country available for its use (e.g. GB and UK), what policy should govern their status?

1 The ICANN Board resolution to delegate .TL during its January 2005 meeting specifically calls for the migration of domains from .TP to .TL. ICANN made public statements during 2003 that the .SU domain would be decommissioned, with an estimated time-frame of one year. ICANN staff consultations have been conducted with other affected TLD operators.

A note about tracking cookies:

This notice is intended to appear only the first time you visit the site on any computer.Dismiss

Domain Name System

Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."