ICANN Johannesburg: des (lents) progrès pour les nouvelles extensions ?

Comme nous l’indiquions  La Réunion ICANN qui se tient cette semaine en Afrique du Sud est spécifiquement dédiée aux réflexions sur le cadre réglementaire (la fameuse “Policy”). On y attendait donc avec impatience les premiers retours du groupe de travail qui se penche sur les évolutions qui pourraient (ou devraient ?) être apportées aux règles ayant été utilisées pour le round de 2012. Surprise : le groupe de travail a travaillé relativement vite et a présenté cette semaine quelques-uns des axes de réflexion sur lesquels ses membres (qui sont eux-mêmes divisés en sous-groupes) se sont accordés.

Avant de le détailler, il est important de revenir sur la méthode et la philosophie de l’ICANN dans cet effort. Les candidatures pour des nouvelles extensions ont été déposées en 2012 mais la création des règles pour le faire avait commencé plusieurs années avant, et le “Guide du Candidat” qui en a résulté a fait l’objet de modifications jusqu’à quelques mois avant la soumission. La mise en place de centaines d’extensions à la fois n’avait jamais été tentée et a eu des conséquences imprévues, pour les entreprises comme pour les internautes. Le rôle de ce Groupe de Travail est donc de profiter de l’expérience accumulée afin d’identifier les problèmes du passé et de proposer des solutions pour l’avenir.

Après un an de travail (il s’est réuni pour la première fois en janvier 2016, hier en « temps ICANN » !), le groupe de travail est arrivé à des conclusions préliminaires : la première est d’importance puisque le groupe a déterminé qu’il n’y avait pas de raison objective de ne pas avoir de nouveau round. Par ailleurs, il ne voit de nécessité à imposer une limite au nombre de candidatures par candidat, ni par round. Ces deux prises de positions sont bien entendu importantes mais, pour les anciens candidats qui ont “souffert” et plus encore pour les entreprises qui n’ont pas souhaité candidater parce qu’elles jugeaient les règles trop complexes, ce sont les changements proposés qui devront retenir l’attention. La réunion de Johannesburg a été l’occasion de présenter les sujets sur lesquels la communauté est appelée à se prononcer.

Des catégories de candidatures ? Ce sujet est crucial, notamment pour les entreprises. Pour le round de 2012, l’ICANN avait refusé avec force de considérer des catégories. Une extension n’était qu’une chaîne de caractère, quel que soit le sens qu’elle pouvait avoir dans “la vie réelle” (marque déposée, nom de ville, etc). Concrètement lors de l’analyse des candidatures, l’ICANN ne faisait aucune différence entre “.XYZ”, “.Paris”, “.Bank” et “.SFR”. Tous étaient soumis aux mêmes règles, y compris, dans le cas d’un CorpTLD, d’utiliser (et de payer) un prestataire d’enregistrement accrédité à l’ICANN pour enregistrer ses propres noms, dans sa propre marque, pour ses propres utilisateurs ! Des situations ubuesques qui ont poussé les opérateurs de ces extensions à s’organiser et trouver en pratique les solutions qui leur étaient refusées par la théorie de l’ICANN. A titre d’exemple, .Bank et d’autres sont regroupés au sein de l’association “Verified TLDs” qui a fait une présentation remarquée à Johannesburg. Les CorpTLDs eux ont pu utiliser la “Spécification 13” qui leur accorde des dérogations si l’extension n’est utilisée qu’en interne… Le groupe de travail souhaite reprendre ces idées et les intégrer aux futures règles en pensant des questions simples : quelles catégories ? Pour qui ? Selon quel critère ? Un changement très bienvenu qui profiteraient à tous et lèverait peut-être des freins pour les entreprises.

Moins de surprises ? « Prédictability » ne se traduit pas bien en français mais il atteste d’un problème profond, directement lié au modèle « multi-acteurs » défendu depuis l’origine par ICANN. Concrètement, si tout le monde peut donner son avis avec un poids équivalent et plus ou moins n’importe quand, les titulaires d’extensions manquent de la stabilité nécessaire pour mettre en place (et respecter) leurs plans d’affaires. Tout en reconnaissant qu’il est impossible de tout prévoir, le Groupe de Travail propose de développer de meilleures méthodes de communication et d’échanges entre les membres de la communauté ICANN pour donner une meilleure visibilité aux nouvelles versions proposées. L’époque des 8 versions successives du Guide du candidat qu’on a connu entre 2009 et 2011 serait enfin révolue ?

Des lancements plus fréquents ? Même si le programme a mis des années à se mettre en place, la « fenêtre de tir » pour soumettre des candidatures a été extrêmement courte puisqu’elle n’a duré que du 12 janvier au 12 avril. Passée cette date, il n’était jusqu’à présent plus possible de soumettre de candidatures. Compte tenu du nombre de dossiers soumis et d’extensions actives, certains membres du Groupe de Travail pensent que l’ICANN et l’infrastructure DNS mondiale ont prouvés qu’ils étaient capables de supporter une charge plus grande avec des ouvertures plus fréquentes et régulières. Concrètement, avec ce système qualifié « d’hybride » on garderait le principe de « rounds » pour garder des dates clés (et laisser aux candidats le temps de préparer leur projet !) mais permettre entre chaque round d’accepter des candidatures – par exemple une fois par an – selon le principe bien connu du premier arrivé premier servi. Bien entendu, ce sujet aussi fera débat, et des questions pratiques devront être réglées (comment gérer les conflits entre demandes identiques ? Comment s’assurer que les ayants-droits potentiels pourraient continuer à se tenir au courant et à contester au besoin ?) mais des candidatures plus fréquentes éviteraient de reproduire la frustration de certains qui, ayant raté le coche en 2012, ne souhaitent pas attendre !

