Résumé

  • La RFC 1264 divisait la maturité d’un protocole de routage entre spécification reproductible, gestion, architecture de sécurité, implémentations indépendantes, essais complets, expérience d’exploitation et limites d’échelle.
  • La RFC 4794 supprima en 2006 cette exigence supplémentaire pour tous les documents de routage, au nom de la rapidité. Elle conserva le pouvoir de l’IESG d’exiger de l’expérience et la liberté des groupes de travail de maintenir leurs procédures.
  • Les textes ultérieurs continuèrent à distinguer statut et exécution : la RFC 6410 lia l’Internet Standard à l’interopérabilité indépendante, au déploiement étendu et à l’expérience réussie ; la RFC 7942 rendit l’état des implémentations utile mais facultatif et non nécessairement vérifié.

Le dossier d’entrée comportait plusieurs preuves

La RFC 1264 partait d’une difficulté propre au routage : un algorithme distribué en temps réel peut fonctionner dans un laboratoire, avec un logiciel et une topologie, puis échouer avec un autre fournisseur ou au-delà d’une limite inattendue. La qualité du document ne suffisait donc pas à résumer sa maturité.

Le dossier séparait la spécification et son usage, la MIB destinée à l’administration distante, l’architecture de sécurité, l’origine des codes, les scénarios et résultats d’essai, les conditions d’exploitation et l’analyse de capacité. Chaque pièce répondait à une question différente. Un texte compréhensible permettait peut-être une implémentation autonome ; il ne prouvait ni l’échange de routes ni le fonctionnement de l’authentification.

De même, une MIB définissait des états observables. Elle ne prouvait pas qu’un opérateur les surveillait, qu’une alerte apparaissait ou qu’un incident était résolu. Le projet, l’exécution et le résultat gardaient des identités distinctes.

L’indépendance était d’abord une provenance

La RFC demandait généralement plusieurs implémentations interopérables, dont au moins deux écrites indépendamment. Deux produits issus du même code peuvent reproduire la même interprétation erronée. Deux origines réellement séparées éprouvent mieux la capacité de la spécification à coordonner sans recours aux auteurs initiaux.

La liste des implémentations devait donc indiquer l’origine du code. Le rapport d’essai devait nommer les scénarios et les résultats. Pour le Draft Standard, toutes les fonctions devaient être exercées entre au moins deux implémentations, y compris les fonctions de sécurité et la protection qu’elles promettaient.

Un nombre de produits ne remplaçait pas une matrice de fonctions. Une interopérabilité réussie restait bornée aux versions, entrées et conditions observées ; elle ne démontrait pas automatiquement l’échelle, toutes les attaques ni le service reçu par les usagers.

L’expérience opérationnelle avait des coordonnées

Le mot « expérience » devait être accompagné d’une topologie, d’un environnement, d’une date, d’une durée, des implémentations présentes, de résultats et de conclusions. Les fonctions importantes devaient être exercées. Les protocoles extérieurs devaient porter l’ensemble des routes extérieures ; les protocoles intérieurs devaient aussi traiter les routes extérieures, sauf mécanisme séparé.

La charge progressait par niveau. Le Proposed Standard exigeait une implémentation et des essais des fonctions majeures, sans expérience opérationnelle obligatoire. Le Draft Standard demandait un nombre modéré de routeurs dans une topologie assez complexe, au sein de l’Internet exploité. Le Standard exigeait une grande population, une topologie complexe et du multiconstructeur.

Ces seuils étaient des conditions, non la constatation qu’un candidat précis les avait franchis. La décision de normalisation et le rapport qui la soutenait devaient rester deux objets consultables.

Le second rapport demandait où le protocole casserait

La pièce la plus exigeante était peut-être l’analyse séparée. Elle devait expliquer les algorithmes, estimer bande passante, mémoire et CPU en régime normal, projeter leur croissance dans un environnement au moins dix fois plus grand et nommer les limites ainsi que les contextes inadaptés.

Le mot « évolutif » devenait ainsi une relation entre hypothèses, ressources et frontière. La comparaison avec RIP, EGP ou d’autres protocoles rendait l’avantage annoncé contrôlable.

Mais un modèle ne constituait toujours pas une observation. La limite prévue, la limite approchée en essai et celle rencontrée en production pouvaient diverger. Les confondre aurait transformé une analyse en faux reçu de déploiement.

En 2006, le contrôle changea de détenteur

La RFC 4794 classa la RFC 1264 comme Historic. Elle jugeait qu’une règle supplémentaire appliquée à tous les protocoles de routage retardait la publication et que le processus général disposait déjà de moyens suffisants. Elle ne déclarait ni le routage simple, ni l’expérience inutile.

La suppression visait l’obligation générale. Les directeurs de la Routing Area pouvaient toujours exiger implémentation ou exploitation selon la RFC 2026. Un groupe de travail pouvait maintenir une procédure inspirée de la RFC 1264. Gestion et sécurité demeuraient prises en charge par des politiques plus larges.

L’autorité passa donc d’une liste universelle à une décision calibrée par l’IESG et les groupes. Ce gain de souplesse rendait la justification plus importante : quel risque motivait quelle preuve, qui l’avait demandée et pourquoi était-elle suffisante ?

Deux niveaux ne supprimèrent pas la différence

La RFC 2026 décrivait déjà le Proposed Standard comme une étape encore modifiable. L’implémentation et l’exploitation n’étaient généralement pas requises, mais l’IESG pouvait les imposer aux protocoles centraux ou à fort impact opérationnel.

La RFC 6410 réduisit ensuite la filière à Proposed Standard et Internet Standard. Pour le second, elle conserva au moins deux implémentations indépendantes qui interopèrent, un déploiement étendu et une expérience opérationnelle réussie, ainsi que des contrôles sur les errata, les fonctions inutilisées et les licences.

Un déploiement « étendu » reste toutefois une catégorie à dater et à délimiter. Il ne prouve pas qu’un opérateur donné a activé une fonction ni qu’un résultat particulier s’est produit.

Le registre léger annonçait lui-même sa limite

La RFC 7942 proposa une section Implementation Status facultative pour les Internet-Drafts. Elle pouvait mentionner maturité, licence, expérience, contacts et rapports d’interopérabilité, afin que le code en fonctionnement éclaire plus tôt la discussion.

Son texte type précisait que les informations fournies par les contributeurs n’étaient ni une approbation de l’IETF, ni forcément vérifiées indépendamment, ni un catalogue complet. Cette limite de provenance empêchait une entrée déclarative de remplacer les artefacts de test, la télémétrie d’exploitation ou la preuve d’un déploiement.

Sources et limites

Les critères de 1991 viennent de la RFC 1264, le processus général de la RFC 2026, et le retrait de la RFC 4794. Les deux niveaux viennent de la RFC 6410 et l’état facultatif des implémentations de la RFC 7942.

Ces textes établissent des règles et les raisons de leur évolution. Ils ne prouvent pas qu’un protocole nommé les a satisfaites, qu’une implémentation déclarée fut vérifiée, qu’un opérateur la déploya ou qu’un résultat utilisateur suivit. Le statut Historic n’efface aucune observation ancienne et ne rend aucune affirmation automatiquement fausse.