Résumé

  • La RFC 1444 distinguait le vocabulaire OBJECT-GROUP, le contrat minimal MODULE-COMPLIANCE et la revendication de version AGENT-CAPABILITIES.
  • Ces déclarations appartenaient au temps de l’implémentation : elles guidaient le gestionnaire sans mesurer l’état vivant de chaque objet.
  • La preuve restait opérationnelle : valeur raisonnablement exacte, exception honnête, accès dans la vue concernée et effet réel d’une écriture.

Une déclaration en trois étages

Dans la RFC 1444, « prendre en charge une MIB » n’était pas une case indivisible. OBJECT-GROUP réunissait des objets gérés qui formaient une unité de conformité. MODULE-COMPLIANCE fixait le minimum qu’une implémentation devait satisfaire. AGENT-CAPABILITIES décrivait ce qu’une version de produit affirmait réellement offrir, variantes comprises.

Cette structure empêchait le nom général d’un module d’effacer les différences. Certains groupes étaient obligatoires sans condition. D’autres ne le devenaient que si un protocole ou un autre groupe existait. Les groupes non cités pouvaient rester facultatifs. Un objet pouvait avoir une syntaxe de lecture plus étroite, une syntaxe d’écriture distincte ou un niveau d’accès minimal particulier.

La notice officielle date le texte d’avril 1993, au statut Proposed Standard, et indique son remplacement ultérieur par la RFC 1904. Son ambition était de rendre la conformité décomposable et contestable objet par objet.

L’obligation désignait ce qui devait être testé

Pour chaque macro, le texte précise que son développement se produit conceptuellement pendant l’implémentation, non à l’exécution. La déclaration disait ce qu’il fallait construire et ce que le fournisseur prétendait avoir construit. Elle n’interrogeait pas un processus vivant.

La règle des MANDATORY-GROUPS était pourtant exigeante : revendiquer la conformité imposait d’implémenter chaque objet de chaque groupe obligatoire. Si un objet obligatoire renvoyait noSuchObject dans toutes les vues MIB, l’agent n’était pas conforme au module. Les clauses GROUP pouvaient exprimer une obligation conditionnelle, à condition d’en écrire clairement la condition.

Le contrat réduit donc l’espace de contrôle. Il ne décide pas si la condition est remplie sur cette machine, si le principal courant voit l’objet, ni si le service qui le produit fonctionne aujourd’hui.

L’identifiant ouvrait un catalogue, pas la machine

La macro AGENT-CAPABILITIES répondait à un besoin pratique. Un logiciel de gestion ne devait pas découvrir à l’aveugle toutes les particularités de toutes les versions. Une description précise pouvait être liée à sysObjectID ou à une instance de snmpORID. Le gestionnaire lisait l’identifiant, consultait sa base et adaptait ses opérations.

Il pouvait ainsi éviter un groupe absent, traiter un objet comme lecture seule, respecter une plage de valeurs restreinte ou fournir les cellules exigées lors de la création d’une ligne. Lorsqu’un agent apprenait dynamiquement de nouveaux objets, la seule identité sysObjectID pouvait être insuffisante ; le jeu d’identifiants opérationnels ajoutait un repère.

Mais le repère menait à une affirmation de l’implémenteur. Il ne mesurait ni la santé du processus, ni la vue active, ni l’exactitude de la valeur. Une capacité déclarée est un excellent plan de visite ; ce n’est pas le rapport d’inspection.

Les variantes rendaient la vérité partielle explicite

L’exemple de la RFC est volontairement irrégulier : un objet n’est pas implémenté, plusieurs ont une syntaxe restreinte, un autre n’est accessible qu’en lecture, un même objet admet des valeurs différentes en lecture et en écriture, et la création d’une ligne exige une cellule précise.

La notation permettait ainsi de dire « partiellement » avec précision. Elle séparait absence, accès réduit et prérequis de création. Elle protégeait aussi l’identité sémantique : toute modification non éditoriale d’un groupe, d’une conformité ou d’une capacité devait recevoir un nouveau descripteur et un nouvel OID. Un identifiant ancien ne devait pas nommer silencieusement un contrat nouveau.

Le verdict appartenait à l’objet

La définition opérationnelle est plus forte que le label. Pour être implémenté, un objet devait renvoyer une valeur raisonnablement exacte aux lectures. S’il était inscriptible, une opération d’écriture devait pouvoir influencer raisonnablement l’entité gérée. En cas d’impossibilité, l’agent devait produire une exception ou une erreur, jamais une valeur fictive.

Il faut donc conserver quatre faits. La déclaration indique la capacité revendiquée par une version. La vue et le contexte d’accès indiquent ce que ce principal peut demander. Le résultat protocolaire indique valeur, exception ou erreur. Une observation indépendante établit si la valeur correspond au système et si une écriture a eu l’effet voulu, puis a persisté.

Une valeur reçue ne prouve pas seule son exactitude. Un succès d’écriture ne prouve pas seul le changement physique ou sa survie au redémarrage. Et noSuchObject ne doit jamais être transformé en zéro pour embellir un tableau de bord : l’absence est une observation.

Les successeurs ont gardé la frontière

La notice de la RFC 1904 retrace le premier remplacement en 1996. La notice de la RFC 2580 retrace le suivant, en 1999. RFC 2580 conserve l’essentiel : un groupe revendiqué exige tous ses objets ou notifications ; la capacité reste liée à une version et consultable par identifiant ; son développement reste une opération conceptuelle d’implémentation, pas une attestation en direct.

La prudence vaut aussi pour la sécurité. RFC 1444 disait ne pas traiter les questions de sécurité. RFC 3410 expliquera plus tard que l’ancien cadre SNMPv2 n’avait pas rempli ses objectifs d’authentification, confidentialité, autorisation, contrôle d’accès et administration, lacunes prises en charge par SNMPv3. Une conformité d’objets ne certifie donc pas le canal qui les transporte.

La primauté du code en fonctionnement formulée par Lu Heng donne l’ordre utile : publication, implémentation, validation, déploiement et usage ne sont pas synonymes. Sa note sur les couches de réalité rappelle qu’un énoncé et un effet exécutable doivent rester distincts.

La RFC 1444 avait déjà construit cette discipline dans sa mécanique. La déclaration réduit le coût de la preuve. L’objet vivant fournit encore la preuve.

Sources