Ces points sont donc très importants pour l’avenir des nouvelles extensions et pour les entreprises qui souhaiteront en bénéficier. Cependant d’autres sujets, souvent plus concrets encore, devront aussi être tranchés prochainement par les sous-groupes de travail.

  1. Soutien aux candidats : il est patent que le programme précédent à mieux profité aux pays occidentaux et riches qu’aux autres. L’ICANN avait mis en place une procédure (complexe) pour subventionner financièrement certaines candidatures mais les entreprises des pays en voie de développement n’en ont que peu profité. Le Groupe de Travail s’interroge donc sur la possibilité de fournir aussi des conseils techniques et juridiques, tout en s’assurant que le coup de pouce financier soit de nature à rendre le futur registre solvable et indépendant.  
  2. Prestataires de Registre : acteur essentiel de la chaîne des extensions, le prestataire de Services de Registre (RSP) est peu connu et, lors du rond de 2012, ils étaient choisis sans processus précis par les candidats. Le Groupe de Travail propose que leur liste soit connue à l’avance et qu’ils soient eux-mêmes accrédités pour que les candidats puissent choisir en connaissance de cause. Par ailleurs, même si les tests techniques ne seraient pas abandonnés – il est important de s’assurer que le prestataire pourra faire bien fonctionner le « petit bout d’Internet » dévolu au candidat – l’ICANN pourrait considérer, enfin, qu’un prestataire qui gère plusieurs extensions n’a pas besoin d’être testé à chaque fois. Quand on sait que ces tests ont parfois retardés de plusieurs mois la sortie de certaines extensions, on ne peut que s’en réjouir.  
  3. Génériques réservés : on se souvient du tôlé qu’avait déclenché Amazon en candidatant pour plusieurs extensions reprenant des mots du langage courant (.books notamment) et en voulant les réserver à son propre usage. Interrogée à ce sujet lors de la réunion de cette semaine la représentante du Registre a d’ailleurs souligné, acide, qu’Amazon voulait « simplement innover conformément à la promesse faite par l’ICANN lors du lancement du Programme, et que pour innover il fallait parfois opérer dans des espaces clos ». Quoi qu’il en soit, cette utilisation ayant été interdite, le Groupe de Travail commence par dire fort logiquement qu’il n’a aucun recul pour déterminer un dommage éventuel. Il n’y a donc pas de consensus sur le sujet et trois solutions sont envisagées : les interdire totalement (comme c’était le cas en 2012, Amazon ayant dû s’engager à ouvrir à tous ses TLDs génériques), leur permettre d’exister avec des limitations quant à l’utilisation qui pourrait en être faîte, ou même définir des critères stricts qu’un candidat devra respecter pour espérer en gérer un. 
  4. Intégration Verticale : là aussi le sujet avait fait l’objet d’âpres débats pour déboucher sur une solution correcte. Il est bien possible à un Registre de posséder son propre Registrar et ainsi de contrôler son canal de distribution, sous réserve du respect de certains critères. Le Groupe de Travail indique qu’il y a eu moins de dix cas recensés de plaintes contre des Registres qui n’auraient pas respectés ces règles et que tous ont pu démontrer leur bonne foi et rentrer dans le rang. Le sujet n’est donc plus vraiment sensible et le Groupe demande simplement davantage de données et une adaptation contractuelle.  
  5. Noms Internationaux : avec plus de 1000 extensions (la plupart en alphabet latin) déjà actives, la recommandation qui consistait à demander que l’extension nouvelle ne soit pas similaire à un TLD existant pose un problème concret pour de futurs rounds qui voudraient utiliser des termes génériques déjà enregistrés mais dans leur propre alphabet. Le Groupe de Travail propose donc d’ « autoriser les variations d’extensions préexistantes si (1) elles sont gérées par le même Registre qui traitera contractuellement les extensions comme identiques et (2) les règles d’utilisation des alphabets pour les domaines et sous-domaines concernés sont annoncés au moment de l’évaluation de l’extension ». Il s’agirait d’une avancée significative pour les noms de domaine internationaux.  
  6. Name Collisions : la crainte qu’inspirait le sujet lors du précédent round a été démentie par les faits : après l’interdiction des .Home, .Mail et .Corp qui étaient effectivement utilisées par un grand nombre de machines pour des réseaux internes et risquaient de créer de trop fortes collisions si ces extensions étaient acceptées sur l’Internet global, le Groupe de Travail ne compte que 37 cas rapportés dont aucun n’était dangereux. Le Groupe recommande donc ici de garder la règle en l’état. 

Même si le nombre de sujets encore ouverts peut inquiéter, on peut néanmoins se réjouir de la cohérence du débat et de l’aspect pratique de la plupart des recommandations. Compte tenu des frustrations, et même parfois des échecs, lors du round de 2012, le status quo n’était pas acceptable. Si on ne peut toujours pas prédire quand le prochain round aura lieu, les équipes de SafeBrands présentent à l’ICANN 59 ont constaté la volonté concrète de la plupart des acteurs d’avancer. Le calendrier est posé et devrait permettre un nouveau Round plus efficace, nourri des expériences passées. SafeBrands suivra bien sûr régulièrement les travaux en cours et se propose d’ores et déjà de répondre à vos questions précises lors de notre Webinar : venez nombreux pour apprendre comment profiter (ou se protéger !) de cette évolution, qui semble désormais inarrêtable.