Résumé

  • Les comptes rendus de RIPE 39 et RIPE 40 relient Nurani Nimpuno à des sujets concrets de service d’enregistrement: réception de ressources, délégation inverse, documentation, automatisation, traitement opérationnel et statistiques communes aux registres Internet régionaux.
  • RIPE-228, corédigé avec Sabrina Waschke, montre qu’une demande de numéro de système autonome devait être étayée par une politique de routage, des relations d’interconnexion et des objets déjà enregistrés; ce document historique ne constitue toutefois pas une procédure actuelle.
  • Les archives de l’ASO et d’ICANN prolongent cette trace vers l’interconnexion et la coordination de la fonction de numérotation de l’IANA, tout en laissant les décisions et les résultats à leurs institutions, équipes et communautés respectives.

Partir d’une trace d’exploitation plutôt que d’un portrait général

Le meilleur angle pour comprendre le rôle de Nurani Nimpuno n’est pas une succession de titres. Les titres situent une personne, mais ils disent rarement ce qui devait être vérifié, quel objet technique était en jeu ou comment une décision pouvait être contrôlée après coup. Les cinq pièces retenues ici offrent autre chose: des dates, des fonctions circonscrites, des documents de procédure et des points de contact entre registre et réseau.

Les minutes du groupe des registres Internet locaux à RIPE 39 attribuent à Nimpuno une présentation de Registration Services. Elles évoquent une nouvelle tranche IPv4 reçue de l’IANA, la délégation inverse, la formation des LIR, les documents de demande, les outils, l’automatisation et le traitement de requêtes IPv6. RIPE-228 la nomme ensuite, avec Sabrina Waschke, parmi les auteurs de notes destinées aux demandes d’ASN. RIPE 40 consigne une répartition entre travail de politique et travail opérationnel, puis une présentation de statistiques conjointes des RIR.

Le registre tient le journal, il ne fait pas circuler les paquets

Un registre de ressources numériques conserve des faits administratifs et techniques: qui détient une ressource, quel statut lui est attribué, quels objets décrivent une politique, quels contacts sont responsables et quelles délégations ont été demandées. Cette fonction est essentielle parce que l’unicité d’une adresse ou d’un ASN dépend d’une chaîne de décisions enregistrées. Elle reste cependant distincte du réseau en fonctionnement.

Une plage d’adresses peut être correctement allouée sans être annoncée dans BGP. Un préfixe peut être visible alors que l’enregistrement de son détenteur est devenu ancien. Un objet de politique peut décrire une intention d’importation ou d’exportation qui n’est plus celle des routeurs. Une délégation inverse peut être exacte dans le registre alors que ses serveurs ne répondent plus. Inversement, une infrastructure peut fonctionner pendant un temps avec un dossier incomplet, jusqu’au jour où un incident exige un interlocuteur ou une preuve d’autorisation.

La valeur du registre tient donc à la correspondance qu’il permet d’établir, pas à une souveraineté supposée. Il doit rendre les changements traçables, protéger l’unicité des ressources, soutenir les transferts et conserver des métadonnées utiles à la sécurité et à la continuité. Les opérateurs, eux, configurent les équipements, concluent des accords, annoncent les routes et réparent les pannes.

RIPE 39: rendre visible le travail du service d’enregistrement

Le compte rendu de RIPE 39, au printemps 2001, apporte une granularité rare. Il n’indique pas seulement que Nimpuno exerçait une responsabilité au sein de Registration Services; il énumère des dossiers concrets présentés à la communauté des LIR. La réception d’un bloc IPv4 /8 depuis l’IANA en est un exemple. Recevoir une ressource au sommet de la chaîne ne termine rien: les systèmes internes doivent reconnaître les limites du bloc, les procédures d’allocation doivent s’y appliquer et les enregistrements ultérieurs doivent rester cohérents.

Le document mentionne aussi les demandes IPv6 et les contraintes de politique d’allocation. À cette époque comme aujourd’hui, l’examen d’une demande ne consiste pas à remplir une case isolée. Il faut relier le besoin déclaré, la topologie envisagée, les objets existants, les critères de la politique applicable et la responsabilité future de l’organisation. Une décision acceptable sur le papier peut encore produire un dossier peu utile si ses données ne sont pas entretenues.

