L'ICANN l'a proclamé. C'est RIPE NCC qui a dû le faire.

Résumé

• Le registre internet régional de l'Afrique a été reconnu par l'ICANN en avril 2005, et cette reconnaissance est présentée comme la suite de l'achèvement d'un processus de transition, non comme le transfert lui-même.
• Le registre sortant, RIPE NCC, indique avoir assuré pour la région africaine l'allocation d'adresses, la gestion de la base de données du registre et la délégation DNS inverse, puis avoir facilité la migration de ces responsabilités et des enregistrements correspondants — un acte distinct, par une autre institution, sur une autre autorité.

Deux institutions figurent dans le nom de ce sujet, et une seule était en position de proclamer quoi que ce soit. L'ICANN a reconnu AFRINIC comme cinquième registre internet régional en avril 2005, un acte dont la trace publique est une annonce construite autour de l'achèvement d'un processus de transition. RIPE NCC, qui exploitait les services de registre pour la région africaine, décrit l'autre moitié : il assurait l'allocation d'adresses, la gestion de la base de données du registre et les délégations DNS inverse, et, dès la reconnaissance d'AFRINIC, il a facilité la migration de ces responsabilités et des enregistrements vers le nouveau registre (ICANN ; RIPE NCC).

Ce couplage paraît anodin jusqu'au moment où l'on tente de l'auditer. Reconnaissance et migration ne sont pas deux descriptions d'un même événement. Ce sont deux actes, accomplis par deux institutions, sur deux types d'autorité différents, et ils produisent deux types de preuve différents. Le premier est une désignation : une instance dotée d'une autorité régionale déclare qu'une autre instance est le registre d'une région. Le second est une garde : une organisation qui détenait des enregistrements, une base de données et des responsabilités de délégation cesse de les détenir, et une autre commence.

La désignation est le genre d'acte qui produit presque automatiquement un artefact public, parce que toute sa raison d'être est d'être lisible par ceux qui ne sont pas dans la salle. La garde est le genre d'acte qui produit des artefacts opérationnels — populations d'enregistrements, migrations de bases, changements de délégation, correspondance avec les titulaires dont les entrées se déplacent — dont aucun n'a l'obligation d'être un document public.

La doctrine sur ce sujet trace la frontière nettement : le dossier disponible peut être décrit comme inégal entre les deux actes, mais une documentation inégale n'est pas une intégrité inégale, et elle ne prouve pas que la garde a changé de mains sans rendabilité.

La question honnête est donc plus étroite que sa version médiatique, et plus utile. Quand une succession de registre est certifiée par une instance et exécutée par une autre, de quoi un tiers aurait-il besoin pour vérifier que le second acte s'est déroulé comme le premier le laisse entendre ?

Ce que la reconnaissance certifie réellement

L'annonce de l'ICANN n'est pas un instrument de transfert. C'est l'affirmation qu'une transition avait été achevée et que l'instance qui en résultait était le registre régional. Lue ainsi, l'annonce certifie le travail de quelqu'un d'autre. L'ICANN n'allouait pas les adresses africaines, ne tenait pas la base de données du registre et ne détenait pas les délégations DNS inverse ; selon le propre compte de RIPE NCC, c'est RIPE NCC qui faisait cela. Le reconnaissant attestait l'achèvement d'un processus opérationnel qu'il n'exécutait pas.

Ce n'est pas une critique de l'ICANN. La certification par une instance externe est exactement à quoi doit ressembler une délégation d'autorité régionale, et un reconnaissant qui tenterait d'exécuter lui-même la migration ferait tout autre chose. Mais cela signifie que le document de reconnaissance ne peut pas porter le poids probatoire que sa notoriété suggère. Il dit que la transition a été jugée achevée. Il ne dit pas, en détail, ce que « achevée » recouvre.

Trois fonctions nommées, et ce qu'elles impliquent

Le compte de RIPE NCC nomme trois classes de fonctions : l'allocation d'adresses, la gestion de la base de données du registre et la délégation DNS inverse. Cette énumération est l'élément le plus concret du dossier disponible, et il faut la prendre au sérieux comme énumération, non comme inventaire certifié.

Chacune des trois a un mode de défaillance différent, et c'est pourquoi les déplacer ensemble est plus difficile que de les déplacer en séquence. L'allocation d'adresses est prospective : à partir d'une date de bascule, le registre receveur décide qui obtient de l'espace. La gestion de la base est cumulative : elle concerne des entrées déjà existantes, créées selon les procédures du registre sortant, avec des contacts et des valeurs de statut qui ne se projettent pas forcément proprement sur le schéma du receveur.

La délégation DNS inverse est tournée vers l'extérieur : elle est visible dans le DNS lui-même, par quiconque interroge, et c'est la seule partie du transfert qu'un tiers peut partiellement observer sans accès à quoi que ce soit.

Un transfert qui nomme les trois sans les dater séparément a un angle mort précis. L'allocation a pu cesser à une date, la migration de base s'étaler sur des mois, et les changements de délégation se poursuivre après. Sans date de bascule, un lecteur ne peut pas dire si un enregistrement créé au second semestre 2005 l'a été sous les règles du registre sortant ou du registre entrant. Cela compte, parce que les droits et obligations attachés à un enregistrement suivent les règles en vigueur au moment où il a été créé.

