Résumé

  • RFC 10040 est un RFC Experimental du flux IETF, issu du consensus de l’IETF, d’un examen public et d’une approbation de l’IESG. Il n’appartient pas à l’Internet Standards Track et précise que le terme Experimental décrit ici la maturité de la technologie, pas une expérimentation de terrain définie.
  • Le registre IANA conserve le type LCAF 5 sous la mention Geo-Coordinates (DEPRECATED) et attribue séparément le type 17 à Geo-Location. Une dépréciation n’est pas une suppression, et une attribution ne démontre pas qu’un produit émet ou interprète le nouveau format.
  • Une preuve de migration exploitable doit distinguer le statut documentaire, les anciens et nouveaux codes, les capacités des implémentations et des pairs, les paquets effectivement observés, le repli, le traitement des types inconnus, ainsi que la provenance, la précision et les règles d’accès des données de localisation.

Une publication ne produit pas six preuves

Le RFC Editor a annoncé RFC 10040 le 15 septembre 2026. Le texte met à jour la section 4.3 de RFC 8060, déprécie l’encodage Geo-Coordinates identifié par le type LCAF 5 et définit Geo-Location sous le type 17.

Ce parcours réunit des faits de nature différente. Le groupe de travail LISP a fait aboutir un document. L’IESG a approuvé sa publication le 15 mars. Le RFC Editor a publié le texte final six mois plus tard. L’IANA a ensuite matérialisé les libellés du registre. Aucune de ces étapes ne permet d’affirmer qu’une version logicielle donnée implémente le type 17, ni que deux nœuds en production l’échangent correctement.

Le statut du RFC le dit sans ambiguïté : le document représente un consensus de la communauté IETF, a reçu un examen public et a été approuvé par l’IESG. Il dit aussi qu’il ne s’agit pas d’une spécification de l’Internet Standards Track. L’approbation répond donc à une question de procédure documentaire. L’usage réel exige une autre chaîne de preuves.

Experimental désigne une maturité, pas un protocole d’essai

L’introduction apporte une précision rare et décisive : le travail n’est pas présenté comme faisant partie d’une « expérience », car tout RFC Experimental ne décrit pas nécessairement une expérience. La catégorie concerne le niveau de maturité de la technologie.

Cette formulation évite deux raccourcis opposés. Experimental ne signifie pas « intrinsèquement dangereux ». Il ne signifie pas non plus qu’un essai mesuré est déjà en cours. RFC 7841 présente cette catégorie comme un cadre d’examen, d’implémentation expérimentale et d’évaluation. Il ne fournit pas, pour RFC 10040, une hypothèse opérationnelle, une population de test, une durée, une télémétrie ou un seuil de réussite.

L’historique public montre que les relecteurs se sont interrogés sur les implémentations antérieures, le besoin de déploiement, la vie privée et la précision des positions. Le texte final est bien le résultat approuvé. Mais le consensus ne transforme pas les questions d’exploitation en réponses déjà observées.

Déprécié ne veut pas dire effacé

Le registre IANA des paramètres LISP conserve le type 5 sous le libellé Geo-Coordinates (DEPRECATED), avec des références à RFC 8060 et RFC 10040. Le type 17 apparaît séparément sous Geo-Location.

Le registre coordonne ainsi une préférence future sans réécrire le passé. RFC 10040 ne dit ni que le type 5 a disparu, ni que tous les récepteurs doivent le rejeter, ni que tous les émetteurs ont basculé. Réutiliser immédiatement son numéro détruirait la possibilité d’interpréter les anciens paquets et les anciennes implémentations.

La dépréciation ouvre donc une période de décision. Un émetteur qui produit uniquement le type 17 doit savoir pourquoi il pense que son pair peut l’utiliser. Un inventaire peut mêler plusieurs versions. Un contrôleur peut sérialiser le nouveau format tandis qu’un outil d’observation ou un validateur aval continue d’attendre le type 5. RFC 10040 n’instaure pas un échange universel de négociation de capacité ; le mode de preuve doit être consigné, qu’il s’agisse d’un profil bilatéral, d’un inventaire de versions ou d’un test contrôlé.

