Résumé

  • Dans RFC 2020, une écriture de configuration exprimait une intention ; l’entraînement séparait cette intention du mode effectivement accepté par le lien.
  • Cette frontière décidait de faits concrets : le cadrage courant fixait la MTU à 1 500 ou 4 464 octets, et seul l’état d’entraînement opened rendait ifOperStatus égal à up.

Une préférence n’est pas encore un résultat

Le modèle de RFC 2020 plaçait côte à côte dot12DesiredFramingType et dot12CurrentFramingType. Le premier choisissait, pour la prochaine tentative d’entraînement, un cadrage compatible IEEE 802.3, compatible IEEE 802.5, ou l’un des deux. Le second indiquait le cadrage réellement utilisé. Même quand la demande autorisait les deux formats, l’état courant devait en désigner un.

La séparation n’était pas décorative. ifMtu dépendait du cadrage courant : 1 500 octets pour la forme 802.3 et 4 464 pour la forme 802.5. Modifier le choix désiré pouvait changer la MTU après le prochain entraînement. L’acceptation d’une commande ne prouvait donc ni le cadrage obtenu ni la nouvelle MTU.

RFC 2020 refusait aussi de déduire le protocole d’accès de la forme de la trame. Une interface 802.12 pouvait employer un cadrage Ethernet ou Token Ring, tout en utilisant son propre Demand Priority Access Method. Appliquer les MIB MAC d’Ethernet ou de Token Ring à cause de cette ressemblance aurait attribué à l’interface des mécanismes qu’elle n’exécutait pas. RFC 1749 ne devenait pertinent que dans le cas plus étroit du cadrage Token Ring avec routage par la source.

L’entraînement comme frontière de preuve

Les trames d’entraînement n’étaient utilisées que pendant l’initialisation du lien. L’esclave situé en bas du lien lançait l’échange ; le maître répondait. RFC 2020 exigeait 24 trames consécutives sans erreur pour achever l’entraînement, afin qu’un lien marginal ne franchisse pas aisément cette étape.

dot12Status distinguait fermé, en ouverture, ouvert, échec d’ouverture et défaillance de lien. ifOperStatus ne passait à up que lorsque l’état était ouvert. Une commande d’ouverture, une remise à zéro ou un changement de cadrage pouvait lancer le processus ; aucun de ces déclencheurs ne constituait son résultat.

Le mode promiscuité rendait la distinction encore plus nette. dot12DesiredPromiscStatus portait la demande de la prochaine trame d’entraînement, mais le maître pouvait ne pas l’accorder. Écrire ifPromiscuousMode mettait à jour la demande et provoquait une tentative de réentraînement. Après celle-ci, le même objet devait refléter le mode en service, non le mode souhaité. dot12LastTrainingConfig conservait, lui, les bits du dernier échange sans erreur.

Le terme « maître » restait tout aussi borné. Il désignait le participant qui accordait aux nœuds demandeurs le droit d’émettre dans Demand Priority. Il ne prouvait ni la propriété de l’équipement, ni une autorité administrative, ni la livraison de paquets.

Les compteurs ne dépassaient pas leurs observations

La RFC omettait certains compteurs d’émission en priorité normale parce qu’ils pouvaient être calculés en soustrayant la haute priorité des totaux d’interface. À la réception, les erreurs et octets illisibles rendaient la situation différente. Ces formules organisaient des mesures ; elles ne démontraient pas qu’un destinataire avait reçu un paquet ou qu’une application avait terminé son travail.

La limite de sécurité est explicite : la section correspondante indique que les questions de sécurité ne sont pas abordées. Un lien ouvert, un cadrage accepté ou un total de trafic ne constitue donc ni authentification, ni confidentialité, ni preuve de fonctionnement sûr.

Deux chronologies documentaires

Les registres actuels du RFC Editor et de l’IETF classent encore RFC 2020 comme Proposed Standard et n’indiquent aucun RFC qui l’abroge. La recherche d’errata ne donnait aucun résultat correspondant le 11 septembre 2026. Ce constat porte sur la base consultée ce jour-là.

Le registre actuel de l’IEEE décrit un autre objet : IEEE 802.12-1995 y est Inactive-Withdrawn, avec retrait au 15 janvier 2001, et le groupe Demand Priority figure parmi les groupes dissous. Cette histoire postérieure ne mesure ni déploiement, ni succès commercial, ni performance. Confondre un statut documentaire avec l’état d’un réseau reproduirait précisément l’erreur que la RFC cherchait à éviter.

Sources