Résumé

  • La RFC 2155 réservait DisplayableDlcAddress à l’affichage et renvoyait vers une MIB propre au DLC pour retrouver les octets réellement placés dans l’en-tête de liaison.
  • Un nom de point de contrôle pouvait venir d’un échange XID ou d’une configuration locale ; une ligne historique pouvait survivre à la liaison ; l’état et la réussite d’une session avaient leurs propres preuves.
  • Un dossier défendable relie donc le libellé à l’instance, au type de DLC, au RowPointer, aux octets et à leur portée, puis à l’état horodaté et au résultat de session.

Un champ fait pour les yeux

Sur une console d’exploitation, les caractères ont un pouvoir trompeur : ce qui est lisible paraît stable, et ce qui est stable paraît utilisable comme identifiant. La RFC 2155, publiée en juin 1997 comme Proposed Standard pour APPN, a précisément refusé ce raccourci.

Son type textuel DisplayableDlcAddress accepte de zéro à 64 caractères ASCII. La station de gestion doit s’en servir uniquement pour l’affichage. L’adresse DLC « réelle », c’est-à-dire les octets circulant dans l’en-tête, se trouve souvent dans la MIB propre au DLC. « Souvent » ne promet pas une résolution universelle, et l’adresse affichée n’est pas forcément fausse : elle n’est simplement pas l’autorité sur la représentation filaire. Une chaîne vide signifie que l’agent ignore l’adresse ; une chaîne remplie ne prouve ni unicité, ni actualité, ni adjacence.

Le RowPointer marque le passage de compétence

Les lignes de port et de station de liaison présentaient des adresses locales ou distantes, mais aussi appnPortSpecific ou appnLsSpecific. Ces RowPointer visaient un objet de la MIB du DLC ; 0.0 signalait que l’agent ne pouvait pas l’identifier. Le rapprochement sérieux doit conserver l’instance APPN, le type de DLC, le pointeur, l’interface, l’adresse inférieure et l’heure de collecte.

La RFC 1747 illustre ce partage pour SDLC : l’adresse de station est une valeur de sondage de 1 à 255, unique seulement dans sa portée définie, et l’état de contact est distinct. La RFC 2024 décrit encore d’autres formes pour DLSw, notamment une adresse MAC de six octets et une adresse IP de quatre octets dans l’ordre réseau. Une seule chaîne destinée à l’écran ne transporte pas à elle seule ces encodages et ces portées.

Le voisin familier pouvait être une attente locale

appnLsAdjCpName pouvait provenir du nom du point de contrôle reçu par XID. En l’absence de XID, l’agent était toutefois autorisé à renvoyer une valeur définie localement ; sans l’une ni l’autre, il renvoyait une chaîne vide. Le même nom pouvait donc signifier « observé chez le pair » ou « attendu par l’opérateur ».

L’identifiant du nœud partenaire provenait d’octets déterminés du XID. La valeur ASCII 00000000 signalait son indisponibilité, et une convention se terminant par cinq zéros pouvait indiquer que l’identifiant n’était pas unique sur le nœud. Le numéro de groupe de transmission 256 signifiait non négocié ou inconnu. La familiarité visuelle ne remplace pas la provenance.

Présent, passé et réussite ne sont pas synonymes

La station de liaison avait un état opérationnel séparé : inactive, en attente d’activation, active ou en attente de désactivation. Compteurs XID bons et mauvais, heure d’activation et entrée dans l’état courant formaient d’autres observations. L’adresse ne synthétisait aucun de ces faits.

La table de statut conservait seulement des événements d’activation, de XID ou de terminaison exceptionnels ou potentiellement exceptionnels. Une opération normale ne produisait aucune ligne, et la durée de conservation dépendait du produit. Une ligne visible est donc un souvenir, pas une adjacence actuelle. Plus haut encore, la RFC 2155 excluait la surveillance et le contrôle des sessions terminales : une liaison active n’atteste pas la réussite d’une session ou d’une application.

La notice RFC Editor et l’historique Datatracker situent le document. La RFC 2455 l’a remplacé en novembre 1998 après des ajouts architecturaux et de l’expérience d’implémentation, tout en conservant exactement cette frontière d’affichage. Les textes de Heng Lu sur la primauté du code en fonctionnement, la spécification initiale minimale et les couches de réalité servent ici de grilles éditoriales déclarées, et non d’exigences de la RFC.

Sources