Résumé

  • RFC 1442 a imposé un unique MODULE-IDENTITY par module, afin d’identifier son OID, son organisme responsable, son contact, sa dernière modification et la succession de ses révisions.
  • Le texte précise que l’expansion de cette macro se produit conceptuellement pendant l’implémentation et non à l’exécution. Elle documente donc l’artefact de spécification, pas les objets réellement présents ou accessibles sur un équipement donné.
  • RFC 1902 puis RFC 2578 ont conservé cette architecture tout en renforçant la discipline : même nom pour les changements compatibles, nouveaux descripteur et OID pour une nouvelle sémantique, conservation définitive des identifiants devenus obsolètes.

Le fichier savait quelque chose que le routeur n’avait jamais dit

Lorsqu’un outil de supervision affiche une date de révision à côté d’un équipement, la mise en page fabrique une relation. La date paraît appartenir à la machine. Pourtant, elle peut provenir exclusivement du paquet de MIB installé sur le serveur de supervision. Le routeur n’a peut-être renvoyé qu’un OID et une valeur encodée.

Cette séparation explique un phénomène courant : un collecteur récent présente proprement les données d’un agent ancien. Il connaît les libellés, les unités et les conventions textuelles les plus récentes, alors que l’agent ignore tout de ce fichier. La compatibilité permet la lecture ; elle ne transfère pas la provenance du dictionnaire à celui qui parle.

L’apport de RFC 1442 fut de rendre cette provenance documentaire explicite. Son avertissement implicite est tout aussi précieux : une preuve solide à propos d’un module ne devient pas, par voisinage, une preuve à propos d’un processus en fonctionnement.

Donner une identité au contenant

La SMIv2 distinguait trois catégories. OBJECT-TYPE définissait les objets administrés. NOTIFICATION-TYPE définissait les notifications. MODULE-IDENTITY définissait le module qui les rassemblait. Le contenant cessait ainsi d’être un simple nom de fichier pour devenir un artefact attribué et révisable.

Chaque module devait comporter exactement une invocation de MODULE-IDENTITY, après les imports ou exports éventuels. On y trouvait l’organisation responsable, les coordonnées de contact, la date de dernière édition et des clauses de révision accompagnées d’une description. L’espace de noms disposait enfin d’une mémoire interne : qui le maintient, quand le texte a changé et pourquoi.

Cette stabilité servait aussi les dépendances. D’autres modules importaient des descripteurs depuis un module nommé. Renommer celui-ci à chaque correction compatible aurait dispersé une même lignée et fragilisé les outils. Une identité durable permettait donc à la fois la traçabilité et la continuité.

Mais la macro n’était pas un objet de gestion offert par l’agent. RFC 1442 indiquait qu’elle était conceptuellement développée pendant l’implémentation, et non au moment de l’exécution. Sa syntaxe ressemble à des données ; sa fonction est déclarative. Rien n’oblige l’équipement à exposer en direct la fiche d’identité du fichier qui a inspiré son code.

Une date ne vaut qu’avec son sujet

LAST-UPDATED est un intitulé tentant. Sans contexte, il peut devenir la dernière mise à jour du firmware, la dernière installation, le dernier démarrage ou la dernière modification de configuration. Dans la SMI, son sujet est plus étroit : le module d’information lui-même. Il s’agit de sa dernière édition.

Les clauses REVISION construisaient le même type de mémoire. RFC 1442 demandait de les ordonner de la plus récente à la plus ancienne, mais les rendait encore facultatives. Une liste absente ne démontrait donc pas l’absence de changement, et une liste complète ne constituait pas un journal de déploiement.

Un système probant conserve plusieurs horloges au lieu d’en choisir une. Il date l’acquisition et le hachage de la MIB, la version du collecteur, la déclaration de firmware, la requête et sa réponse, puis la vérification du comportement observé. Chacune répond à une question précise. Les fusionner en une colonne « version » fait perdre le sujet de la date, donc sa valeur.

Le même nom couvrait une évolution sous contrainte

