Résumé

  • Le 19 octobre, RIPE NCC a déployé une nouvelle page Resources sur le site RIPE Database, remplaçant la liste par un arbre et ajoutant des contrôles. L’intégration au parcours Assisted Registry Check du portail LIR reste annoncée pour plus tard.
  • Un résultat vérifié, un point à examiner et une ressource non contrôlée sont trois états distincts. L’absence d’une route exacte ne suffit pas à conclure à une erreur.

Le parent est vert. Et l’enfant ?

Le 19 octobre, Edward Shryane a annoncé au groupe de travail sur la RIPE Database le déploiement de la page Resources sur le site de la base. L’ancienne liste cède la place à un arbre ; des contrôles signalent les ressources qui appellent un examen. Shryane a situé l’arrivée de cette fonction dans le parcours Assisted Registry Check du portail LIR dans une étape ultérieure. Le site de la base et le portail LIR ne sont pas le même lancement.

Deux jours plus tard, l’équipe de conception de RIPE NCC a mis le doigt sur le défaut que cet arbre pourrait rendre spectaculaire : un parent peut paraître net alors qu’un enfant attend encore son contrôle. Une grande hiérarchie réclame de nombreux appels API. Quand la machine n’a pas atteint une branche, le vert du parent ne doit pas ruisseler jusqu’aux feuilles.

Le panneau latéral décrit par l’équipe rassemble données d’enregistrement, utilisation, objets de la RIPE Database et routage. La page fait ainsi davantage qu’exposer des lignes de registre : elle suggère où consacrer du temps. Cela exige une précision élémentaire sur ce qui a réellement été examiné.

RIPE NCC explique que contrôler chaque parent et chaque enfant dans une grande hiérarchie peut exiger de nombreux appels API. Certaines ressources enfants peuvent donc rester sans contrôle. L’équipe cherche encore comment éviter que cette absence soit prise pour un feu vert général.

Il faut trois états visibles : vérifié et clair ; vérifié et à examiner ; pas encore vérifié. « Inconnu » n’est pas une faute. C’est une information. La masquer reviendrait à cocher une case vide et à la présenter comme validée.

Ce qu’un contrôle peut constater

Les exemples publiés couvrent les allocations IPv6 annoncées sans utilisation enregistrée, les assignments IPv6 plus petits que prévu, les allocations comportant des assignments enregistrés mais non annoncés, les ASN absents de la table BGP et l’espace utilisé qui pourrait nécessiter un enregistrement supplémentaire.

Ces signaux n’ont pas le même poids. Une donnée d’enregistrement manquante appelle une vérification. L’absence d’un ASN dans une table BGP décrit d’abord la visibilité dans cette table. Une route qui ne correspond pas exactement à une ressource peut être plus spécifique, couvrir le préfixe ou relever d’une autre configuration intentionnelle. RIPE NCC indique qu’une recherche de correspondance exacte, à elle seule, produirait des avertissements trompeurs. La refonte prévoit donc des messages neutres lorsque le système ne peut établir un problème.

C’est préférable au triangle rouge pour chaque détail inhabituel. Dans une équipe réseau, une alerte prend le temps de quelqu’un. Si toute différence s’appelle « problème », les équipes finissent par ignorer les alertes. Si un contrôle jamais exécuté affiche du vert, le tableau de bord demande aux membres de faire confiance à une case vide.

La documentation publique de l’API My Resources décrit des données sur les ASN, les allocations et assignments IPv4 et IPv6, ainsi que les ressources IPv4 historiques. Un enregistrement peut contenir son état, sa date d’inscription et un lien vers l’objet RIPE Database correspondant. L’interface ajoute des comparaisons à ces données ; il faut toujours savoir ce qui a été comparé, ce qui a été trouvé et qui agit ensuite. L’annonce du déploiement ne donne pas l’inventaire de chaque contrôle effectivement actif en production.

« À examiner » est déjà une décision

« À examiner » laisse de la place au contexte. « Problème » ressemble à un verdict. « Aucune correspondance exacte trouvée » décrit ce que le système a vu sans prétendre connaître toute la conception du routage.

La refonte sépare les éléments qui appellent une action des informations qui demandent une interprétation. Les notifications doivent expliquer la détection, son intérêt et l’action possible. Les routes liées pourront apparaître dans une hiérarchie. RIPE NCC prévoit aussi des essais auprès des membres à RIPE 93 pour vérifier qu’ils comprennent l’arborescence, les contrôles et le passage vers le service Registry Check existant.

Le dossier public ne contient pas encore les résultats de ces essais ni un rapport de couverture en production ; un compte rendu daté et une définition de l’état de contrôle par ressource permettraient de réévaluer le modèle.

Laisser le carré vide

Un portail de ressources ne fait pas que montrer des données. Dès qu’il classe des constats et suggère une suite, il distribue l’attention des membres et des équipes. Ce rôle opérationnel exige de distinguer une vérification d’un jugement sur une configuration inhabituelle.

La note de Lu Heng sur la continuité du registre sépare la fiabilité des données et des services des choix de pouvoir de l’institution. Ici, la distinction est concrète : un portail peut aider à tenir les enregistrements à jour sans transformer l’absence d’une route exacte en décision de non-conformité.

Chaque ressource devrait montrer ce qui a été contrôlé, à quelle date, ce que le contrôle a trouvé et si le résultat est clair, à examiner ou encore inconnu. Dans une grande arborescence, l’avancement doit rester visible branche par branche. Quand le système n’a pas atteint un enfant, il lui faut un carré vide, pas le feu vert emprunté au parent.

Sources : annonce du déploiement de RIPE NCC ; mise à jour de RIPE NCC aux membres, octobre 2026 ; RIPE Labs, Redesigning My Resources ; API My Resources de RIPE NCC ; Assisted Registry Check de RIPE NCC.