Résumé

  • En juin 2024, ARIN a annoncé qu’après acceptation d’un standard IETF commun, geofeed serait mis en œuvre dans RDAP, ARIN Online et Reg-RWS. La suggestion devait rester Open jusqu’au développement et au déploiement.
  • RFC 9877 est devenu un RFC Standards Track en octobre 2025. Il définit geofeed1, la relation geofeed et le type application/geofeed+csv, désormais inscrits dans les registres correspondants.
  • Le 12 septembre 2026, le registre ACSP d’ARIN affichait toujours 2024.10 comme Open et la réponse RDAP help en production ne déclarait pas geofeed1. Un objet réseau choisi pour son intérêt illustratif portait encore l’URL dans un commentaire.
  • Ces constats ne prouvent ni l’inaction technique ni une absence dans toute la base. Ils justifient un reçu public et daté : déclencheur normatif, état de chaque produit, migration des commentaires, accès en masse, protection de la vie privée, tests et retour arrière.

Un bon de livraison pour une promesse conditionnelle

Les organismes techniques ont raison de ne pas coder trop tôt une convention appelée à changer. Cinq RIR qui exposeraient cinq variantes d’un même lien imposeraient leur histoire interne à chaque client RDAP. Attendre un vocabulaire commun peut donc être un choix de discipline, pas une excuse.

Mais une attente publique produit une obligation de mise à jour. Lorsque la condition annoncée change, le lecteur doit pouvoir distinguer trois choses : le travail de normalisation, le travail de produit et la preuve que le service public correspond au produit annoncé.

La Suggestion ACSP 2024.10, déposée le 3 juin 2024, demandait un champ geofeed facultatif pour les objets réseau d’ARIN. Son auteur décrivait une pratique existante : placer une ligne de type Geofeed [URL] dans les commentaires d’enregistrement. Pour un humain, l’intention est visible. Pour une machine, il faut reconnaître une chaîne libre, choisir le bon URL et espérer que les mots voisins ne modifient pas son sens.

La réponse d’ARIN, datée du 7 juin, avait une qualité rare : elle nommait la condition et les produits. Les cinq RIR travaillaient avec l’IETF à une extension RDAP. Une fois le standard accepté, ARIN mettrait le changement en œuvre dans RDAP et ajouterait les fonctions nécessaires à ARIN Online et à Reg-RWS. Le texte évoquait aussi un format RDAP en masse cohérent entre RIR. La suggestion resterait ouverte jusqu’au développement et au déploiement de la nouvelle fonction.

Il n’y avait ni date ferme ni définition du mot « accepté ». Ce terme pouvait viser l’approbation par l’IESG, la publication d’un RFC, l’adoption d’un profil NRO ou une autre étape opérationnelle. Il serait donc excessif de transformer la réponse en délai contractuel. Elle établissait néanmoins un passage vérifiable : avant l’événement, le standard était le verrou ; après lui, ARIN devait identifier le verrou suivant ou montrer le produit.

Le RFC n’impose pas l’extension, il rend la déclaration vérifiable

RFC 9877 a été publié en octobre 2025 avec le statut Standards Track. Il ne contraint pas tout serveur RDAP à fournir des geofeeds. Sa contribution est plus précise : lorsqu’un serveur choisit cette capacité, les clients disposent de signes enregistrés et de règles partagées.

La relation de lien geofeed décrit la destination fonctionnelle. Le type de média application/geofeed+csv décrit la représentation attendue. L’identifiant d’extension geofeed1 indique qu’un serveur héberge des URL geofeed pour ses objets de réseau IP. Le registre IANA des extensions RDAP contient aujourd’hui cet identifiant et sa référence à RFC 9877.

Si un serveur revendique geofeed1, il doit l’inclure dans le tableau rdapConformance de sa réponse help ainsi que dans les réponses de recherche ou de consultation contenant des objets réseau IP. Lorsqu’il possède une URL pour un objet donné et peut la communiquer, il doit joindre le lien correspondant.

Cette combinaison donne une portée particulière à l’absence. Avec l’identifiant, un client sait que le serveur a annoncé la règle générale ; l’absence du lien pour un objet peut alors être lue dans ce cadre. Sans l’identifiant, elle ne signifie que ceci : cette réponse ne comporte pas le lien.

