Summary

  • Dans le fichier cumulatif du 2 novembre, LACNIC publie 1 922 opérations. Une seule ligne IPv4 porte des bornes nulles : le transfert daté du 7 janvier 2026 entre UNIVERSIDAD AUTONOMA DE SAN LUIS POTOSI et DIGY NETWORKS.
  • Cette ligne apparaît dans l'export du 9 janvier et garde ses quatre bornes vides 297 jours plus tard. Les parties sont nommées, mais les adresses transférées restent introuvables dans ce registre public.

Le registre sait qui, quand et dans quel pays. Il a oublié quoi. Le fichier cumulatif de LACNIC du 2 novembre réunit 1 922 lignes de transferts. Dans celle du 7 janvier 2026, UNIVERSIDAD AUTONOMA DE SAN LUIS POTOSI figure comme cédant et DIGY NETWORKS comme destinataire. Les deux organisations portent le code MX et relèvent de LACNIC ; le type indiqué est RESOURCE_TRANSFER. Pourtant les objets ip4nets.original_set et ip4nets.transfer_set donnent chacun null pour l'adresse initiale et l'adresse finale. Les listes ASN et IPv6 sont vides. Aucun numéro de ressource ne permet donc de reconnaître ce qui aurait changé de main.

Un tableau peut contenir des lacunes. Celle-ci a une singularité vérifiable : dans les 1 922 lignes de l'export actuel, c'est la seule plage IPv4 transférée dont une borne est nulle. Le 7 janvier, la ligne n'existe pas ; le 8 janvier, elle n'existe toujours pas. Elle apparaît dans le fichier du 9 janvier, déjà privée de ses quatre bornes. Celui du 1er novembre les laisse également vides. Entre sa première apparition et le 2 novembre, 297 jours calendaires passent. Le fichier gagne 333 lignes ; celle-ci ne gagne pas une adresse.

Le 9 janvier, deux lignes possédaient des bornes nulles. L'autre, datée du 30 décembre 2025, ne figure plus sous les mêmes noms et la même date dans l'export du 2 novembre. Les fichiers ne donnent pas de numéro de dossier commun qui expliquerait cette disparition. L'observation utile est plus étroite : le contenu historique du tableau peut évoluer, tandis que cette entrée précise reste incomplète.

Le manuel des politiques de LACNIC, version 2.21, section 2.3.2.18.4, prévoit un journal public comportant notamment la date, les organisations et les adresses transférées. La section 2.3.2.18.1 fixe une taille minimale de /24 ; la section 2.3.2.18.6 empêche un nouveau transfert des mêmes adresses pendant un an. Sans plage, le public ne peut calculer la taille ni rechercher une transaction ultérieure portant sur le même bloc. Il ne peut même pas interroger RDAP à partir de cette ligne pour savoir qui détient aujourd'hui la ressource.

Une exportation corrigée, ou un dossier public lié à cette ligne et nommant la plage, changerait ce constat. En attendant, la ligne demande au lecteur de croire à une opération dont elle retire l'objet vérifiable. La responsabilité de ce vide appartient au registre qui publie la table, pas aux organisations qui y sont nommées.