L’identité stable n’interdisait pas la modification. Des descriptions pouvaient être clarifiées, des références corrigées et certaines définitions étendues selon des règles compatibles. Le but n’était pas de figer le vocabulaire, mais de permettre à des implémentations anciennes et nouvelles de continuer à se comprendre sur le réseau.

Cette tolérance avait une frontière. Une modification sémantique située hors de la liste admise exigeait un nouveau descripteur et un nouvel OID. L’ancien identifiant ne pouvait pas devenir discrètement le véhicule d’un autre contrat. Le descripteur protégeait les imports ; l’OID protégeait le sens sur le fil.

Le nom du module représentait donc une lignée gouvernée, non une photographie exacte d’une implémentation. Deux fichiers pouvaient porter ce même nom à des dates différentes, tandis qu’un appareil pouvait n’en réaliser qu’un sous-ensemble. La continuité éditoriale et la présence opérationnelle restaient deux dimensions.

Les successeurs ont conservé la leçon

En 1996, RFC 1902 a remplacé RFC 1442. La nouvelle spécification a gardé les trois formes de définition, l’unique identité de module et la distinction entre implémentation et exécution. L’obsolescence du premier RFC n’a donc pas effacé la frontière qu’il avait formulée.

RFC 2578 a remplacé RFC 1902 en 1999 et a établi la SMIv2 comme Internet Standard. Il a rendu la discipline de révision plus ferme : des versions différentes peuvent conserver le même nom de module ; une révision ne doit pas créer de problème d’interopérabilité sur le réseau ; toute modification doit être enregistrée dans l’identité du module ; une définition ne doit pas être déplacée arbitrairement vers un autre module.

La règle la plus prudente concerne la disparition. Une définition déclarée obsolete ne doit pas être supprimée, et son OID ne doit jamais être réattribué. L’ancien sens demeure réservé. Cette mémoire négative empêche un logiciel plus récent d’offrir un nouveau contrat à une adresse que les anciens systèmes comprennent autrement.

Les statuts current, deprecated et obsolete qualifient ainsi la recommandation normative d’une définition. Ils ne mesurent ni son déploiement ni son accessibilité. Un objet obsolète peut répondre encore ; un objet courant peut manquer ; un objet déprécié peut rester indispensable à une chaîne ancienne.

Construire une chaîne plutôt qu’une affirmation totale

Le MODULE-IDENTITY fournit une excellente ancre documentaire. Avec l’URL d’origine et le hachage du fichier, il établit exactement quel schéma a servi à décoder une observation. Il relie le module à une organisation, un OID et une histoire éditoriale. C’est une preuve précise, à condition de ne pas lui demander davantage.

Pour parler de l’équipement, il faut ajouter des maillons. Une sonde montre quels objets ont répondu. Les erreurs distinguent absence, instance manquante et refus d’accès. L’identité de sécurité, le contexte et la vue indiquent l’étendue réellement visible. Un test contrôlé vérifie la sémantique. Une observation indépendante, éventuellement après redémarrage, vérifie l’effet et sa persistance.

La formulation honnête devient alors : le collecteur C, chargé avec le schéma dont le hachage est H, a interprété la réponse R reçue de l’endpoint E à l’heure T, sous l’identité P. Ce constat est moins compact que « E exécute la révision Y », mais il est vérifiable. Il montre également où se trouve l’incertitude.

La modestie des registres

RFC 1442 raconte une réussite institutionnelle : conserver l’identité d’une définition tout en autorisant son évolution. Le module a obtenu un responsable, une adresse durable et une mémoire. Ses successeurs ont renforcé cette méthode au lieu de la remplacer.

La confusion commence lorsqu’un registre bien tenu est supposé produire la réalité qu’il décrit. Le texte standardisé, l’entrée de compilation, le paquet reçu et l’effet physique appartiennent à des plans liés, mais distincts. Aucun ne peut être déduit intégralement du précédent.

Il faut donc garder la plaque d’identité fixe. Elle rend l’histoire auditable. Il faut seulement refuser qu’elle parle à la place de la machine située derrière la vitre.

Sources