Résumé

  • Le dump officiel d’AFRINIC daté du 30 août 2026 contient 3 790 objets RPSL portant exactement remarks: Geofeed HTTPS-URL, mais seuls 3 573 sont des objets d’adresses inetnum ou inet6num visés par la méthode de découverte de la RFC 9632.
  • Cette écriture n’est ni une anomalie ni une infraction. La RFC 9632 la prévoit pour les bases dépourvues de champ geofeed: et impose aux consommateurs de comprendre les deux formes pendant la migration.
  • Les schémas WHOIS en service chez AFRINIC proposent toujours remarks: sans geofeed:. Le dossier public du DBWG montre une demande de work item et d’étude d’impact, relancée à plusieurs reprises, sans décision publique ultérieure retrouvée jusqu’en août 2026.
  • Un reçu de migration limité pourrait publier l’état de la décision, les droits de modification, les règles de syntaxe et de conflit, le sort des données existantes, la projection WHOIS/RDAP, les limites d’authentification, les essais et le retour arrière.

Le premier enseignement du dump n’est pas que 3 790 pointeurs existent. C’est que 217 d’entre eux se trouvent ailleurs que là où le modèle normalisé les attend.

Une recherche textuelle stricte dans la base publique d’AFRINIC trouve 3 790 lignes conformes à la séquence définie par la RFC 9632 : l’attribut remarks:, le jeton sensible à la casse Geofeed, puis une URL HTTPS. Dès que l’on reconstitue les objets RPSL, le périmètre change. On compte 3 483 objets inetnum et 90 objets inet6num, soit 3 573 objets d’adresses.

Le solde apparaît dans 168 objets route, 41 route6, cinq domain, deux as-set et un organisation. La chaîne est correctement orthographiée, mais son conteneur n’est pas l’objet d’adresse autour duquel la RFC organise la découverte.

Il serait excessif d’appeler ces 217 occurrences des erreurs. Elles révèlent plutôt la propriété essentielle d’un champ de remarques : il accueille du texte, pas un type. Le sens opérationnel vient d’une convention entre producteurs et lecteurs. La base, elle, ne distingue pas nativement un pointeur Geofeed d’une consigne de support ou d’un commentaire administratif.

Voilà pourquoi le titre retient 3 573. Le total de 3 790 mesure la diffusion d’une chaîne dans l’ensemble du corpus RPSL. Le nombre de 3 573 mesure les objets d’adresses pertinents pour la procédure normalisée. Les deux chiffres sont utiles, à condition de ne pas les faire répondre à la même question.

Le meilleur argument en faveur du système actuel

Le format de repli fait exactement ce qu’un bon mécanisme de compatibilité doit faire : il permet à plusieurs bases et à plusieurs générations de clients de coexister.

La RFC 9632 ne suppose pas une migration simultanée de tous les RIR. Lorsqu’une base n’a pas mis en œuvre geofeed:, elle définit la forme dans remarks:. Tant que tous les producteurs n’ont pas annoncé la prise en charge du champ dédié et que les titulaires n’ont pas déplacé leurs références, les consommateurs doivent lire les deux formes. Rejeter la forme AFRINIC au seul motif que RIPE ou APNIC disposent d’un attribut dédié contredirait cette exigence d’interopérabilité.

L’usage observé est substantiel. Les 3 573 objets d’adresses renvoient à 106 URL HTTPS distinctes. Leur répartition comprend 3 461 ASSIGNED PA, 71 ALLOCATED PA, 17 ALLOCATED-BY-RIR, 13 ASSIGNED PI et 11 SUB-ALLOCATED PA. Une même URL peut légitimement servir plusieurs plages lorsqu’un opérateur publie un fichier commun.

Ces données ne démontrent ni la disponibilité des URL, ni la justesse des localisations, ni leur adoption par un service commercial. Elles montrent qu’un grand nombre d’enregistrements s’appuient déjà sur la convention. Une migration qui casserait ces références pour obtenir un schéma plus élégant détruirait de l’interopérabilité au nom de l’interopérabilité.

La prudence d’AFRINIC peut donc être rationnelle. Ajouter un attribut touche l’authentification des mises à jour, les formulaires, les soumissions par courrier, le dump, les clients WHOIS, RDAP, la documentation et l’assistance. Il faut traiter les objets contenant les deux formes, les variantes tolérées aujourd’hui, les erreurs historiques et les clients qui n’évoluent pas au même rythme. Une petite modification de modèle peut devenir un projet de migration transversal.