La compatibilité est asymétrique

La section 8 sépare deux cas. Les enregistrements EID Geo-Location ne sont utilisables que par les nœuds LISP capables de les traiter lors de l’enregistrement et de la recherche. Les enregistrements RLOC Geo-Location peuvent être renvoyés à un nœud qui ne les comprend pas ; ce nœud les ignore alors.

Ignorer correctement un type inconnu peut préserver le protocole tout en faisant échouer la fonction attendue. Un émetteur peut produire un corps type 17 valide, le système de mapping peut le transporter, et le destinataire peut l’ignorer conformément à sa règle locale. Aucun composant n’est nécessairement défectueux, mais aucune décision fondée sur la localisation n’a lieu.

Il faut donc une preuve directionnelle : composant et version qui ont émis le type, pair qui l’a reçu, résultat de l’analyse, usage ou ignorance de l’enregistrement, et repli ayant ou non maintenu le service. La phrase « compatible RFC 10040 » est trop large pour diagnostiquer une flotte mixte.

Un champ plus précis n’est pas une position plus vraie

Le type 17 ajoute notamment une incertitude explicite, des millisecondes pour la latitude et la longitude, des unités d’altitude et un rayon permettant de distinguer Geo-Point de Geo-Prefix. Ces choix améliorent la représentation. Ils ne certifient pas la provenance des coordonnées.

Une valeur finement encodée peut provenir d’un inventaire périmé, d’une saisie erronée ou d’une estimation beaucoup moins précise. Le champ d’incertitude transporte une déclaration ; il ne mesure pas lui-même la vérité de la position. De même, la présence de coordonnées ne prouve ni le consentement, ni l’autorité de consultation, ni la légitimité de leur conservation.

RFC 10040 évoque des politiques locales d’accès, l’application de ces politiques par un Mapping Service Provider, des réponses signées ou chiffrées, l’usage de Geo-Prefix pour réduire la précision et des TTL courts pour limiter la fenêtre d’exposition. Le RFC envisage surtout des structures et lieux publics, plutôt que des personnes, véhicules ou équipements. Chacun de ces garde-fous reste à configurer et à observer.

Le reçu de maturité et de migration

Un reçu minimal doit garder trois couches distinctes. La couche documentaire enregistre le flux IETF, la catégorie Experimental, les dates d’approbation et de publication, la section 4.3 de RFC 8060, le type 5 déprécié et le type 17 attribué. Un futur erratum ou changement de statut devient un nouveau fait daté.

La couche de compatibilité nomme l’implémentation et sa version, les rôles d’enregistrement pris en charge, la méthode de vérification de la capacité du pair, le type réellement émis et analysé, le résultat d’un type inconnu, la fenêtre de double lecture ou de repli, la portée du test, les échecs, le responsable de correction et les conditions de retrait. « Accepter les deux » doit préciser s’il s’agit seulement d’analyse, d’usage en production ou de repli actif.

La couche d’usage localise la source des coordonnées, la précision déclarée et vérifiée, Geo-Point ou Geo-Prefix, la politique d’accès, le mécanisme d’autorisation, la durée de rétention, les consommateurs aval et la procédure de correction. Elle doit distinguer « non observé », « non testé », « non pris en charge », « ignoré » et « échec d’analyse ».

La publication crée un objet de coordination commun. Le registre coordonne un nombre. La migration ne devient un fait que lorsque le logiciel l’exécute, que les pairs interopèrent et que les responsables acceptent les effets mesurés.

Sources et limites

Les sources principales sont RFC 10040, l’annonce du RFC Editor, l’historique Datatracker, le registre IANA, RFC 8060, RFC 7841 et RFC 6973. La recherche d’errata de RFC 10040 ne renvoyait aucun résultat au 21 septembre 2026.

Ces documents prouvent le statut, l’allocation et les règles du protocole. Ils ne fournissent pas une matrice exhaustive d’implémentations, un recensement des déploiements, des traces de paquets, un calendrier de migration, un audit de précision ou un registre de consentement. Cette absence borne l’analyse ; elle ne prouve pas qu’aucune implémentation n’existe.