Résumé

  • RFC 9515 fait passer les valeurs 32768–65530 de six registres du BGP Monitoring Protocol de Specification Required à First Come First Served.
  • L’attribution devient moins coûteuse et limite l’occupation sauvage des codes, mais elle ne comporte aucun filtrage technique ni obligation de spécification interopérable.
  • Le reçu IANA doit rester distinct des preuves de sens, de code, de lecture par les collecteurs, de protection du transport et d’usage en production.

Une demande bien formée arrive chez IANA. Le nombre demandé est disponible ; il est donc attribué. Aucun expert désigné n’a à décider si le document permettrait à deux équipes indépendantes de produire le même comportement. Avec First Come First Served, cette absence d’examen n’est pas une anomalie : c’est la règle choisie.

RFC 9515 répond à un problème concret. Une barrière trop haute pousse les implémenteurs à utiliser des codes non enregistrés, jusqu’au jour où deux significations se rencontrent. Une attribution précoce retire ce risque de collision. Elle n’ajoute aucune preuve positive sur la qualité de l’extension.

Une réforme limitée à six plages

La nouvelle politique vise 32768–65530 dans BMP Statistics Types, Initiation and Peer Up Information TLVs, Termination Message TLVs, Termination Message Reason Codes, Route Mirroring TLVs et Route Mirroring Information Codes. Les valeurs 0–32767 restent soumises à Standards Action ; 65531–65534 demeurent expérimentales et 65535 réservé.

Le protocole n’est pas redessiné. RFC 7854 avait placé ces plages sous Specification Required. L’expérience a montré que cette politique ressemblait en pratique à Standards Action et ne constituait pas la voie légère attendue.

RFC 8126 permet de mesurer l’écart. First Come First Served n’exerce pratiquement aucun filtrage : la demande recevable obtient une valeur libre. Specification Required ajoutait l’approbation d’un expert et une spécification publique, durable, claire et techniquement suffisante pour des implémentations indépendantes. RFC 9515 retire volontairement ces deux conditions.

Ce point le distingue de RFC 9519 pour SSH et de RFC 9650 pour un registre IS-IS : ces deux réformes conservent un Expert Review. Pour les six plages BMP, le registre ne porte plus ce jugement. Le vocabulaire historique de RFC 5226, cité par RFC 7854, permet de comparer l’ancienne base à l’autorité actuelle de RFC 8126.

Ce qu’établit réellement une ligne du registre

Le registre BMP d’IANA affiche désormais First Come First Served et cite RFC 9515. Une ligne peut établir qu’à une date donnée un nombre public a été relié à une description et à une référence, sans double attribution connue dans ce registre.

Elle n’établit pas les unités, les erreurs, la compatibilité ou les changements de version. Elle ne montre pas que deux routeurs émettent la même charge ni que deux collecteurs la lisent de la même manière. Un tableau de bord peut afficher une courbe parfaitement nette tout en ayant perdu la provenance et la version du champ.

Or BMP exporte des vues de routes, des événements de voisins, des messages BGP recopiés et des statistiques. RFC 7854 avertit aussi qu’un flux BMP peut révéler des routes privées et qu’en l’absence de protections, un attaquant peut usurper le routeur ou le collecteur, lire le trafic ou le modifier. L’unicité du type ne donne ni authenticité ni vérité opérationnelle.

Les preuves déplacées vers l’aval

Le dossier d’attribution doit conserver registre, plage, demande, valeur, description, référence, demandeur, responsable du changement, contrôle de disponibilité et horodatages. Le dossier sémantique ajoute une spécification versionnée, des exemples binaires, unités, cardinalités, erreurs et règles de compatibilité. Le dossier d’implémentation nomme commits, versions, rôles et tests ; le dossier de production ajoute périmètre, transport protégé, provenance, migration et retour arrière.

Cette séparation empêche un fournisseur de présenter le numéro comme une approbation technique. Elle empêche aussi de considérer l’attribution comme illégitime au seul motif qu’aucun expert ne l’a examinée. FCFS doit être évalué sur sa capacité à coordonner sans collision ; l’extension, sur les preuves qu’elle produit en fonctionnement.

La page IANA est vivante. RFC 9736 et RFC 9972 ont ensuite modifié des espaces BMP. Il faut donc conserver la version de politique et la date d’attribution au lieu de lire le registre actuel comme une photographie de 2023.

La trace comprend la fiche RFC, le texte, le XML, les errata, l’historique Datatracker et le dernier brouillon. Elle prouve la réforme, pas le fonctionnement d’une extension future.

Les essais de Heng Lu sur la primauté du code en marche, la spécification minimale et l’adoption volontaire et les couches de réalité fournissent la discipline : ne pas laisser un symbole institutionnel se faire passer pour un résultat opérationnel.