Résumé

  • Dans le RFC 2051, les tables Admin montrent en lecture seule les valeurs attendues, tandis que les tables Oper témoignent de l’état courant ou négocié ; une ligne Admin de mode peut disparaître alors qu’une session active et sa ligne Oper subsistent.
  • Sessions, conversations, compteurs facultatifs et historiques d’arrêt anormal ont des cycles de vie distincts. Aucun ne prouve à lui seul la configuration, l’accord du pair, la réussite applicative, l’exhaustivité ou la sécurité.

L’objet décisif du RFC 2051 est une ligne absente. Le texte autorise la suppression d’une appcModeAdminEntry alors qu’une session active utilise encore ce mode. L’appcModeOperEntry correspondante reste présente. Ce n’est pas une incohérence : la consigne administrative a disparu, le fait opérationnel continue.

Les tables Admin représentaient des valeurs par défaut ou attendues. Le MIB ne créait ni ne modifiait cette configuration, d’où des objets en lecture seule. Les tables Oper décrivaient ce qui existait à l’instant ou ce que deux systèmes avaient négocié. Un objet dynamique pouvait naître d’un modèle Admin puis suivre son propre cycle de vie.

Il faut donc distinguer « configuré », « demandé », « accepté par l’agent », « négocié » et « actif ». La suppression d’une ligne Admin ne rembobine pas une session établie. La persistance d’une ligne Oper ne signifie pas davantage que l’ancienne configuration reste autorisée pour une prochaine session.

Le RFC répartissait ses objets entre groupes global, LU, programme transactionnel, session, conversation et CPI-C. Cette ampleur ne faisait pas du MIB une télécommande générale. Il ne permettait pas normalement de créer ou supprimer les LU partenaires, modes et programmes, ni d’activer les LU, de lancer les conversations ou d’activer les sessions.

Quelques commandes étaient prévues : choix de la collecte statistique et du traçage, commandes CNOS, demande de désactivation d’une session. Une écriture prouvait qu’une demande avait atteint la surface de contrôle, pas que son effet s’était produit.

CNOS matérialise la séparation. Les objets administratifs portaient les valeurs souhaitées ; les objets opérationnels, les valeurs réellement négociées. La documentation IBM actuelle sur le démarrage des sessions développe CNOS en Change Number Of Sessions. Elle éclaire le terme, sans démontrer qu’un système donné implémente le RFC ni qu’une négociation a abouti.

La table des sessions actives suivait unbound, pendingBind, bound et pendingUnbind. L’agent créait et retirait les lignes selon ces transitions. Écrire unbound sur une session liée pouvait déclencher une désactivation ; l’écriture attestait la demande, l’état ultérieur attestait la suite donnée.

Même bound ne prouvait qu’un état de session. Il ne disait pas qu’une conversation avait été allouée, qu’un programme avait terminé, que le pair avait répondu correctement ou qu’un processus métier avait réussi. Le pair et l’application restaient des témoins séparés.

La conversation avait une durée plus courte. L’agent créait sa ligne au démarrage et la supprimait à la fin. Elle utilisait une session sans se confondre avec elle : plusieurs conversations pouvaient se succéder sur une session toujours active.

Les statistiques formaient une couche facultative. Lorsque la collecte était active, une ligne apparaissait pour chaque session. Les compteurs étaient des Counter32 du RFC 1902, accompagnés d’un temps de fonctionnement. Sans intervalle, sans traitement du bouclage et sans état de collecte, le chiffre n’était pas un historique complet.

Le RFC précise qu’un passage de la collecte administrative à l’état inactif retire toutes les lignes statistiques. Les sessions actives, elles, ne sont pas nécessairement interrompues. Une table vide peut donc signifier « mesure arrêtée » plutôt que « aucune activité ».

L’historique était sélectif : arrêts anormaux de sessions et conversations terminées en erreur. La quantité et la durée de rétention dépendaient de l’implémentation. Une absence ne démontrait ni l’absence d’activité normale, ni la conservation de toutes les anomalies passées.

Le RFC 1666 situe le modèle dans la famille de gestion SNA. Cette filiation ne constitue pas une preuve de déploiement. Une norme définit des objets ; elle ne montre pas qu’un opérateur les a installés, activés, protégés ou correctement interprétés.

Le statut documentaire appelle la même rigueur. Le Datatracker de l’IETF et la fiche du RFC Editor indiquent Proposed Standard, Standards Track, octobre 1996. L’index des changements de statut figé pour cette recherche ne mentionne pas le RFC 2051, et aucun RFC de remplacement n’est indiqué. Le texte est ancien et la technologie patrimoniale ; son statut officiel n’est pourtant pas établi comme Historic.

La recherche d’errata ne renvoie aucune correspondance. Cela réduit une incertitude documentaire, sans certifier les implémentations, l’interopérabilité ou l’actualité.

Enfin, le RFC déclare ne pas traiter les questions de sécurité. Son appartenance au Standards Track ne prouve ni contrôle d’accès, ni sûreté des écritures, ni fiabilité des compteurs. Une session active peut être non sûre ; un objet de gestion ne révèle pas qui avait le droit de changer le système.

La bonne lecture consiste donc à attribuer une compétence à chaque témoin. Admin décrit la configuration affichée ; l’objet inscriptible, la demande ; l’agent, la transition ; CNOS Oper, le résultat négocié ; la session, la relation active ; la conversation, une interaction ; les compteurs, une fenêtre mesurée ; l’historique, certains échecs conservés. Le pair et l’application doivent produire leurs propres preuves.

Sources