Pourquoi le second acte est structurellement plus discret

La tentation est de lire l'asymétrie comme un choix : l'une a publié, l'autre non. L'explication structurelle est plus plausible et moins intéressante, ce qui est généralement bon signe. Une désignation s'adresse au monde ; elle est censée être trouvée. Une migration s'adresse à une relation de travail entre deux organisations et aux titulaires dont les entrées se déplacent ; elle est censée fonctionner. La première est un acte de parole. La seconde est un projet.

Les projets laissent des traces internes — plans de migration, rapports de rapprochement, listes d'exceptions, correspondance sur les entrées qui ne se sont pas déplacées proprement. Ce sont exactement les documents qui permettraient à un tiers de vérifier la succession, et exactement ceux qui tendent à ne pas être publiés, parce que les publier n'a jamais été l'objectif. Cela n'est propre ni aux registres internet, ni scandaleux. C'est l'écart ordinaire entre l'acte qui confère l'autorité et l'acte qui transfère la garde.

La conséquence, elle, est réelle. Si les instruments sous-jacents restent hors du dossier public, le résultat pratique est une auditabilité indépendante réduite. Quiconque veut savoir comment la garde des ressources numériques africaines a réellement changé de mains doit s'en remettre aux récits institutionnels plutôt qu'à des instruments disponibles de façon indépendante. C'est une affirmation sur ce que le dossier peut soutenir. Ce n'est pas une affirmation que la rendabilité était absente, et la différence entre ces deux phrases est tout l'argument.

Ce qui n'est pas établi ici

L'instrument ou l'accord de transfert entre RIPE NCC et AFRINIC n'a pas été obtenu dans cette revue. Le texte de la résolution du conseil d'administration de l'ICANN d'avril 2005 n'a pas été obtenu dans cette revue. Les entrées de réaffectation de l'espace d'adressage de l'IANA, qui montreraient des mouvements de blocs individuels, n'ont pas été obtenues dans cette revue, et aucune date de bascule du service de registre pour la région africaine n'a été obtenue.

Des tentatives répétées de récupération pour ces classes d'instruments ont abouti à des échecs de permission, de capacité et de quota côté fournisseur, ce qui est un fait sur ce processus de recherche, non un fait sur les instruments.

Rien de ce qui précède ne doit être lu comme une conclusion qu'aucun accord n'existe, que RIPE NCC n'a rien publié sur le transfert, que reconnaissance et transfert opérationnel ont eu lieu le même jour, ou qu'un bloc d'adresses particulier a ou n'a pas été réenregistré. Le jour précis de la reconnaissance d'avril 2005 est lui-même rapporté de façon divergente selon les pages indexées, de sorte que seul le mois est retenu ici.

Pourquoi la distinction compte au-delà de 2005

Les successions de registres sont assez rares pour que chacune serve de précédent à la suivante. Le motif visible ici — désignation externe documentée par une annonce, garde opérationnelle documentée par une rétrospective institutionnelle — est le motif que toute succession future suivra probablement, parce qu'il découle de la finalité de chaque acte.

Pour les titulaires de ressources numériques, la question pratique n'est pas de savoir qui a été reconnu. C'est de savoir quelles règles s'appliquaient à leur entrée le jour où elle a été créée ou modifiée, et si cette entrée a survécu intacte à la migration. Pour un registre receveur, la question est de savoir s'il a hérité d'une population réconciliée ou non, car les entrées héritées deviennent les litiges de la décennie suivante. Pour le système global, la question est de savoir si une reconnaissance peut être vérifiée après coup par quelqu'un qui n'était pas dans la salle.

Aucune de ces questions ne trouve de réponse dans une annonce. Toutes sont solubles en principe, par des instruments qu'une succession de registre pourrait publier systématiquement : une date de bascule, un état de la population d'enregistrements transférée, une description du traitement des entrées qui n'ont pas migré proprement, et un pointeur vers l'endroit où les changements de délégation ont été consignés. Ce n'est pas une exigence de transparence comme vertu abstraite. C'est la description de la preuve minimale qui permettrait à un successeur de se reconnaître dans le travail de son prédécesseur.

Tant que cette preuve n'est pas publiée systématiquement, la description honnête d'une succession de registre est celle que le dossier de ce sujet soutient : le registre receveur publie son histoire institutionnelle (AFRINIC), l'instance reconnaissante publie la désignation, le registre sortant publie un récit rétrospectif de ce qu'il faisait, et le transfert de garde lui-même doit être inféré de la forme des trois.

Cette inférence mérite d'être faite avec soin, et mérite d'être nommée comme une inférence. L'alternative — traiter l'annonce comme la preuve que le transfert a été vérifié — confond la lisibilité du premier acte avec l'exhaustivité du second.

Pour le dossier institutionnel complet sur ce sujet, voir l'entrée du répertoire BTW Réservé au Cercle stratégique.