Résumé

  • RFC 1065 définit un type d'objet par son nom, sa syntaxe, son codage et sa catégorie d'accès ; cette déclaration n'est pas la mesure courante d'une machine donnée.
  • L'arbre d'identifiants délègue des noms durables, et le vocabulaire de types discipline la représentation ; la MIB et le protocole doivent encore dire ce qui existe, comment viser une instance et ce que signifie une réponse.

Un catalogue n'était pas un tableau de bord

Les premiers systèmes de gestion TCP/IP devaient d'abord accorder les mots. Sans structure commune, une erreur d'interface pouvait rester un numéro privé, représenté autrement par chaque fabricant. Mais le même vocabulaire créait un nouveau danger : prendre le catalogue pour l'état du réseau.

Publié en août 1988, RFC 1065 sépare précisément ces tâches. Il fournit, au moyen d'ASN.1, des structures et un schéma d'identification pour les informations de gestion des internets TCP/IP. Sa Structure of Management Information est un socle, non une encyclopédie opérationnelle. Le texte dit qu'elle ne définit ni les objets effectivement gérés par un système particulier ni le mécanisme propre au protocole qui permet de désigner une instance. Ces responsabilités appartiennent respectivement à la MIB et au protocole de gestion.

La différence devient nette avec le type d'objet. Un type déclare la manière de nommer une classe d'information, la syntaxe de ses valeurs, leur codage et la catégorie d'accès applicable. C'est une description déclarative. Une instance d'objet est, elle, un type lié à une valeur à un moment donné. Le type prépare la lecture d'une réponse possible ; il ne livre ni la réponse, ni l'appareil répondant, ni la date d'échantillonnage, ni la preuve que la valeur décrit encore le système en marche.

L'arbre nommait une responsabilité avant une valeur

L'OBJECT IDENTIFIER constitue l'ossature visible de cette discipline. RFC 1065 emploie une hiérarchie d'arcs et place la gestion Internet sous iso.org.dod.internet. Une telle trajectoire numérique permet à des sous-arbres administrés séparément de coexister sans catalogue plat mondial de chaque variable imaginable.

Il serait abusif d'y voir le numéro de série d'un équipement, une clé primaire de chaque occurrence ou la garantie qu'une implémentation expose l'objet. Un identifiant d'objet est un nom structuré dont l'administration peut être déléguée. Il désigne la définition d'un type. La façon de compléter cette référence pour viser une instance, et la question de savoir si cette instance existe chez un agent, relèvent encore de règles supplémentaires.

Cette modestie a une conséquence durable. Un nom stable rend la comparaison possible, il n'efface pas les circonstances de la comparaison. Deux agents peuvent répondre avec le même type ; le même agent peut répondre à des instants différents ; une absence de réponse ne prouve pas l'absence d'un type. RFC 1065 établit la grammaire qui permet de poser ces questions au lieu de les résoudre clandestinement.

Une syntaxe rendait une valeur lisible, non vraie

Le RFC ajoute des types applicatifs comme Counter, Gauge, TimeTicks et Opaque au vocabulaire ASN.1. Ce n'est pas de la décoration. Connaître la syntaxe et le codage permet au destinataire de lire les octets sans deviner s'il reçoit un entier, un identifiant d'objet ou une chaîne d'octets.

La représentation n'est toutefois pas une provenance. Un Counter bien formé ne dit pas où le comptage a commencé ; TimeTicks ne reconstitue pas l'histoire complète d'une horloge ; Opaque ne devient pas intelligible parce que le champ qui l'enveloppe voyage correctement. Des MIB et protocoles ultérieurs peuvent donner une signification plus précise à certains types. RFC 1065 fait moins, mais fait quelque chose d'essentiel : il évite que chaque échange de gestion réinvente sa notation de base.

La limite vaut aussi pour l'accès. read-only, read-write, write-only et not-accessible classent la surface de gestion attendue pour un type. Ce ne sont ni des identifiants, ni une décision d'authentification pour un opérateur, ni la preuve qu'une modification demandée a réussi. read-write n'autorise pas tout gestionnaire : le terme indique que lecture et écriture appartiennent à la déclaration, sous réserve du système qui traite réellement la requête.

La frontière empêchait le protocole de se déguiser en base de données

La retenue de la SMI prit de la valeur à mesure que les systèmes accumulaient tables, compteurs et commandes de configuration. La MIB définit les objets ; le protocole forme une référence d'instance, transporte une demande et renvoie une réponse ; l'agent applique l'état et la politique locale ; le gestionnaire décide enfin de la confiance à accorder au résultat. RFC 1065 ne fait disparaître aucun de ces acteurs derrière un nom élégant.

RFC 1155 a ensuite rendu RFC 1065 obsolète tout en rééditant explicitement son contenu technique sans changement, hormis son statut et de petites corrections typographiques. RFC 1212 présente des conventions ultérieures pour les définitions MIB concises, tandis que RFC 2578 montre la forme SMIv2. Cette filiation ne permet pas de rétroprojeter les mécanismes ultérieurs dans le texte de 1988.

Sources et limites

RFC 1065 établit la portée de la SMI initiale, la déclaration du type, la hiérarchie d'identifiants, la syntaxe et les catégories d'accès. RFC 1155 établit la réédition techniquement inchangée. RFC 1212 et RFC 2578 servent de comparaison ultérieure. Ces textes ne prouvent ni un déploiement actuel, ni le contenu d'une MIB de fournisseur, ni l'identité de l'agent répondant, ni l'autorisation d'une session, ni un effet dans le plan de données, ni la fraîcheur d'une valeur donnée.

Lire la déclaration durable comme volontairement plus étroite qu'une observation vivante est une interprétation de cette séparation documentée.