ICANN ICANN Email List Archives

[cctld-sunset-comments]


<<< Chronological Index >>>    <<< Thread Index    

Comments on the Discussion Paper on Retiring Country Code TLDs

  • To: cctld-sunset-comments@xxxxxxxxx
  • Subject: Comments on the Discussion Paper on Retiring Country Code TLDs
  • From: Elisabeth Porteneuve <Elisabeth.Porteneuve@xxxxxxxxxxxx>
  • Date: Wed, 31 Jan 2007 19:11:44 +0100 (MET)

31 january 2007
(text in English and in French)

Good evening,

On the 5th December 2006, ICANN published on its website a "Discussion 
Paper on Retiring Country Code Top-Level Domains", cf. 
http://www.icann.org/announcements/announcement-2-05dec06.htm, with an 
attached questionnaire.
ICANN specifies the questionnaire is being done within its contract 
with the United States Government concerning IANA function.

The questionnaire is about the policy related to the management of the 
ccTLDs. Not only it address the issue of three ccTLDs, related to the 
discontinued 2-letters codes from ISO 3166-1 table (SU, YU, TP), but 
also disserts on three other ccTLDs existing in 2-letters ISO 3166-1 
table, with special status, and which have been in the Root for several 
years (UK, EU, AC), cf. 
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html