Nimpuno présente ce travail, mais le compte rendu ne lui attribue pas chaque mise en œuvre. Les logiciels, les procédures, les agents du RIPE NCC, les membres qui soumettaient des demandes et les groupes qui élaboraient les politiques avaient des rôles différents. Cette séparation protège la précision de l’article: une présentation est une preuve de responsabilité et de participation, non une mesure de tous les résultats du service.

La délégation inverse met en contact numérotation et DNS

La délégation DNS inverse, citée dans le rapport de Registration Services, constitue un bon test des limites institutionnelles. Le registre peut vérifier qu’une organisation est autorisée à demander une délégation pour une plage donnée et enregistrer les serveurs prévus. Il ne peut pas, par la seule acceptation du dossier, garantir la disponibilité durable de ces serveurs ou l’exactitude de chaque réponse.

Plusieurs plans doivent donc rester distincts. Le premier est celui de l’autorisation: la demande provient-elle de l’entité responsable de la ressource ? Le deuxième est celui de l’enregistrement: les noms de serveurs et la hiérarchie déléguée sont-ils saisis correctement ? Le troisième est opérationnel: les serveurs sont-ils joignables, font-ils autorité, donnent-ils des réponses cohérentes et disposent-ils d’un propriétaire capable d’intervenir ? Le quatrième est temporel: ces conditions restent-elles vraies après un changement d’hébergement, une réorganisation ou un transfert de ressources ?

La source ne dit pas que Nimpuno exploitait personnellement les zones ou les serveurs concernés. Elle montre qu’elle rapportait une activité du service située à cette frontière. C’est une attribution plus modeste, mais techniquement plus utile: elle permet de comprendre pourquoi la coordination des ressources Internet réclame des enregistrements exacts et une vérification indépendante par les systèmes qui tournent réellement.

Former les demandeurs fait partie de la qualité des données

RIPE 39 mentionne la formation des LIR, un tutoriel consacré aux demandes d’adresses et le travail documentaire. Ces activités pourraient sembler périphériques face aux bases de données et aux routeurs. Elles déterminent pourtant la qualité de ce qui entre dans le système. Un contrôle automatique ne peut corriger une intention qui n’a jamais été formulée avec les bons concepts.

Un demandeur peut confondre le besoin d’adresses avec le besoin d’une route indépendante. Il peut omettre une relation d’amont, utiliser un objet de contact ancien, citer un objet de routage absent ou décrire une croissance sans préciser la période et l’unité. Une demande de délégation peut désigner des serveurs non préparés. Une demande d’ASN peut employer ce numéro comme un simple identifiant d’organisation alors que la justification porte sur une politique de routage autonome.

La documentation réduit ces erreurs en expliquant le contrat de preuve: quelles informations sont nécessaires, à quelle décision elles servent et quelles limites subsistent après acceptation. La formation apporte une dimension interactive. Elle révèle les ambiguïtés répétées, permet de corriger les exemples et rapproche le vocabulaire administratif de celui des opérateurs.

Les minutes attestent que Nimpuno rapportait ces activités. Elles ne permettent pas de chiffrer une baisse d’erreurs, un gain de délai ou une amélioration universelle. Le résultat mesuré manque. L’importance opérationnelle demeure: sans pédagogie sur les données attendues, le registre risque de conserver proprement des réponses à des questions mal comprises.

Automatiser les contrôles sans automatiser la vérité

Les outils et l’automatisation figurent également dans le compte rendu de RIPE 39. Une automatisation bien conçue peut vérifier la présence de champs obligatoires, la syntaxe d’un objet, l’existence d’une référence, l’appartenance d’une ressource à une plage administrée ou la cohérence élémentaire d’une délégation. Elle peut détecter rapidement des erreurs répétitives et réserver l’attention humaine aux cas qui exigent un jugement.

Son risque apparaît lorsque le passage d’un test est présenté comme une vérité sur le réseau. Une adresse électronique conforme à la syntaxe ne prouve pas qu’un ingénieur répond. Un objet RPSL valide ne prouve pas que les filtres d’un routeur ont été générés à partir de lui. Un serveur DNS joignable lors du contrôle peut devenir indisponible. Un calcul de prévision peut satisfaire la formule tout en décrivant imparfaitement le déploiement futur.

Il faut donc rendre le contrôle explicable. Chaque résultat devrait identifier l’entrée examinée, la règle appliquée, l’heure du test et ce qui n’a pas été vérifié. Une exception devrait garder une justification et un responsable. Si une décision automatique influence l’allocation d’une ressource unique ou la publication d’une délégation, le chemin de correction doit être aussi clair que le chemin nominal.

