Résumé

  • Les fichiers statistiques standard d’AFRINIC portant les dates des 10, 11 et 12 septembre 2026 sont identiques octet pour octet. Leur numéro interne et leur fin de période restent 20260910. Les fichiers étendus suivent le même schéma.
  • Cette identité ne prouve ni une panne ni l’absence de nouveaux événements dans le registre. Une fiche de publication pourrait préciser si le résultat a été contrôlé à nouveau, réémis ou limité par une source en retard, sans révéler les dossiers des membres.

Le téléchargement répond à une question simple : quel objet le serveur a-t-il livré ? Il ne répond pas toujours à la question plus importante : jusqu’à quand cet objet a-t-il été vérifié ? Dans l’archive publique d’AFRINIC, les noms avancent de trois jours tandis que le contenu conserve une seule identité.

La capture réalisée le 14 septembre, selon le calendrier Asia/Shanghai, a reçu 491 382 octets pour chacun des fichiers standard nommés 10, 11 et 12 septembre. Leur SHA-256 commun est 54b0cfb6c962fe41815728ef9bff5950cece5fcdd7ab17b94cc3875e68378e07. Le numéro interne vaut 20260910, le total déclaré est de 9 947 enregistrements et la fin de période reste le 10 septembre. C’est un constat reproductible sur les objets publics, pas un diagnostic du système interne.

Plusieurs horloges, plusieurs responsabilités

Le RIR Statistics Exchange Format publié dans le répertoire d’AFRINIC prévoit une production quotidienne. Le suffixe de delegated-<registry>-yyyymmdd désigne la date locale à laquelle le fichier a été produit. Le champ serial, lui, est le numéro du fichier dans la série du RIR. La fin de période est encore un autre champ. L’alias latest doit pointer vers le fichier le plus récent lorsqu’il est mis à jour.

L’heure de modification du serveur n’est aucune de ces trois choses. L’index 2026 associe au nom du 10 septembre une modification le 11, au nom du 11 une modification le 12, et au nom du 12 une modification le 13. Les réponses HTTP portent aussi des métadonnées distinctes. Elles décrivent l’objet servi ; elles n’attestent ni l’exécution d’un nouveau générateur ni la date limite des sources examinées.

Dans le répertoire racine, le nom delegated-afrinic-20260913 côtoie une modification datée du 10 septembre. Son téléchargement livre le même contenu, tout comme l’alias standard actuel. La date du chemin, l’heure du serveur et la version interne ne progressent donc pas ensemble dans cet échantillon.

Les contrôles confirment l’identité, pas son motif

Les fichiers étendus des 10, 11 et 12 septembre et leur alias actuel sont également identiques : 992 722 octets, SHA-256 66f1d06b8f272cbb3f2da3260b73a63cb7b1cd132ad770851dc2e2864ac9eb75, numéro et fin de période 20260910, 19 651 enregistrements déclarés. Leur format enrichit l’information sur les ressources et leurs détenteurs, mais ne documente pas cet épisode de publication.

Les trois fichiers MD5 sont identiques eux aussi. Le calcul indépendant du contenu standard retrouve la valeur annoncée, 568a689f01216f94af0b174514fd3903. Les trois objets de signature OpenPGP détachée partagent les mêmes octets. Cet article ne prétend pas avoir vérifié ces signatures localement.

Le checksum concordant limite l’hypothèse d’une corruption de transport par rapport à la valeur publiée. Une signature mathématiquement vérifiée relierait les octets à une clé. Ni l’un ni l’autre ne fournit la raison pour laquelle un nom plus récent livre un ancien numéro. Le contenu peut être authentique tout en laissant sa fraîcheur opérationnelle indéterminée.

Un témoin modeste existe : le fichier standard du 9 septembre a la même taille et le même nombre déclaré d’enregistrements, mais un autre digest et un numéro du 9 septembre. Un total stable ne prouve pas des lignes stables. L’égalité complète des octets, en revanche, prouve l’identité du contenu capturé.

Une absence de changement doit être datée

Un registre peut n’avoir rien de nouveau à annoncer un jour donné. Il peut aussi republier volontairement un résultat validé. Ces pratiques ne sont pas nécessairement anormales. Mais « contrôlé jusqu’au nouveau jour, sans changement » et « sortie précédente diffusée à nouveau » constituent deux observations différentes.

Les fichiers ne montrent pas d’identifiant d’exécution, de limite temporelle des sources, de motif de réémission ni d’état de correction. Ils ne permettent pas de choisir entre résultat inchangé, réutilisation délibérée, générateur arrêté ou source retardée. Conclure à une panne serait excessif. Considérer le nouveau nom comme preuve d’un contrôle récent le serait tout autant.

Deux erreurs symétriques menacent les collecteurs. Une archive indexée uniquement par URL peut compter trois observations indépendantes là où il n’y a qu’un jeu de données. Une archive dédupliquée uniquement par numéro interne peut effacer l’apparition de nouvelles publications. Il faut conserver la version des données et l’événement de diffusion séparément.

Les utilisateurs peuvent déjà enregistrer URL demandée, heure de collecte, métadonnées reçues, numéro, fin de période et digest. AFRINIC pourrait compléter cette observation avec une fiche liant publication, fenêtre effectivement contrôlée, validation et motif général d’un contenu inchangé. Aucun dossier confidentiel n’est requis.

Limites de la preuve et sources

La comparaison porte sur des fichiers publics figés. Elle ne démontre ni allocations manquantes, ni données de registre erronées, ni panne, antidatation, manipulation ou dommage opérationnel. Elle n’assimile pas l’heure du serveur à celle du générateur. Si un fichier est corrigé ultérieurement, l’ancien état doit rester identifiable.