Le RFC prévoit aussi une nuance décisive. Un serveur peut utiliser la relation enregistrée et le type de média sans déclarer l’extension geofeed1. Le protocole RDAP accepte déjà des relations enregistrées dans une réponse ordinaire. L’identifiant ajoute une promesse à l’échelle du service ; il n’est pas l’unique chemin licite vers un lien typé.

La production livre deux observations étroites

La réponse help du service RDAP d’ARIN, capturée le 12 septembre 2026, présente plusieurs capacités : niveau RDAP de base, profil NRO, CIDR, origin-AS, recherches RIR et formats de résultats. geofeed1 n’apparaît pas dans rdapConformance.

Ce fait est solide à condition de rester petit. La réponse n’a pas revendiqué l’extension au moment de la capture. Elle ne révèle pas une branche de code, un pilote réservé, un formulaire non publié dans ARIN Online ou un accord inter-RIR encore en discussion. Elle ne permet pas de conclure qu’aucun travail n’existe.

Un deuxième appel montre pourquoi la migration compte. L’objet couvrant 154.54.100.0/22 contient, dans Registration Comments, Geofeed ai.net/geofeed.csv. Son tableau de conformité ne comprend pas geofeed1. Ses liens sont de relation self, alternate et up, sans rel=geofeed.

Ce réseau a été choisi parce qu’il expose clairement la convention évoquée dans la suggestion. Ce n’est pas un échantillon aléatoire. Il ne mesure pas la proportion de commentaires geofeed, n’exclut pas l’existence de liens typés ailleurs et ne certifie pas le contenu du fichier visé. Un pointeur publié par le registre ne prouve ni la localisation physique, ni le routage, ni l’exactitude de la déclaration de son éditeur.

La conclusion utile est donc restreinte : après la publication du RFC, au moins un objet public illustre encore l’ancien chemin. Tout nouveau champ doit dire comment ce passé traverse la frontière.

En avril 2026, le récit public attendait encore l’IETF

La transcription de la deuxième journée d’ARIN 57 ajoute une question chronologique. Dans son rapport d’ingénierie, ARIN a cité des améliorations RDAP pour geofeed et les services de répertoire RPKI, puis a indiqué que cela passait alors par l’IETF. La réunion s’est tenue environ six mois après la publication de RFC 9877.

Il existe plusieurs explications raisonnables. La phrase pouvait viser un document connexe, un profil d’exploitation, une coordination entre RIR ou une diapositive dont la description n’avait pas été actualisée. Elle ne démontre pas qu’ARIN ignorait le RFC et encore moins que l’ingénierie était inactive.

Elle montre en revanche que les deux pièces publiques ne s’accordent pas seules. Une note de correction suffirait : RFC 9877 est terminé ; le dépendant actuel est tel profil, telle migration ou telle revue. Corriger un récit n’est pas reconnaître une faute. C’est empêcher une dépendance expirée de continuer à masquer la décision réelle.

Le coût principal se trouve dans les données anciennes

Ajouter un lien à une réponse JSON est la partie visible. Le système de contrôle est plus large. ARIN Online reçoit les décisions humaines. Reg-RWS reçoit les changements automatisés. RDAP les expose. Un canal en masse sert les consommateurs qui ne doivent pas parcourir des milliers de consultations unitaires. La migration décide ce qu’un commentaire historique devient.

Ces surfaces peuvent évoluer séparément. ARIN Online peut accepter un champ avant Reg-RWS. Une réponse réseau peut fournir une relation enregistrée avant que help ne revendique geofeed1. Le fichier en masse peut être produit à un autre rythme. Une annonce unique de « déploiement » ne dit pas quelle asymétrie est normale.

Les commentaires rendent toute conversion automatique risquée. Certains contiennent un URL propre. D’autres contiennent deux adresses, du texte d’avertissement, une référence morte ou simplement le mot geofeed. Extraire chaque correspondance et la transformer en champ typé conférerait à une ancienne phrase une autorité qu’elle n’avait pas nécessairement.

Ne rien faire n’est pas neutre non plus. Deux voies de découverte survivraient, avec des règles de priorité implicites. Un client pourrait lire le nouveau lien, un autre continuer à analyser le commentaire, puis conserver deux versions divergentes.