RIPE-228 relie la demande d’ASN à une intention de routage

Daté du 2 octobre 2001, RIPE-228 décrit des notes d’accompagnement pour une demande de numéro de système autonome auprès du RIPE NCC. Le document nomme deux auteurs, Nurani Nimpuno et Sabrina Waschke. Toute lecture fidèle doit conserver cette corédaction: effacer Waschke transformerait un document partagé en accomplissement individuel.

Le cœur du texte est un contrat d’information. Le demandeur devait expliquer les relations de routage qui justifiaient l’ASN, exprimer des politiques d’importation et d’exportation et s’appuyer sur des objets préexistants de la base RIPE. Le numéro demandé n’était donc pas traité comme un badge d’identité. Il devait correspondre à un domaine de routage présentant une politique cohérente envers d’autres systèmes autonomes.

RIPE-228 a ensuite été rendu obsolète. Il ne faut donc pas l’employer comme formulaire actuel, ni supposer que ses exigences décrivent la pratique présente. Sa valeur est historique et analytique. Il prouve qu’en 2001 les éléments de routage faisaient partie de la justification attendue, et que Nimpuno a participé avec Waschke à la formalisation de ces notes. Il ne prouve pas que chaque ASN accordé a ensuite respecté indéfiniment la politique annoncée.

Une déclaration RPSL reste une déclaration

Le langage RPSL permet de représenter une politique de routage dans des objets structurés. Une expression d’importation peut indiquer ce qu’un système autonome prévoit d’accepter d’un voisin; une expression d’exportation, ce qu’il prévoit de lui annoncer. Cette formalisation facilite la lecture, l’analyse et, dans certains environnements, la génération de filtres.

Mais l’objet n’est pas le chemin du paquet. Un opérateur doit convertir l’intention en configuration, ou utiliser une chaîne d’outils qu’il maîtrise et contrôle. Le voisin peut appliquer d’autres filtres. Un objet peut ne plus refléter une nouvelle relation commerciale. Une fuite de routes peut contredire les politiques déclarées. Une autorisation d’origine RPKI peut fournir un signal supplémentaire sur le couple préfixe-ASN, sans décrire à elle seule toute la politique de chemin.

Une supervision responsable rapproche donc plusieurs preuves: l’objet de registre actuel, la configuration voulue, les annonces observées, les chemins vus depuis plusieurs points et l’identité du responsable de toute divergence. Aucun de ces éléments ne suffit universellement. Ensemble, ils permettent de distinguer une modification légitime, une donnée ancienne, une erreur de configuration et un événement de sécurité.

RIPE-228 se place dans cette chaîne du côté de l’intention documentée. Son intérêt n’est pas de promettre que le registre commande les routeurs. Il exigeait qu’une demande donne à voir les relations qui fondaient le besoin. La contribution attribuable à Nimpuno et Waschke concerne cette procédure historique. Les décisions d’attribution relevaient du RIPE NCC selon les politiques applicables; les sessions, filtres et annonces relevaient ensuite des réseaux concernés.

Portabilité des adresses et croissance de la table de routage

Les minutes de RIPE 39 consignent également une discussion conduite par Nimpuno sur les espaces portables, les allocations agrégées par un fournisseur, le multihoming et la croissance de la table de routage. Cette discussion appartient à RIPE 39, non au compte rendu de RIPE 40. La distinction de source importe car elle préserve le contexte exact de l’attribution.

Les intérêts en présence sont difficiles à réduire à une règle unique. Une organisation peut chercher des adresses indépendantes pour changer de fournisseur, se connecter à plusieurs réseaux ou éviter un renumérotage coûteux. Cette indépendance peut conduire à l’annonce d’un préfixe distinct. Une multiplication de préfixes plus spécifiques augmente la charge des tables et peut rencontrer des politiques de filtrage. À l’inverse, imposer une forte agrégation peut accroître la dépendance envers un fournisseur ou exclure des architectures légitimes.

La discussion rapportée fait apparaître des désaccords sur les tailles minimales, la responsabilité du registre à l’égard de la routabilité et les effets incitatifs des critères d’allocation. Nimpuno a présenté le problème et des questions. Le groupe, les processus de politique et les opérateurs conservaient leurs droits de décision. Il serait donc faux de lui attribuer seule une politique ultérieure ou un effet mesuré sur la table globale.

