Résumé

  • RFC 2366 distribuait l'observation et la configuration de MARS entre des tables de clients, de serveurs et de MCS, tout en autorisant la suppression d'une ligne parente malgré des lignes de VC encore présentes ou utilisées.
  • Le droit maximal read-create, la conformité minimale en lecture seule, un compteur, une notification de panne et une opération SET réussie décrivaient des preuves différentes ; aucun de ces éléments ne certifiait seul la fermeture du circuit ni la livraison.

Une ligne disparaît de la console. Pour l'opérateur pressé, l'histoire semble terminée : le client n'est plus là. Dans RFC 2366, cette conclusion était précisément celle qu'il ne fallait pas tirer.

L'objet marsClientRowStatus permettait de créer, modifier ou supprimer la ligne principale d'un client MARS. Son activation exigeait que les colonnes nécessaires soient renseignées et qu'une ligne statistique correspondante existe. Pourtant, sa suppression restait autorisée même si des lignes de tables associées, notamment celles des circuits virtuels, existaient encore ou étaient en service.

Le texte ne promettait aucune suppression en cascade. Il recommandait ensuite à l'agent, ou si possible à la station de gestion, d'effacer au moyen de SET les lignes devenues obsolètes. Entre la suppression du parent et ce nettoyage se trouvait une zone d'incertitude : un VC pouvait fonctionner encore, avoir déjà été libéré ou ne survivre que comme trace périmée.

La même règle revenait pour le serveur MARS et pour le serveur multicast MCS. La ligne principale pouvait être retirée sans attendre la disparition de ses lignes VC. Ce parallélisme est important. Il montre une décision de modélisation commune aux trois rôles, non une curiosité limitée à une table.

Le protocole sous-jacent venait de RFC 2022. Un MARS distribuait l'information d'appartenance aux groupes dans un ensemble de terminaux ATM. Un émetteur pouvait construire un VC point-multipoint vers les destinataires ou confier les données à un MCS. RFC 2366 n'était ni le serveur, ni la signalisation, ni le commutateur. Il créait un magasin virtuel d'objets permettant de regarder et parfois d'influencer ces éléments.

La surface était détaillée. Côté client figuraient l'adresse ATM, le MARS par défaut, l'état d'enregistrement, les temporisateurs, les plages multicast, les serveurs de secours, les VC ouverts et les compteurs. Côté MARS apparaissaient les cartes entre groupes et hôtes ou MCS, les membres enregistrés, les VC et les statistiques. Le MCS disposait d'un ensemble parallèle.

Mais les tables ne formaient pas une photographie atomique. Une inscription dans la liste des membres ne remplaçait pas la configuration du client. Une correspondance d'adresse ne prouvait pas l'existence d'un circuit. Une ligne VC pouvait nommer VPI, VCI, groupes, parties, type de circuit, temporisateur, MTU négociée et besoin de revalidation sans démontrer que le commutateur maintenait réellement le chemin ni qu'un récepteur recevait les paquets.

La faculté d'agir variait également selon l'origine des lignes. Les cartes configurées pouvaient être administrées. Celles apprises dynamiquement ne pouvaient être ni modifiées ni supprimées par la même commande RowStatus. Certaines propriétés d'un VC actif restaient ajustables, mais une ligne correspondant à un SVC ne pouvait pas être modifiée ou détruite par cette voie. La station de gestion ne dominait donc pas uniformément ce qu'elle voyait.

Une autre limite se cachait dans les déclarations de conformité. De nombreux objets portaient MAX-ACCESS read-create. Cette syntaxe définissait la capacité maximale prévue par le module. Toutefois, les déclarations de conformité de RFC 2366 abaissaient l'accès minimal à read-only et répétaient que l'écriture n'était pas obligatoire.

Un agent pouvait ainsi être conforme tout en n'offrant qu'une fenêtre d'observation. RFC 1904 précisait qu'un objet réellement écrit devait permettre au SET d'influencer raisonnablement l'entité gérée. Afficher automatiquement un bouton « modifier » à partir de la seule syntaxe revenait à confondre le plafond du modèle avec la capacité du produit rencontré.

Même un SET accepté ne fermait pas toute la chaîne de preuve. Il fallait encore connaître le principal authentifié, la vue autorisée, la valeur appliquée, sa persistance, la réaction de la signalisation ATM et l'état du trafic. Une réponse SNMP réussie n'était pas un reçu remis par le commutateur ni par le destinataire.

Les compteurs répondaient à des questions encore plus étroites. Ils totalisaient requêtes, JOIN, LEAVE, réponses multiparties, NAK, migrations et expirations de délai. Le serveur MARS comptait aussi les groupes disposant de membres ou de MCS enregistrés. Sans instant de collecte, référence précédente et contexte de remise à zéro, même une variation pouvait être ambiguë. Avec ces éléments, elle établissait une activité de contrôle, pas une livraison de données.

Le modèle séparait aussi valeur par défaut et valeur négociée. Le MTU du client ou du MCS fournissait un défaut de groupe ; chaque VC pouvait en négocier un autre. Les numéros de séquence HSN, CSN et SSN aidaient à repérer des messages manqués ou des changements d'appartenance, mais ne certifiaient pas le chemin de données. La notification marsFaultTrap annonçait une condition détectée ; émission, transport, réception par le gestionnaire, diagnostic, réparation et rétablissement demeuraient successifs.

La section sécurité nommait franchement le danger. Des objets en écriture dans un environnement insuffisamment protégé pouvaient nuire aux opérations. SNMPv1 ne décidait pas qui, sur un réseau par ailleurs sécurisé, avait le droit de créer, changer ou supprimer les objets. Le texte recommandait le modèle utilisateur et le contrôle d'accès par vues de SNMPv3. Il ajoutait que la lecture elle-même pouvait nécessiter un contrôle.

En effet, une vue en lecture seule pouvait révéler adresses ATM, membres, associations, préférences de secours, extrémités de circuits, MTU, temporisateurs et pannes. Chiffrer le transport, authentifier l'appelant, autoriser une vue et justifier l'usage opérationnel n'étaient pas la même décision.

L'histoire de l'identifiant du module fournit une dernière séparation. RFC 2366 avait placé le MIB sous snmpModules. En septembre 1998, RFC 2417 l'a rendu obsolète pour corriger cette attribution et le rattacher à mib-2 57. Les objets et leur logique furent conservés ; leur adresse publique changea. Même un modèle sémantiquement stable a besoin d'une coordonnée correcte pour être partagé.

La leçon n'est donc pas que la gestion était inutile. RFC 2366 a rendu trois rôles complexes interrogeables avec un vocabulaire commun. Sa rigueur tenait à ce qu'il ne transformait pas cette commodité en omniscience. La ligne avait disparu. Le circuit, lui, demandait encore une preuve.

Sources