There are no apparent reasons to explain such a questionnaire on ICANN 
website, either the terms of contract for IANA function (removal of ccTLD 
from the Root is not ICANN's remit), nor any immediate emergency related to 
the stability and security of the Internet.

  1. The imminent threatens on the stability and security on the Internet 
  is definitely not a case, because there was no single recent change is 
  ccTLD's arena. No one of three ccTLD codes discontinued from 2-letters 
  ISO 3166-1 table - "SU" in 1994, "YU in 2006, "TP" in 2003 - have been 
  abandoned by its registry. The .SU is run by the same registry as .RU. 
  The .YU registry has been operation perfectly well despite ten years 
  war in Balkans. There is no single new element related to those 
  registries since ICANN inception in 1998.

  2. The exact mandate of most recent IANA contract signed in August 2006 
  between the U.S. Government and ICANN is published on NTIA's site, cf. 
  http://www.ntia.doc.gov/ntiahome/domainname/iana.htm . The IANA contract 
  is very explicit on every action ICANN shall and must perform with regard 
  to modification of the Root file, see pages 4-5, C.2 CONTRACTOR REQUIREMENTS, 
  section C.2.2.1, and page 27, APPENDIX A - PROCESSING METRICS, PROCESS FOR 
  IANA ROOT MANAGEMENT REQUESTS, Specific Steps to Process a Change Request, 
  in http://www.ntia.doc.gov/ntiahome/domainname/iana/ianacontract_081406.pdf. 
  In no one place of the U.S. Government contract there is a single world 
  stating that a policy related to retiring ccTLDs is within IANA mandate.

In summary, the ICANN/IANA questionnaire concerning the policy of retiring 
ccTLDs from the root is outside of its contractual remit. The very existence 
of the questionnaire creates conflicts. It shall be withdrawn.

The countries and territories changes over time, according to the sovereign 
will of theirs populations, which is subsequently recorded in the 
statistical tables of United Nations on one side, and in the ISO 3166-1 
tables on another side, for any practical usage one may need. In its wisdom, 
the ISO 3166/Maintenance Agency does not allocate discontinued codes for at 
least 50 years. ICANN is one of users of ISO 3166-1 tables, and also one of 
10 voting members of ISO 3166/MA - that ensure for a correct communication 
between those organisations, and pragmatic approach for synchronisation of 
ISO 3166-1 tables and ccTLD codes in the Root file. Perhaps if a code is 
withdrawn from 2-letters ISO 3166-1 list it should go to the reserved list 
indefinitely particularly if there is a TLD in existence, and that way any 
divergence between ISO 3166-1 tables and Root files is averted. But that 
issue is definitely within the ISO 3166/Maintenance Agency's mandate.
 
--

Bonsoir,

Le 5 décembre dernier l'ICANN a affiché sur son site web un document 
avec une enquête concernant le retrait des codes pays de la racine de 
l'Internet, cf. 
http://www.icann.org/announcements/announcement-2-05dec06.htm,
L'ICANN précise que cette enquête se situe dans le cadre de son 
contrat avec le gouvernement des Etats-Unis pour la fonction IANA.

Le questionnaire en question s'attaque clairement à la politique de 
gestion des codes ccTLD. Non seulement il aborde le sujet des trois 
ccTLDs, dont les codes a 2-lettres ont été supprimés de la table 
ISO 3166-1 (SU, YU, TP), mais aussi disserte sur les trois autres ccTLDs, 
dont les codes a 2-lettres existent dans la table ISO 3166-1 avec le 
statut réservé, et qui sont dans la racine depuis plusieurs années 
(UK, EU, AC), cf. 
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/iso_3166-1_decoding_table.html

Il n'y a pas de raison apparente pour expliquer un tel questionnaire 
sur le site de l'ICANN, ni les termes du contrat pour la fonction IANA 
(retrait d'un ccTLD ne fait pas partie des attributions de l'ICANN), 
ni une menace immédiate liée à la stabilité et sécurité de l'Internet.

  1. La menace immédiate sur la stabilité et sécurité de l'Internet 
     est à exclure, puisque rien n'a changé dans le fonctionnement 
     quotidien de tous les ccTLDs, y compris ceux visés par le 
     questionnaire. Aucun des trois ccTLDs, dont les codes ont été 
     enlevés de la table ISO 3166-1, - "SU" en 1994, "YU en 2006, 
     "TP" en 2003 - n'a été abandonné par son registre. Le ".SU" 
     est opéré par le même registre que ".RU". Le ".YU" fonctionne 
     correctement malgré dix ans des guerres dans les Balkans. 
     Il n'y a aucun élément nouveau depuis la création de 
     l'ICANN fin 1998.

  2. Les termes exactes du plus récent contrat IANA, signé en août 
     2006 entre le gouvernement des Etats-Unis et l'ICANN, sont 
     affichés sur le site de la NTIA, cf. 
     http://www.ntia.doc.gov/ntiahome/domainname/iana.htm
     Le contrat IANA est très explicite sur tout ce que l'ICANN peux 
     et doit faire concernant la modification de la racine, voir 
     pages 4-5, C.2 CONTRACTOR REQUIREMENTS, section C.2.2.1, et page 27, 
     APPENDIX A - PROCESSING METRICS, PROCESS FOR IANA ROOT MANAGEMENT 
     REQUESTS, Specific Steps to Process a Change Request dans 
     http://www.ntia.doc.gov/ntiahome/domainname/iana/ianacontract_081406.pdf. 
     En aucun endroit ce contrat avec le gouvernement des Etats-Unis 
     ne spécifie que la politique des retraits des ccTLDs de la racine 
     fait partie du mandat de IANA.

En conclusion, le questionnaire de l'ICANN/IANA concernant le retrait 
des codes pays de la racine de l'Internet se situe hors des attributions 
du cadre contractuel de la mission IANA. L'existence même de ce 
questionnaire crée des situations conflictuelles. Il doit être retiré.

Les pays et les territoires se créent et changent par la volonté 
souveraine de leurs populations, cela est enregistré dans les tables 
statistiques par les Nations Unis d'un côté, et dans les tables de 
l'ISO 3166-1 pour les utilisations pratiques par tout ceux qui en ont 
besoin. Dans sa sagesse l'Agence de Maintenance ISO 3166 n'affecte pas 
des codes désaffectés pendant une période de 50 ans. L'ICANN est 
l'un des utilisateurs des tables ISO3166-1, il est aussi l'un des 10 membres 
votants de l'Agence de Maintenance ISO 3166 - tout est donc en place pour 
une bonne communication, et une approche pragmatique de synchronisation 
des tables ISO 3166-1 avec les codes ccTLD de la racine. Peut-être qu'il 
serait souhaitable qu'un code retiré de la table a 2-lettres d'ISO 3166-1 
puisse rester indéfiniment sur la liste réservée, particulièrement 
si un TLD correspondant existe, ce qui éviterait une divergence entre 
les tables ISO 3166-1 et la racine de l'Internet. Mais ce sujet relève 
certainement de la compétence de l'Agence de Maintenance ISO 3166.


Elisabeth Porteneuve 


<<< Chronological Index >>>    <<< Thread Index    

Privacy Policy | Terms of Service | Cookies Policy