RIPE 40: distinguer la politique de son exécution

Le compte rendu de RIPE 40, en octobre 2001, place Nimpuno dans une division définie du travail de politique et du travail opérationnel au RIPE NCC. Cette indication est courte mais importante. Elle empêche de raconter la coordination des ressources comme si une même personne ou une même réunion décidait d’une règle, traitait les demandes, configurait les systèmes et constatait les résultats.

Une politique de ressources énonce les conditions selon lesquelles une allocation, une assignation ou un numéro peut être accordé. Sa mise en œuvre transforme ces conditions en formulaires, contrôles, files de traitement, décisions et enregistrements. L’exploitation du registre assure ensuite la disponibilité et la cohérence de l’information. Les réseaux utilisent enfin les ressources dans des topologies qu’ils contrôlent. Chaque couche produit ses propres preuves et ses propres échecs.

La mention de RIPE 40 établit que Nimpuno exerçait une responsabilité dans cette articulation. Elle ne donne pas le détail de chaque décision et ne permet pas de lui attribuer toute la politique ou toute l’exploitation. D’autres membres du personnel, les groupes de travail, les LIR et les opérateurs participaient au processus.

En gardant RIPE 40 dans ce périmètre, on peut aussi éviter une erreur précise: la discussion sur l’espace portable et la pression sur les tables est attestée par RIPE 39. RIPE 40 atteste ici la division des tâches et la présentation de statistiques communes.

Les statistiques conjointes des RIR exigent des définitions stables

RIPE 40 attribue à Nimpuno une présentation de statistiques conjointes des registres Internet régionaux. La comparaison entre régions peut éclairer la distribution des ressources, les volumes de demandes et les changements de pratique. Elle devient trompeuse lorsque les catégories paraissent identiques sans l’être.

Un nombre d’allocations ne correspond pas au nombre de préfixes visibles. La taille nominale de ressources distribuées n’est pas une mesure directe de leur utilisation. Le nombre de membres ne donne pas celui des réseaux autonomes. Une file de demandes mélange parfois des dossiers en attente du registre et des dossiers en attente du demandeur. Des changements de définition peuvent créer une rupture de série qui ressemble à un changement du monde réel.

Une statistique exploitable doit donc préciser l’objet compté, la période, le système d’origine, la version de la politique, les exclusions et les corrections. Elle doit distinguer demandes, approbations, allocations, assignations, ASN, préfixes annoncés et organisations. Lorsque des données sensibles empêchent une publication détaillée, la méthode et les agrégats peuvent néanmoins rester explicites.

La présentation attribuée à Nimpuno est une preuve de participation à la visibilité inter-RIR. Elle n’est pas une validation indépendante de chaque chiffre ni la preuve que les données ont déterminé une décision. Son intérêt institutionnel réside dans le besoin de rendre des systèmes régionaux comparables sans effacer leurs contextes.

L’interconnexion fait passer les dossiers à l’épreuve de la production

La fiche archivée de l’ASO élargit la trace de Nimpuno vers le peering, l’échange de trafic, le DNS et les points d’échange. Elle mentionne des expériences dans plusieurs environnements liés aux ressources et à l’interconnexion. Comme il s’agit d’un profil archivé, il documente un parcours à des dates données; il ne doit pas être lu comme l’énoncé de fonctions actuelles.

L’interconnexion est le lieu où plusieurs abstractions du registre deviennent concrètes. Un ASN apparaît dans une session BGP. Une politique d’importation devient un filtre. Une plage d’adresses transporte du trafic. Un contact est sollicité lors d’une anomalie. Une délégation DNS doit être joignable par des chemins réels.

Un point d’échange fournit une infrastructure commune à des réseaux indépendants. Il peut proposer des ports, un domaine de commutation, des services et parfois des serveurs de routes. Il ne décide pas pour autant de toutes les annonces des membres, de leurs contrats de transit ou de leurs filtres. Une inscription au répertoire des entités n’est pas une preuve de session active; une session active n’est pas une preuve de trafic utile; un trafic mesuré n’est pas une garantie de disponibilité applicative.

Le rapprochement entre registre et interconnexion est donc précieux. Il permet de demander si le détenteur enregistré, l’ASN observé, le port, la session et le contact opérationnel décrivent le même acteur. La source soutient l’idée que le parcours de Nimpuno a traversé ces surfaces. Elle ne prouve pas qu’elle a exploité chaque équipement, dirigé chaque échange cité ou contrôlé les politiques des réseaux membres.

