Résumé

  • RFC 1316 décrit des ports de caractères physiques ou virtuels, chacun capable de porter une ou plusieurs sessions, et donne à ces deux niveaux des objets distincts.
  • L’état administratif du port exprime ce qui est permis ; son état opérationnel décrit une condition locale. Les compteurs du port et ceux d’une session ne répondent pas à la même question.
  • Une écriture de contrôle execute demande un reset ou une terminaison selon l’objet concerné. Elle ne suffit pas à prouver l'auteur, le partenaire, la trace, la livraison ou l'effet ultérieur.

Un point d’attache ne résumait pas les échanges

Le champ de RFC 1316 allait du connecteur matériel au port virtuel d'une console distante. Un port physique correspondait à une prise matérielle ; un port virtuel était une entité logicielle comparable, dépourvue de connecteur. Tous deux pouvaient transporter un flux de caractères. Cette parenté ne les transforme pas en une identité commune ni en une session.

Le MIB ajoute en effet une seconde unité : la session. Chaque port peut en supporter une ou plusieurs. Une session est une connexion virtuelle entre le port et un partenaire, souvent au-dessus d'une pile telle que Telnet sur TCP. Le modèle ne dit donc pas « un port, un dialogue ». Il permet à l'agent de conserver le rattachement sans confondre le support et les relations qui l'empruntent.

Cette précision est importante pour les archives d'exploitation. Le nom administrativement choisi pour un port a seulement une portée locale. Son index identifie une ligne dans le MIB. Même si un port est visible et actif, ces données ne livrent ni le contenu des caractères, ni une identité vérifiée, ni l'intention d'un interlocuteur, ni le comportement d'un programme de l'autre côté.

Permission et condition ne sont pas synonymes

charPortAdminStatus décrit l'état désiré indépendamment du contrôle de flux. Enabled autorise les caractères et de nouvelles sessions ; disabled laisse passer des caractères mais interdit de nouvelles sessions ; off interdit caractères et sessions ; maintenance réserve le port à un usage exclusif, par exemple un test. C'est une règle locale sur ce que le port devrait pouvoir faire.

charPortOperStatus décrit au contraire son état opérationnel : up, down, maintenance, absent ou active. RFC 1316 précise qu’active signifie up avec un utilisateur présent, par exemple connecté. Cette information est plus riche qu'un simple voyant, mais elle reste la classification opérationnelle de l'agent. Elle ne donne pas un nom, une authentification, une autorisation, une transcription ni la preuve que le travail supposé par la session a abouti.

La coexistence des deux objets évite une phrase trop facile. Une volonté administrative et une condition observée peuvent diverger. Un port disabled peut encore laisser passer des caractères alors qu'il refuse de nouvelles sessions. Maintenance n'est pas un rapport de test réussi. Active ne transforme pas une présence au port en consentement, en réception ou en résultat applicatif. Le modèle est précieux justement parce qu'il laisse les divergences visibles.

Le total du port n’était pas un journal

Les compteurs semblent souvent fournir la preuve la plus solide, parce qu'ils s'accumulent. Or le total d'entrée de port défini par RFC 1316 comprend aussi le cadrage, les caractères de contrôle de flux XON/XOFF, les conditions BREAK, les entrées traitées localement et les entrées envoyées à toutes les sessions. Le total de sortie inclut de même du contrôle, de la sortie créée localement et les caractères reçus de toutes les sessions.

Un total en hausse est donc une observation technique, non un verbatim. Il ne désigne pas une session particulière, ne sépare pas tous les octets de données des caractères de service et n'établit ni commande comprise, ni écran vu, ni impression, ni action distante. La table de session offre des compteurs plus étroits : chacun est un sous-ensemble du compteur correspondant du port. La relation permet une attribution locale, pas un raccourci vers une preuve de bout en bout.

L'index de session ajoute une autre limite. Il n'a de sens que dans le contexte de son port et peut être réutilisé sur un autre port. Conserver « session 2 » sans port, heure et agent suffit à fabriquer une fausse continuité. Les identifiants sont des coordonnées de gestion, non une biographie automatique d'une connexion.

Connected restait une possibilité de circulation

Le nombre de sessions du port comprend les états connecting, connected et disconnecting. charSessState les précise : connected signifie que les caractères pouvaient circuler du côté réseau de la session ; connecting et disconnecting décrivent les transitions vers ou hors de cet état. Le texte ne dit pas qu'un octet déterminé a circulé, que son interlocuteur l'a interprété ou qu'une action a été exécutée.

Les objets complémentaires aident à corréler sans fermer l'enquête. L'origine d'établissement peut être unknown, network ou local. Le protocole peut être indiqué. Le connection ID peut pointer vers une information MIB locale de niveau supérieur, ou être nul si l'agent n'en possède pas. Aucun de ces objets ne crée de toute pièce l'identité du partenaire, une authentification ou un effet métier.

Une observation sérieuse retient le port, l'index de session dans ce port, l'heure, l'état administratif et opérationnel, l'état de session, le protocole et la référence disponible. Si l'on veut conclure sur un destinataire, une application ou une personne, il faut aller chercher l'évidence là où cette affirmation est réellement produite.

execute n’écrivait pas la suite de l’histoire

Les deux objets de commande rendent la discipline très concrète. Lire charPortReset renvoie toujours ready ; écrire execute provoque un reset destiné à remettre le port dans un état initial propre, matériel et logiciel, en déconnectant les sessions existantes. charSessKill possède le même schéma pour une session : ready à la lecture, terminaison lors de l'écriture execute.

Ces définitions indiquent un pouvoir de contrôle réel. Elles ne fabriquent pourtant pas un journal complet. Une lecture ultérieure de ready ne prouve pas qui a écrit execute, quelle session était présente, ce qu'un pair distant a observé, si une perte a été subie ou si une reconnexion a eu lieu. La commande, son auteur et son autorisation éventuelle doivent être conservés comme événement séparé ; les états avant/après et les observations du partenaire ou de l'application doivent rester leurs propres éléments de preuve.

Une leçon de méthode

L'ambition de RFC 1316 était pratique : rendre administrables des ports, des consoles et des sessions hétérogènes. Son héritage est aussi méthodologique. Il donne un emplacement distinct à l'intention, à l'état, au compteur, à la connexion et à la commande. Une console moderne peut afficher ces données plus vite, mais elle ne gagne pas le droit de les fusionner.

Lorsqu'un rapport annonce qu'un port était actif, qu'une session était connected ou qu'un reset a eu lieu, la bonne question est immédiatement : lequel de ces objets parle, et de quoi ne parle-t-il pas ? C'est cette retenue qui rend une enquête révisable lorsque de nouvelles traces arrivent.

Sources et limites de preuve

Cet article s'appuie sur RFC 1316, Definitions of Managed Objects for Character Stream Devices (avril 1992). Il établit les distinctions port physique/virtuel, port/session, état administratif/opérationnel, compteur agrégé/sous-ensemble de session, étapes de session et contrôles reset/kill. Il n'établit pas un port en activité, une personne nommée, une autorité, un partenaire exact, une transcription, une livraison, une sortie affichée, un résultat applicatif ou un reset réel.