Résumé

  • RFC 9756 réserve des types d’erreur PCEP aux essais, sans transformer les choix numériques des participants en identifiants permanents.
  • Le passage à des valeurs attribuées par IANA doit aussi être pensé pour les outils de diagnostic, les versions encore actives et les procédures de retour arrière.
  • La sortie d’essai mérite un responsable et un budget distincts de la démonstration technique.

Dans un cahier des charges, le pilote a généralement une date, des participants et une fonction à démontrer. Sa disparition est moins souvent un livrable. Elle semble aller de soi : une fois le produit prêt, il suffirait de remplacer le provisoire par le définitif.

Les numéros de protocole rendent cette hypothèse particulièrement séduisante. Quelques constantes changent, les deux nouvelles versions se comprennent, les tests passent. Mais le numéro d’hier peut rester dans une règle de supervision, une procédure de support ou une image de secours. L’organisation a changé de logiciel sans nécessairement changer de langage partout où ce logiciel est observé.

Il ne s’agit pas ici d’un défaut identifié chez un fournisseur. C’est un problème d’acceptation que l’on peut déduire des mécanismes de RFC 9756, publié en mars 2025. Ce texte facilite l’expérimentation des erreurs PCEP et leur évolution vers des attributions durables. Il permet surtout de voir ce que le protocole prend en charge, et ce qu’un contrat d’exploitation doit encore couvrir.

Une convention entre participants

PCEP assure des échanges avec les éléments de calcul de chemins. Son socle, RFC 5440, représente une erreur au moyen d’un Error-Type et d’un Error-value. Le premier en indique la classe ; le second apporte une précision. L’unité de sens est donc le couple, pas un entier isolé dans une alerte.

Le registre PCEP d’IANA réserve désormais les types 252 à 255 à l’expérimentation, avec leurs valeurs 0 à 255. Les types 0 à 251, et toutes les valeurs correspondantes, relèvent d’IETF Review. Les participants à un essai doivent se mettre d’accord sur les couples employés et sur leur signification. Des essais simultanés utilisant les mêmes implémentations doivent éviter les collisions entre leurs choix.

Cette réserve ne distribue pas une propriété exclusive. Elle évite d’occuper arbitrairement une attribution ordinaire, mais deux expériences distinctes peuvent choisir les mêmes chiffres pour des usages différents. RFC 9756 ferme aussi une fausse échappatoire : on ne peut pas placer une valeur expérimentale sous un type d’erreur ordinaire en prétextant que la case est encore libre.

Le périmètre de l’essai devient ainsi une condition technique. L’arrivée d’un nouveau partenaire, le partage d’une implémentation ou le transfert de l’exploitation à une autre équipe peuvent modifier les hypothèses de départ. Une liste de participants obsolète n’est pas seulement un document mal tenu ; elle laisse incertaine la portée de la convention.

Pourquoi conserver un nom plutôt qu’un chiffre

RFC 9756 conseille de ne pas inscrire les couples numériques expérimentaux dans la documentation publique, notamment celle de l’IETF. Des noms textuels ou symboliques peuvent rendre la description intelligible. Cette distinction évite de donner à un choix temporaire l’apparence d’une interface promise pour longtemps.

Elle n’impose pas d’effacer les preuves d’exploitation. La documentation publique explique une fonction ; le relevé de diagnostic permet de savoir ce qui a réellement été reçu. Un opérateur peut avoir besoin du couple brut, de l’heure, du correspondant et de la version de dictionnaire qui lui donne son sens. Ce sont des pistes d’organisation du diagnostic, pas un format de journal prescrit par le RFC.

Prenons un exemple hypothétique. Le support recherche une ancienne panne après la mise à jour de son outil. Celui-ci applique son nouveau dictionnaire à tous les événements conservés. L’affichage paraît cohérent, mais l’erreur historique a changé de nom sans que le paquet d’origine ait changé. Si le contexte initial a disparu, la comparaison avant-après devient douteuse.