L’ASO organise une responsabilité distribuée

L’Address Supporting Organization relie les communautés des cinq RIR aux mécanismes d’ICANN qui concernent les politiques mondiales de ressources numériques. La fiche archivée indique que Nimpuno a représenté la région RIPE au sein du Conseil d’adressage. La mise à jour d’ICANN de novembre 2015 consigne son élection à ce conseil.

Un mandat élu confère une responsabilité de délibération, d’examen et de coordination. Il ne transforme pas le titulaire en propriétaire des adresses, en opérateur du routage mondial ou en autorité capable de rendre une base exacte par déclaration. La légitimité du rôle vient du processus, des limites du mandat et de la possibilité de relier les avis aux communautés qui les produisent.

Le dossier de Nimpuno permet d’examiner la continuité entre son travail antérieur de service d’enregistrement et ce rôle de coordination. Il n’autorise pas à lui attribuer seule les décisions du Conseil, les politiques issues des communautés ou les résultats observés sur Internet. Le conseil est collégial et les propositions suivent des procédures distinctes.

Une attribution rigoureuse n’est pas une formule de prudence ajoutée après coup. Elle fait partie du contrôle du système. Savoir qui a présenté, qui a corédigé, qui a voté, qui a mis en œuvre et qui exploite permet de réparer une erreur sans inventer un pouvoir qui n’existe pas.

Le rôle de vice-présidente de CRISP reste un rôle d’équipe

La même mise à jour d’ICANN identifie Nimpuno comme vice-présidente de l’équipe chargée de consolider la proposition des communautés RIR pour la supervision des fonctions de numérotation de l’IANA. Cette équipe, connue sous le nom de CRISP, travaillait dans le contexte plus large de la transition de la supervision de l’IANA.

Une vice-présidente peut structurer les travaux, rapprocher des formulations, faciliter la continuité et représenter l’avancement du processus. Ces fonctions sont substantielles. Elles ne signifient pas que la proposition est son œuvre exclusive. Le texte consolidait des contributions issues de plusieurs communautés et résultait d’un travail collectif. Les institutions concernées conservaient ensuite des responsabilités propres pour l’acceptation et la mise en œuvre.

La source de 2015 établit le mandat et l’élection. Elle ne démontre pas que Nimpuno contrôlait les fonctions IANA, qu’elle a choisi seule l’architecture finale ou qu’elle répond de chaque résultat ultérieur. Elle n’évalue pas non plus la performance de la transition à l’aide d’indicateurs opérationnels.

Cette frontière permet néanmoins de lire le rôle avec précision. Le travail de consolidation porte sur des engagements, des responsabilités et des mécanismes de continuité. Il transforme des demandes communautaires en un objet commun susceptible d’être examiné. Dans un système mondial, cette fonction évite que la mémoire d’une procédure repose sur un seul acteur ou une seule institution.

Séparer systématiquement rôle, décision et résultat

Les récits d’infrastructure deviennent fragiles lorsqu’un rôle est converti silencieusement en résultat. Trois questions simples permettent d’éviter ce glissement. Quel rôle la source attribue-t-elle ? Quelle décision ou action documente-t-elle ? Quel résultat le système permet-il réellement d’observer ?

Dans RIPE 39, le rôle comprend la présentation d’activités de Registration Services et la conduite d’une discussion. L’action documentée consiste à exposer des sujets, des contraintes et des questions. Le document ne mesure pas chaque délai, chaque délégation ou chaque résultat de routage.

Dans RIPE-228, Nimpuno et Waschke sont corédactrices de notes. Le document définit des informations attendues. Il ne prouve pas que toutes les politiques déclarées ont été déployées ni entretenues.

Dans RIPE 40, Nimpuno apparaît dans une division de travail et présente des statistiques conjointes. La source ne lui attribue ni toute la collecte, ni toutes les décisions dérivées de ces chiffres.

Dans la fiche ASO, des rôles liés aux ressources et à l’interconnexion sont consignés. Le profil ne mesure pas la performance d’un point d’échange ou d’un service DNS. Dans la mise à jour d’ICANN, une élection et une vice-présidence sont attestées. Le résultat institutionnel appartient à un conseil, une équipe et des communautés.

Ce que les cinq sources ne permettent pas d’affirmer

