Résumé

  • La RFC 9650 remplace Standards Action par Expert Review pour le registre IS-IS Neighbor Link-Attribute Bit Values, afin que l’expérimentation puisse obtenir une valeur coordonnée sans occuper clandestinement un bit libre.
  • L’avis de l’expert et l’inscription IANA attestent l’attribution d’un symbole ; ils n’attestent ni la qualité du protocole, ni sa présence dans un logiciel, ni son activation, ni son effet sur une route.
  • La preuve exploitable relie la demande, la décision, le registre, la version construite, l’autorisation locale, le paquet émis, l’analyse par le voisin, la politique et le résultat observé.

L’illusion d’une autorisation complète

Une équipe prépare une fenêtre de maintenance. Le registre public contient le bit recherché, son nom et une RFC. La case « standardisé » passe au vert. Pourtant, ce que l’écran a vérifié n’est pas ce que le changement va faire.

La RFC 9650 corrige un problème plus étroit. La RFC 5029 imposait Standards Action pour attribuer les bits du sous-TLV Link-Attributes. Cette exigence empêchait en pratique d’attribuer des bits à des protocoles expérimentaux. Les auteurs risquaient alors de prendre un code non enregistré, et deux expériences pouvaient occuper la même position. La nouvelle procédure est Expert Review.

Le registre devient plus accessible pour conserver l’unicité. Il ne devient pas une commission de mise en production.

Un petit champ, plusieurs réalités

La RFC 5029 définit le sous-TLV 19 et un champ de drapeaux sur 16 bits. 0x1 signifie que la protection locale est disponible ; 0x2 indique qu’un lien doit être exclu du calcul d’un chemin de protection. Le sous-TLV est facultatif, ne doit apparaître qu’une fois pour un voisin et peut être ignoré silencieusement par un routeur qui ne le prend pas en charge.

Le registre IANA affiche aujourd’hui Expert Review, les experts désignés et les références RFC 5029, 9667 et 9650. Il contient aussi 0x4, Local Edge Enabled for Flooding, défini par la RFC 9667.

Cette table établit le sens public assigné. Elle ne révèle pas le contenu d’une image logicielle, la configuration d’un routeur ou le calcul effectué après réception. Le même bit peut être enregistré, correctement émis puis silencieusement ignoré. Il peut être compris et néanmoins écarté par une politique locale. Il peut modifier une entrée de calcul sans modifier le service observé.

Ce que l’expert examine — et ce qu’il ne promet pas

La RFC 8126 recommande la procédure la moins stricte qui convienne réellement au registre. Une procédure trop coûteuse décourage les demandes ; l’usage réel se déplace alors hors du registre et la coordination s’affaiblit. Expert Review reste cependant une revue documentée, menée par un expert désigné, et non une réservation automatique.

La RFC 7370 encadre l’examen pour IS-IS. L’expert vérifie normalement que la demande vient d’un document de groupe de travail ou d’un travail destiné à être parrainé par un Area Director. Il consulte le consensus ou l’accord pertinent, puis apprécie le mérite technique. Il ne remplace pas le consensus de l’IETF. Après son accord, IANA inscrit la valeur et sa référence. Si le document n’aboutit pas, le mécanisme d’expiration et de désallocation s’applique.

La décision est donc : « cette demande peut recevoir une place unique sous ces critères ». Elle n’est pas : « cette extension est sûre, interopérable, livrée et adaptée à votre réseau ».

Pourquoi l’attribution précoce protège l’interopérabilité

La RFC 7120 décrit le piège des valeurs apparemment libres. Une implémentation pré-RFC a besoin d’expérience, mais la publication formelle n’est pas terminée. Si elle choisit un numéro seule, IANA peut finalement attribuer un autre numéro au même mécanisme, ou donner le numéro choisi à une autre extension. Dans le premier cas, les premières versions ne parlent plus le langage final ; dans le second, deux langages partagent le même symbole.

L’attribution coordonnée rend publique une convention provisoire et son cycle de vie. Elle réduit le coût d’une expérimentation honnête. Elle ne dispense pas de prévoir l’expiration, la désallocation ou la renumérotation si le document s’arrête.

Construire une chaîne de quittances

La première quittance conserve la demande exacte, la révision du document et la fonction sollicitée. La seconde nomme l’expert, les critères appliqués, les réserves et la décision. La troisième capture la ligne IANA, la valeur, la référence et l’état de cycle de vie.

Ensuite commence l’autorité de l’ingénierie : commit, provenance de construction, tests d’émission et d’analyse, traitement des bits inconnus, comportement en cas de sous-TLV dupliqué. L’autorité de changement conserve l’identité de l’approbateur, les équipements, la configuration, l’heure et le retour arrière. L’exploitation relie le LSP émis à sa réception, au résultat du parseur, à la politique locale, au calcul de route et à l’observation du service.

La primauté du code exécuté interdit de remplacer ces preuves par un lien vers le registre. Le registre décrit le vocabulaire ; le binaire chargé et le paquet reçu décrivent l’événement.

La sécurité reste à son propriétaire

La RFC 9650 précise qu’elle ne change pas les questions de sécurité de la RFC 5029. Celle-ci rappelle que les informations supplémentaires peuvent être observées dans les LSP et que leur modification pose un risque. Chaque mécanisme doit traiter la divulgation, la modification et, lorsque nécessaire, l’intégrité.

Une procédure d’attribution ne protège pas le paquet, ne valide pas le parseur et n’autorise pas le changement. Cette séparation est saine : réduire le risque de collision ne doit pas faire disparaître les responsables de la sécurité logicielle ou de la politique de routage.

La spécification initiale minimale fournit ici une architecture claire. Le niveau commun garantit l’unicité et un sens documenté. L’adoption, l’exécution et le jugement restent localisés. Les couches de réalité empêchent la demande, l’avis, la ligne du registre, le logiciel et la route de se substituer l’un à l’autre.

Sources