Résumé

  • Le RySG demande au Conseil de l’ICANN d’adopter le modèle de gouvernance du Root Server System publié en février, de fournir des moyens et un secrétariat pour la phase d’initiation, puis de fixer des délais indicatifs.
  • Cette première phase doit préparer les institutions et la transparence. Son lancement ne conférerait pas au futur Conseil l’ensemble des pouvoirs de gouvernance.

Le 13 octobre, l’ICANN a rendu publique une lettre de Keith Drazek, président par intérim du Registries Stakeholder Group (RySG), qui veut faire passer la gouvernance du Root Server System (RSS) de la conception à la mise en œuvre. Le courrier formule trois demandes au Conseil : adopter le modèle fonctionnel achevé par le groupe de travail RSS Governance Working Group (GWG), charger l’organisation de fournir les moyens et le secrétariat nécessaires à la phase d’initiation, puis fixer des échéances « indicatives » pour cette phase et les suivantes. La lettre est datée du 7 octobre.

Le RySG motive cette demande par la dépendance de ses membres, les opérateurs de registres génériques de premier niveau, à un fonctionnement sûr et stable des serveurs racine. Il estime qu’une structure formelle renforcerait la responsabilité des opérateurs de serveurs racine et permettrait au RSS d’évoluer avec les besoins de fiabilité et de résilience du DNS. C’est l’argument du groupe en faveur d’une structure ; le courrier ne signale ni défaillance d’un opérateur ni menace actuelle sur le service.

Le Conseil n’a pas encore adopté le modèle

Dans son aperçu du séminaire d’octobre, publié le 13 octobre, Tripti Sinha, présidente du Conseil, indiquait que les administrateurs poursuivraient l’examen du modèle. Les équipes de l’ICANN devaient présenter une première vue des travaux de mise en œuvre, d’un calendrier et des garde-fous possibles, notamment pour la charte d’un RSS Council et les politiques nécessaires à la structure complète. La page officielle des activités du Conseil annonçait encore sa réunion ordinaire du 18 octobre comme à venir lors de la vérification du 17 octobre. Les sources publiques consultées ne montrent ni résolution d’adoption ni engagement budgétaire de lancement. Un point à l’ordre du jour n’est pas une décision.

Une phase de préparation, pas un transfert de pouvoir

Le modèle fonctionnel, publié le 18 février, prévoit trois phases. L’initiation créerait le Conseil et son secrétariat, instaurerait la transparence et préparerait les étapes suivantes. Son mandat serait volontairement limité : il ne s’agit pas encore d’exercer les pouvoirs de gouvernance envisagés. La phase d’établissement formaliserait ensuite les procédures, les politiques et les mécanismes de responsabilité. La structure ne deviendrait pleinement habilitée qu’après l’achèvement des premières phases et des jalons définis.

Cette progression répond à une question de continuité. Le modèle écarte l’idée d’activer d’un seul coup une nouvelle gouvernance pour un système dont la valeur dépend de la stabilité. Il sépare donc la création d’un forum et de ses moyens de travail de l’attribution des pouvoirs de décision et de contrôle. Si le Conseil suit la demande du RySG, le premier changement devrait porter sur l’organisation et la procédure, non sur l’exploitation des serveurs racine.

Le modèle sépare aussi l’exploitation de la dépendance. Les Root Server Operators siègent individuellement parce qu’ils font fonctionner le système. Les registres génériques et les registres de codes de pays sont reconnus comme communautés participantes selon des critères de dépendance opérationnelle directe et d’organisation suffisante. Être tributaire de la racine donne aux registres une place dans les discussions prévues, mais ne les transforme pas en opérateurs.

Les conditions du lancement restent ouvertes

La lettre d’octobre ne précise ni montant, ni source de financement, ni calendrier détaillé. Dans sa contribution à la consultation de 2025, le RySG avait déjà demandé de plafonner le nombre de sièges occupés par une seule organisation, d’instaurer tôt des contrôles financiers transparents, de rechercher des financements durables et de documenter plus tôt les liens entre la structure, le RSSAC et l’ICANN.

Ces choix conditionnent la crédibilité du dispositif. L’Internet Architecture Board a également soutenu le principe d’une gouvernance durable, tout en jugeant le projet trop peu précis sur la responsabilité, les modalités pratiques et l’équilibre des décisions. Ce constat appartient à l’IAB ; il n’est pas une conclusion du Conseil. Le modèle final et le traitement des commentaires offrent un cadre, mais les garde-fous que le Conseil examinait doivent montrer comment ces questions seront traitées.

La décision immédiate est donc plus étroite que de trancher la place de la gouvernance dans le DNS. Le Conseil peut-il associer à l’adoption une phase initiale réelle mais limitée, avec secrétariat identifié, moyens publiés, charte du Conseil et jalons vérifiables ? Un calendrier éviterait qu’un travail de plusieurs années reste indéfiniment provisoire. Mais la vitesse ne suffit pas : les règles de nomination, de contrôle des dépenses et de passage à la phase suivante doivent être publiques et réexaminables.

Autres documents officiels de référence : RSSAC058: Success Criteria for the RSS Governance Structure; RSSAC037: A Proposed Governance Model for the DNS Root Server System; Functional Model for Root Server System Governance proceeding; ICANN Correspondence archive; Approved Resolutions: Special Meeting of the ICANN Board, 18 November 2021.