L’argument sérieux en faveur du champ dédié n’est pas qu’il figure dans un texte normatif. C’est qu’il peut retirer une ambiguïté mesurable sans retirer la compatibilité qui fonctionne.

Ce qu’un schéma peut contrôler — et ce qu’il ne peut pas promettre

La RFC 9632 précise que la forme en remarques ne peut pas être vérifiée formellement par le RIR. La recommandation d’une seule référence par objet ne peut donc pas être imposée proprement au niveau du modèle. Un champ dédié pourrait vérifier une URL HTTPS, limiter la cardinalité, signaler un conflit et offrir aux interfaces d’export une valeur structurée.

Le dump quantifie cette différence. On trouve 3 592 objets d’adresses avec une remarque ressemblant à Geofeed sans tenir compte de la casse. Cent six lignes s’écartent de la forme stricte : deux-points après le mot, minuscules ou URL HTTP. Rien ne prouve que tous les collecteurs les rejettent. Cela prouve qu’une convention textuelle peut dériver sans rencontrer de barrière de schéma.

Un attribut dédié ne transforme pourtant pas la localisation en vérité certifiée. Il faut séparer trois contrôles.

Le premier concerne la structure : cette valeur est-elle reconnue comme un pointeur Geofeed attaché à cet objet ? Le deuxième concerne l’autorité : l’éditeur du fichier peut-il parler au nom de l’espace d’adresses ? Le troisième concerne le contenu : les lieux déclarés sont-ils exacts, à jour et suffisamment agrégés pour ne pas exposer une personne ?

HTTPS authentifie le point de terminaison nommé et protège le transport. Il n’authentifie pas l’attribution de l’espace IP. La RFC 9632 décrit donc une signature RPKI facultative pour renforcer le lien avec un certificat de ressources. Même signée, une déclaration ne prouve pas qu’un code pays ou une ville correspond à l’usage réel de chaque adresse au moment où un tiers la consulte.

Le champ dédié rend la première couche explicite. HTTPS traite une partie du transport. La signature RPKI facultative traite une partie de l’autorité. L’exactitude et la protection de la vie privée restent des obligations opérationnelles distinctes.

Cette limite différencie la présente enquête d’un article existant sur le champ Geofeed d’APNIC. Cet article examinait le risque de confondre l’authentification du lien et la vérité de chaque localisation. Ici, le problème est antérieur : chez AFRINIC, le pointeur lui-même demeure une phrase indifférenciée dans le modèle.

La demande publique reste sans état public visible

Le débat a une date et un lieu institutionnel. Le 27 octobre 2025, un participant du Database Working Group a proposé d’ajouter geofeed: et de permettre aux titulaires de ressources de le mettre à jour. Il a décrit le recours actuel aux remarques et, pour ses ressources PI, la nécessité selon son expérience de solliciter le hostmaster.

Le lendemain, le coprésident du DBWG a ouvert deux semaines de discussion et invité le personnel à préparer une étude d’impact. Le 14 novembre, après avoir constaté l’absence de désaccord, il a demandé à AFRINIC de prendre le sujet comme work item et d’expliquer sa mise en œuvre, étude d’impact comprise.

Le proposant a demandé un rapport le 6 avril 2026. Le 16 avril, le coprésident a demandé confirmation du statut actif du work item et renouvelé la demande d’analyse. Un autre participant a ajouté son soutien le 17 avril.

L’index officiel contient des mois d’archives en janvier, février, mars, avril et août 2026, mais aucun mois en mai, juin ou juillet. Les fils consultés jusqu’en août ne montrent pas de nouveau message Geofeed après le 17 avril. La conclusion doit rester exacte : aucune réponse ou décision ultérieure n’a été trouvée dans l’archive publique examinée.

Cela ne signifie pas qu’AFRINIC n’a rien fait. Un ticket interne, une étude technique, un échange privé ou une dépendance de calendrier peuvent exister. Une liste publique ne révèle pas toutes les opérations de l’institution. Le manque porte sur le reçu public : la demande publique est-elle acceptée, différée, rejetée, remplacée ou en attente ?

