Résumé

  • La RFC 2366 plaçait marsMIB sous { snmpModules 17 }. Publiée deux mois plus tard, la RFC 2417 parle d’une erreur d’attribution administrative et la place sous { mib-2 57 }.
  • Le développement des chemins symboliques donne deux racines numériques distinctes : 1.3.6.1.6.3.17 et 1.3.6.1.2.1.57. Les objets définis sous la MIB héritent du préfixe corrigé.
  • Cette MIB décrit des objets de gestion pour les clients et serveurs MARS ainsi que les serveurs multicast. Le changement de leurs noms ne signale pas, à lui seul, une modification des agents, des gestionnaires, des groupes, des circuits virtuels ou du transfert des paquets.

Une correction de branche aux longues conséquences

Un identifiant d’objet (OID) est un chemin hiérarchique, pas une étiquette ajoutée à un nombre fixe. Chaque arc désigne un enfant de son parent. En juillet 1998, la RFC 2366 définissait le module de gestion MARS comme marsMIB ::= { snmpModules 17 }. En septembre, la RFC 2417 a rendu ce texte obsolète. Sa note à l’IANA qualifie l’attribution antérieure d’erreur administrative ; sa note de révision demande de « reroot this MIB from snmpModules to mib-2 », et son identité de module devient marsMIB ::= { mib-2 57 }.

Le calcul rend l’ampleur de la correction visible. La RFC 1902 place snmpModules sous snmpV2, lui-même sous internet ; MIB-II, RFC 1213 place mib-2 sous mgmt et internet. L’ancienne racine se développe donc en 1.3.6.1.6.3.17, la nouvelle en 1.3.6.1.2.1.57. Les descendants du module étant définis relativement à marsMIB, leurs chemins numériques héritent eux aussi du nouveau préfixe.

Il s’agit bien d’un changement d’identité dans l’espace de noms de gestion. Ce n’est pas, en soi, un changement de fonctionnement de MARS. La RFC 2022 décrit MARS comme le mécanisme grâce auquel des équipements de réseaux ATM s’enregistrent pour des groupes multicast ou interrogent leur appartenance, puis utilisent des maillages de circuits virtuels ou un serveur multicast pour distribuer le trafic. Les tables de la RFC 2417 donnent des vues des clients, serveurs, groupes, correspondances, circuits virtuels, états, temporisateurs et statistiques. Elles décrivent ce qu’un agent peut rapporter ; elles n’exécutent pas la distribution des adhésions et ne prouvent pas quel circuit transporte un paquet.

La distinction importe, car « la MIB a changé » peut renvoyer à plusieurs niveaux : un document normatif, un OID symbolique, le nom numérique compilé dans un agent, les objets interrogés par un gestionnaire et le comportement du réseau observé par l’exploitant. La RFC 2417 établit les deux premiers. Elle ne nomme aucun fournisseur ni agent mis à jour, aucun système de supervision converti, pont de compatibilité, incident ou migration achevée de parc. Le statut de texte successeur indique quelle attribution la norme retient, pas la vitesse à laquelle les équipements en service l’ont suivie.

Le registre IANA SMI Numbers actuel inscrit l’arc 57 de mib-2 comme marsMIB, en citant la RFC 2417, et marque obsolète l’ancienne entrée de l’arc 17 de snmpModules. C’est une confirmation utile de l’état présent du nommage du registre. Ce n’est pas un recensement rétrospectif des déploiements. La RFC 2417 indique aussi que ce module s’utilise avec l’ATM-MIB de la RFC 1695, MIB-II de la RFC 1213 et, facultativement, IF-MIB de la RFC 1573 : des dépendances entre modèles de gestion, non la preuve qu’un agent précis les exportait.

La limite de preuve fait l’histoire

On pourrait imaginer un exploitant voyant chaque objet MARS disparaître d’une branche puis réapparaître dans l’autre. Les documents ne racontent pas cette scène. Un gestionnaire configuré pour l’ancien sous-arbre numérique aurait pu nécessiter une nouvelle vue ; un agent compilé pour exposer le sous-arbre corrigé aurait pu répondre à une requête différente. Ce sont des conséquences plausibles du changement de nom, pas des événements historiques documentés.

Pour savoir si un système acceptait les deux noms, a changé de configuration ou a subi des échecs d’interrogation, il faudrait des preuves d’implémentation ou d’exploitation qui manquent ici.

Les notes de Heng Lu sur la primauté du code en fonctionnement et les couches de réalité offrent une grille utile : attribution symbolique, implémentation, interprétation du gestionnaire et service observé sont des affirmations différentes. Cette grille ne fournit aucune preuve sur les déploiements de 1998.

La leçon étroite est donc plus solide qu’une anecdote de migration impossible à étayer : une correction de registre peut modifier l’identité sous laquelle un logiciel de gestion trouve une information, et déplacer avec elle chaque nom descendant, alors que l’action réseau observée reste une question distincte. L’arbre documentaire a bougé. Les RFC ne disent pas que MARS lui-même a bougé.

Sources