APNIC réintègre 92 rapports WHOIS et RDAP sans bilan de réparation

Résumé

L’archive d’octobre d’APNIC répertorie maintenant les 92 rapports WHOIS/RDAP correspondant aux heures du 23 octobre à 04:00 UTC au 27 octobre à 00:00 UTC. Les rapports et leurs fichiers MD5 affichent tous la même modification : le 29 octobre à 10:16, heure UTC+10 du répertoire.
L’avis du 16 octobre ne comporte toujours ni heure de fin ni durée. Une somme MD5 confirme les octets téléchargés ; le schéma public d’APNIC ne renseigne pas l’exhaustivité des journaux à l’origine de chaque heure.

Quatre jours remis en ligne d’un seul coup

Le 27 octobre, le répertoire d’APNIC passait du 23 au 27 octobre et sautait 92 rapports horaires. Ils sont à présent tous visibles. Le créneau va du 23 octobre à 04:00 UTC au 27 octobre à 00:00 : quatre jours, soit 92 intervalles d’une heure.

Le 29 octobre, le répertoire a horodaté toute la série à 10:16, heure UTC+10. Cette minute commune apparaît sur chacun des 92 rapports et sur chacun de leurs fichiers .md5. Pour le premier et le dernier fichiers, les en-têtes HTTP indiquent 00:16:28 UTC. J’ai téléchargé ces deux archives gzip, vérifié les intervalles inscrits dans les rapports et comparé leur MD5 au fichier de contrôle publié par APNIC. Le premier couvre 23 octobre, 04:00–05:00 UTC ; le dernier, 26 octobre, 23:00–27 octobre, 00:00 UTC.

Le flux courant a continué d’avancer. Le JSON WHOIS/RDAP le plus récent couvre maintenant 30 octobre, 23:00–31 octobre, 00:00 UTC ; son MD5 correspond aux octets récupérés. À l’échelle des fichiers, les heures manquantes sont revenues et la publication horaire est à jour.

L’avis d’incident, lui, n’a pas suivi. Le 16 octobre, APNIC attribuait l’incomplétude des statistiques à un problème de traitement des journaux à partir de 10:00 UTC+10. L’organisation disait avoir désactivé la génération et promettait de republier les fichiers concernés une fois le problème réglé. Les champs de fin et de durée sont toujours vides. La page des mises à jour de service conserve cet avis sans publier de clôture pour cet incident WHOIS/RDAP.

Les 92 rapports sont revenus dans l’archive. Le README d’APNIC énumère les champs horaires : intervalle, volume de requêtes, répartition par type, nombre d’ASN et chiffres par ASN. Les documents publics ne donnent ni identifiant de révision, ni état de complétude par heure, ni manifeste de reprise. Les deux MD5 contrôlés correspondent aux valeurs publiées. Pour identifier les journaux traités et confirmer la reconstruction de chaque heure touchée, il manque un relevé de traitement par intervalle.

Pour l’analyste qui avait calculé une série depuis la copie du 27 octobre, l’archive actuelle change la fenêtre : un recalcul à partir de tous les fichiers ajoute 92 observations horaires. Conserver l’ancienne copie permet de refaire le premier calcul ; un statut par intervalle permettrait de qualifier les nouvelles observations. L’avis d’APNIC ne donne toujours ni heure de clôture ni état de reprise pour la période touchée depuis le 16 octobre.

Il manque un reçu de réparation

APNIC pourrait fermer le dossier avec un manifeste par intervalle : l’heure UTC concernée, son état de récupération, l’identifiant du traitement, la valeur MD5 actuelle et l’heure de clôture de l’incident. Si une statistique reste incomplète, il suffit de le signaler pour cette heure. Les utilisateurs pourraient alors séparer les fichiers remis en ligne des données dont l’exhaustivité a été confirmée, puis refaire les mêmes calculs plus tard.

L’horodatage fixe à la minute près le retour des fichiers. Un registre de réparation devrait donner, pour chaque heure, le traitement appliqué et son état. APNIC a remis les rapports dans l’archive ; il reste à documenter les données qu’ils contiennent.