Le corpus retenu n’est pas une biographie complète et ne doit pas être étendu au-delà de ses dates. Il n’établit pas l’emploi actuel de Nimpuno ni l’ensemble de ses fonctions présentes. La fiche ASO est archivée; toute affirmation contemporaine demanderait une preuve institutionnelle actuelle.

Les sources ne prouvent pas qu’elle a seule élaboré les politiques IPv4, IPv6 ou ASN. Elles ne lui attribuent pas la conception de la base RIPE, l’exploitation de tous les serveurs DNS concernés, la configuration des routeurs des membres ou la direction de chaque point d’échange associé à son parcours. RIPE-228 a une corédactrice nommée, Sabrina Waschke, et son statut historique doit rester visible.

Le corpus ne démontre pas l’adoption universelle d’une procédure, la justesse durable de tous les objets, une baisse quantifiée de la table de routage, une amélioration mesurée de disponibilité ou un consensus général. Il ne garantit pas la routabilité d’une allocation et n’évalue pas chaque statistique présentée. Il ne fait pas de Nimpuno l’auteure unique de la proposition CRISP, la responsable de l’IANA ou la décideuse de toutes les étapes de la transition.

Il ne contient enfin aucune base pour publier des coordonnées privées, des identifiants, des informations de clients, des détails de sécurité ou des procédures internes sensibles. Les éléments pertinents sont les responsabilités publiques et les mécanismes techniques décrits.

Une méthode de correspondance pour les ressources et l’interconnexion

À partir de cette trace, sans prétendre que Nimpuno a elle-même formulé la méthode, on peut établir une grille de contrôle. Pour chaque préfixe ou ASN, il faut identifier le détenteur enregistré, le statut, la base de la décision, la date du dernier changement et le responsable capable d’agir. Pour une demande, il faut conserver le besoin technique, les objets référencés et les limites de la validation.

Pour le routage, la politique déclarée doit être comparée à la configuration prévue et aux annonces observées. Pour le DNS inverse, l’autorisation et l’inscription de la délégation doivent être rapprochées des réponses des serveurs. Pour les contacts, la complétude du champ doit être distinguée de l’utilité réelle lors d’un incident. Pour l’interconnexion, l’adhésion, le port, la session BGP, les préfixes acceptés, le trafic et la disponibilité applicative doivent rester des signaux séparés.

Chaque écart mérite un propriétaire et une échéance. Un changement de route sans mise à jour du dossier peut être légitime, mais il doit devenir explicable. Une délégation correcte vers un service en panne exige une réparation opérationnelle. Une fiche de entité sans session ne doit pas être présentée comme une interconnexion active. Une politique ancienne doit être versionnée plutôt que silencieusement réinterprétée.

Cette méthode traite le registre comme un journal indispensable et le réseau comme l’épreuve finale. Elle évite deux caricatures: le registre qui commanderait la réalité, et la réalité instantanée qui rendrait les registres inutiles. La coordination se trouve dans la capacité à relier les deux, à conserver l’historique et à réparer les divergences.

Conclusion de l’analyse publique

Les minutes de RIPE 39 relient Nurani Nimpuno à un ensemble concret d’activités du service d’enregistrement: réception d’espace, délégation inverse, documentation, formation, automatisation, demandes IPv6 et discussion de contraintes d’allocation liées au routage. Elles montrent un travail d’interface entre les besoins des LIR, les règles du registre et les conséquences possibles dans les réseaux.

RIPE-228 ajoute une pièce plus formelle. Avec Sabrina Waschke, Nimpuno a corédigé des notes historiques demandant qu’une requête d’ASN présente ses relations et ses politiques de routage. Le document montre l’importance d’une intention enregistrée, tout en rappelant qu’une intention ne configure pas un routeur.

RIPE 40 consigne la séparation entre politique et exploitation ainsi qu’une présentation de statistiques communes aux RIR. La fiche archivée de l’ASO prolonge le dossier vers le peering, le DNS et l’échange de trafic. La mise à jour d’ICANN de 2015 établit une élection au Conseil d’adressage et une vice-présidence au sein de l’équipe CRISP.

Aucune de ces pièces ne transfère les décisions collectives ou les résultats de production à une personne unique. Ensemble, elles décrivent toutefois une continuité: rendre les informations nécessaires lisibles, maintenir les rôles séparés, rapprocher les registres des contraintes opérées et préserver une coordination qui ne dépend pas d’un seul acteur.