Une institution n’est pas tenue d’implémenter toute proposition qui ne rencontre pas d’opposition. Elle gagne toutefois à rendre le statut d’une demande nommée aussi visible que la discussion qui l’a créée.

Treize objets PI : une observation, pas une généralisation

L’expérience PI citée dans la proposition peut être comparée aux données, mais pas transformée en vérité universelle. Le dump contient 13 objets d’adresses ASSIGNED PI avec la forme stricte. Tous portent AFRINIC-HM-MNT dans mnt-by, tandis que des mainteneurs propres aux ressources apparaissent dans des attributs de niveau inférieur.

Cette structure est compatible avec l’idée que la protection de l’objet et la faculté de créer ou gérer des objets plus spécifiques ne relèvent pas exactement de la même autorité. Elle ne permet pas de connaître chaque canal d’assistance, les exceptions, l’implémentation de l’authentification ou l’historique des demandes.

La bonne question n’est donc pas : « tous les titulaires PI sont-ils bloqués ? » Il faut une matrice. Pour chaque classe, statut et combinaison mnt-by/mnt-lower, qui peut ajouter, modifier, supprimer ou corriger le pointeur ? Par quelle interface et avec quelle authentification ? Si l’écriture directe est impossible, quel service prend le relais et quel reçu permet de suivre le résultat ?

Une telle matrice protège autant contre les modifications indues que contre l’impossibilité de corriger une donnée périmée.

RDAP transporte la valeur sans en déclarer la nature

La réponse RDAP d’AFRINIC pour 160.115.0.0 contient une URL Geofeed dans une description générique de remarques. Son tableau de conformité annonce rdap_level_0, nro_rdap_profile_0 et cidr0. Il n’annonce ni geofeed1 ni un lien Geofeed structuré.

La RFC 9877 définit la relation rel: geofeed et l’extension facultative geofeed1. Un serveur peut fournir ces liens. S’il annonce l’extension, il doit fournir le lien lorsqu’il possède l’URL et peut la divulguer. Comme AFRINIC n’annonce pas l’extension dans la réponse examinée, l’absence du lien ne constitue pas une non-conformité.

Elle montre néanmoins le coût de l’implicite. Un lecteur humain et un collecteur spécialisé reconnaissent la chaîne. Un client RDAP générique ne peut pas déduire de la conformité que le service propose une découverte structurée, ni extraire la relation standard sans analyser la prose. La donnée traverse le protocole ; son contrat sémantique, lui, reste dans la remarque.

Un reçu qui n’impose pas la conclusion

Le reçu minimal devrait publier :

  1. l’identifiant du work item, son responsable, sa date d’entrée, son état et sa prochaine revue ;
  2. les versions actuelle et cible du schéma ;
  3. l’étude d’impact sur les mises à jour, le dump, WHOIS, RDAP et les collecteurs ;
  4. les droits d’écriture par classe, statut et relation de mainteneur ;
  5. la syntaxe HTTPS, la cardinalité et les erreurs de validation ;
  6. les règles de coexistence et de priorité entre remarques et champ dédié ;
  7. l’inventaire et le traitement des formes strictes, variantes et occurrences hors classes d’adresses ;
  8. la décision concernant geofeed1 et la projection RDAP ;
  9. la séparation explicite entre syntaxe, endpoint HTTPS, autorité RPKI et exactitude de localisation ;
  10. les précautions de confidentialité et de granularité ;
  11. la cohorte d’essai, les résultats, la correction et les déclencheurs de retour arrière ;
  12. un reçu de déploiement ou de clôture avec version, date, mesures et exceptions.

Ce document pourrait conclure à un report. Il pourrait conserver les remarques en ajoutant seulement une validation. Il pourrait introduire le champ sans migration automatique, puis traiter RDAP plus tard. La responsabilité ne suppose pas que la solution proposée soit adoptée. Elle suppose que la décision soit identifiable et que ses limites soient testables.

Le rôle sain d’un registre est celui d’un comptable précis, non d’un arbitre omniscient des lieux. Il doit savoir quelle valeur il reconnaît, quelle déclaration il ne fait que transporter, qui peut la modifier et comment une erreur est corrigée. Un champ dédié n’augmente pas cette autorité ; bien conçu, il en dessine la frontière.