L’acceptation de la migration devrait donc inclure une relecture des traces anciennes. Mettre à jour les équipements prouve qu’ils peuvent employer les nouvelles valeurs ; retrouver correctement le sens d’un incident d’essai prouve autre chose. Les deux vérifications ont des propriétaires, des outils et parfois des budgets différents.

Un raccourci utile dans l’implémentation

L’expérimentation existait déjà dans PCEP. RFC 8356 réservait des espaces pour les messages, les objets et les TLV. Sa logique permettait de porter une fonction nouvelle dans un objet ou un TLV expérimental, sans ouvrir tous les sous-registres.

RFC 9756 juge ce détour peu souhaitable pour les erreurs. Créer un objet spécial contenant des erreurs arbitraires ferait diverger inutilement le code. Réutiliser le mécanisme d’erreur habituel simplifie le passage d’une expérience réussie vers un travail de normalisation.

Le bénéfice est précis : moins de structure particulière à remplacer. En revanche, les couples numériques de l’essai doivent recevoir des attributions IANA lorsque le travail avance vers une publication sur la voie des standards. Il peut s’agir de nouveaux types et de leurs valeurs, ou de nouvelles valeurs sous un type existant.

Le RFC présente le changement dans l’implémentation comme une substitution de nombres. Il ne décrit ni calendrier de déploiement d’un parc, ni négociation automatique entre deux dictionnaires, ni garantie de coexistence des anciennes et nouvelles versions. Un acheteur qui transforme cette simplicité locale en promesse de migration sans coût étend abusivement la portée du texte.

L’essai n’est pas une allocation de fait

RFC 3692 expose la difficulté à récupérer des numéros temporaires une fois qu’ils sont entrés dans des produits. Les interlocuteurs changent ; la fin réelle d’une expérience devient difficile à établir ; une réutilisation peut rencontrer des équipements encore présents.

D’où la réserve d’expérimentation, assortie de limites : pas de déploiement général implicite, pas de reconnaissance expérimentale activée par défaut dans les versions livrées. L’utilisateur doit activer et configurer explicitement l’usage, éventuellement au moyen d’une reprogrammation adaptée au produit. Un accord entre fournisseurs ne transforme pas cet espace partagé en namespace mondialement unique.

Le même RFC explique pourquoi la réussite d’un essai appelle une attribution permanente par les procédures normales. La réussite fonctionnelle apporte une raison de poursuivre ; elle ne remplace pas la coordination nécessaire à une identité durable.

RFC 9756 élargit par ailleurs les catégories de documents pouvant obtenir certaines attributions PCEP. Le passage de Standards Action à IETF Review conserve l’examen par consensus de l’IETF, tout en ne se limitant plus aux RFC Standards Track ou Best Current Practice. RFC 8126 distingue clairement cette politique de l’attribution au premier demandeur et de la politique RFC Required. Ce n’est pas une dispense de contrôle offerte à des partenaires commerciaux.

Le diagnostic reste une enquête

Une valeur inconnue dans un type expérimental reconnu peut signaler une erreur de réalisation, un désaccord entre versions du dictionnaire ou plusieurs expériences simultanées. RFC 9756 ne permet pas de choisir une cause à partir de ce seul symptôme.

Il évoque la journalisation et la possibilité de fermer la session. Il ne rend pas obligatoire la fermeture pour toute erreur PCEP. RFC 5440 prévoit des conséquences différentes selon les cas, notamment l’annulation d’une requête et, dans un autre cas, la conservation de la session existante. Le comportement réel des correspondants doit être vérifié, sans confondre silence, continuation et bonne interprétation.

La méthode rejoint le principe de réalité plutôt que plaidoyer défendu par Lu Heng : décrire la structure sous contrainte, sans lui inventer des héros ou un échec. Les sources ne mesurent ici ni adoption, ni coût, ni incident. Elles suffisent à faire apparaître une charge de travail que la formule « changement de numéro » peut masquer.