La migration devrait commencer par un inventaire. Les candidats peuvent être classés : clairs, ambigus, multiples, injoignables ou hors sujet. Le détenteur de ressources confirme les cas où l’autorité change. Le système conserve le texte d’origine et la décision, définit la priorité d’un champ typé et dispose d’un retour arrière. Il teste aussi les objets plus spécifiques, car un geofeed couvrant un préfixe étroit ne doit pas être écrasé par une référence plus large.

Une source autorisée n’est pas une géographie observée

RFC 9632 décrit la découverte par RPSL et un mécanisme facultatif d’authentification RPKI. Le mot facultatif empêche un glissement sémantique. Une signature peut relier le fichier à l’autorité sur les ressources couvertes. Elle ne visite pas les équipements et ne mesure pas la position d’un utilisateur.

Quatre décisions restent distinctes. Le détenteur publie une URL. ARIN expose le pointeur. Une signature peut authentifier sa provenance. Le consommateur choisit d’utiliser les coordonnées déclarées. Ni le registre ni le RPKI ne transforme cette chaîne en preuve de présence physique.

La lisibilité machine augmente l’échelle de distribution. Elle améliore la découverte, mais amplifie également les effets d’un cache ancien, d’un retrait tardif ou d’une règle de spécificité mal comprise. RFC 9632 note des enjeux de vie privée et déconseille l’emploi de RDAP ordinaire pour la collecte en masse. La réponse de 2024, qui annonçait un format de téléchargement cohérent, reconnaissait déjà que transaction et distribution ne sont pas le même produit.

Il faut donc publier le temps de prise en compte d’une suppression, la date de chaque instantané en masse, la politique de conservation, l’intégrité du fichier et le comportement en cas de restriction. Un silence réglementaire ne devrait pas être confondu avec l’absence d’une déclaration chez le détenteur.

Les colonnes du reçu de déploiement

La première colonne fixe le déclencheur : RFC 9877, ses errata éventuels, le profil NRO ou inter-RIR retenu et la date à laquelle ARIN a jugé la condition de 2024 satisfaite. Si une autre norme reste nécessaire, elle doit être nommée.

La deuxième colonne est une matrice des produits. Pour ARIN Online, Reg-RWS, RDAP help, les réponses réseau et le service en masse, elle indique conception, test, disponible, défaut, déprécié ou achevé selon des définitions stables. Elle précise l’identifiant, la relation et le type de média attendus.

La troisième colonne décrit l’écriture : rôles autorisés, format des URL, normalisation, suppression, aperçu de la future réponse RDAP et traitement d’un serveur temporairement injoignable. Une panne du site geofeed peut justifier un avertissement ; elle ne doit pas effacer silencieusement une décision du détenteur.

La quatrième consigne la migration : nombre de commentaires candidats, catégories de décision, confirmation du détenteur, priorité entre commentaire et champ, conservation de la preuve initiale et procédure de restauration. Les URL individuelles n’ont pas à figurer dans une statistique publique.

La cinquième sépare les horloges : changement accepté, relecture dans ARIN Online, relecture dans Reg-RWS, visibilité RDAP, inclusion dans l’instantané en masse. Une fenêtre d’éventuelle cohérence est plus honnête qu’un seul horaire fictif.

La dernière colonne contient les tests et la gouvernance. Il faut des cas valides, absents, mal formés, plus spécifiques, multilingues, retenus et supprimés ; une date de déploiement et une condition de retour arrière ; une note sur la formulation d’ARIN 57 ; puis une décision ACSP reliée aux preuves qui satisfont la définition d’ARIN.

Un document pour limiter les inférences

Sans reçu, le public peut transformer un token absent en accusation d’inaction. ARIN peut, à l’inverse, considérer un travail interne comme équivalent à une fonction publique. Dans les deux cas, un état remplace abusivement un autre.

Le reçu donne une affirmation modeste mais forte : à telle date, ces interfaces prennent en charge ces éléments selon ces règles. Il laisse intacts les garde-fous. Une suggestion Open ne décrit pas la charge de travail privée. Un objet n’est pas la base entière. Une URL n’est pas un lieu. Une authentification n’est pas une mesure géographique.

La réponse finale peut être banale : un autre profil reste à terminer, ou certaines surfaces existent déjà tandis que le registre ACSP tarde. L’important est de rendre la limite falsifiable. RFC 9877 a normalisé le langage du serveur ; ARIN doit maintenant normaliser le langage de son propre passage en production.

Sources