Résumé

  • RFC 1052 choisit SNMP comme base de gestion à court terme et consigna le retrait volontaire de HEMS. Dans le même mouvement, il demanda que les définitions de RFC 1024 servent d’entrée au chantier de la MIB commune.
  • Publié après cette décision, RFC 1076 décrivit un autre modèle d’exécution : un petit interpréteur lisait un flux ASN.1, parcourait un arbre de données, filtrait des tables mouvantes et renvoyait l’image des valeurs représentées après l’opération.
  • Le choix du protocole, la réutilisation d’une sémantique, l’autorisation d’une requête, la valeur renvoyée et l’effet observé sur le réseau demeuraient cinq faits distincts.

Le retrait qui rendit l’accord possible

À la fin des années 1980, administrer l’Internet signifiait administrer une diversité croissante. RFC 1021 partait d’un constat très concret : lorsque quelques fabricants fournissaient la plupart des passerelles, un administrateur chevronné pouvait apprendre plusieurs outils privés. Avec la croissance du réseau et du nombre de fournisseurs, cette connaissance artisanale ne formait plus un système commun.

HEMS, le High-Level Entity Management System, proposait de répartir les rôles. Un processeur de requêtes réduit vivait dans l’entité gérée ; un générateur émettait des événements spontanés ; des applications plus intelligentes formulaient les demandes et interprétaient les réponses. L’appareil exposait une vue commune de ses données sans devoir contenir toute l’intelligence du centre de gestion.

RFC 1021 séparait déjà surveillance et contrôle. Surveiller consistait à recueillir des données pour comprendre un comportement. Contrôler consistait à tenter de le modifier en temps réel. Le second supposait le premier : changer un réseau sans pouvoir observer l’effet du changement n’avait guère de valeur. HEMS définissait des mécanismes de contrôle, mais reconnaissait que les opérations génériques et les protections d’accès fortes restaient incomplètes.

Puis vint la décision institutionnelle. RFC 1052 rend compte de la revue menée par l’IAB en mars 1988. Trois familles se côtoyaient : HEMS, SNMP et l’approche CMIP/CMIS issue de l’ISO. L’IAB recommanda SNMP comme base à court terme, avec une justification de déploiement : du logiciel existait et fonctionnait déjà, tandis qu’un accord rapide devenait nécessaire.

Le document rapporte aussi que Craig Partridge proposa de retirer HEMS de la compétition afin d’ouvrir la voie à un accord à l’échelle de l’Internet. Ce retrait ne fut pas suivi d’un effacement intellectuel. Le même texte qualifia le travail HEMS sur les éléments surveillés de riche et largement discuté. Il chargea le groupe MIB de prendre les définitions de RFC 1024 comme l’une de ses entrées, avec les matériaux SNMP et CMIP/CMIS.

Une décision pouvait donc fermer une voie de transport sans jeter toutes les définitions transportées par cette voie.

Un langage publié après la sélection

RFC 1076 date de novembre 1988 et remplace RFC 1023. Cette chronologie exclut l’idée d’une nouvelle victoire cachée : sept mois après le choix à court terme, les auteurs achevèrent la description du langage expérimental HEMS.

La requête n’était pas un appel distant unique. Elle contenait une suite d’objets ASN.1. Les objets de données arrivaient sur une pile bornée ; les codes d’opération étaient exécutés immédiatement. L’agent pouvait produire une partie de la réponse avant d’avoir reçu la fin de la requête. Pour une passerelle critique, ce traitement en flux limitait mémoire, attente et nombre d’allers-retours.

L’interpréteur ne connaissait que huit actions : BEGIN, END, GET, GET-ATTRIBUTES, GET-RANGE, SET, CREATE et DELETE. Il ne stockait pas de programme, n’avait ni sous-programme ni branchement général. Pourtant, chemins, gabarits, valeurs et filtres permettaient de composer une question élaborée.

Les données formaient un arbre. Les dictionnaires regroupaient les objets ; le chemin depuis une racine constituait le nom ; les feuilles portaient les valeurs. En parcourant une branche, le processeur recopiait la structure qualifiée dans sa réponse. Le résultat indiquait donc non seulement une valeur, mais le contexte dans lequel elle avait été trouvée.

Cette qualification évitait qu’un petit numéro de balise signifiant « nom » dans un dictionnaire soit confondu avec un numéro identique signifiant « adresse » ailleurs. L’économie de l’encodage dépendait d’une sémantique locale explicite. Une petite balise n’avait de sens qu’avec tout son chemin.

Filtrer une table sans confondre place et identité

Une table d’interfaces ou de routes change. Son troisième élément aujourd’hui peut devenir le quatrième après un redémarrage. RFC 1076 renonça donc à un index positionnel général et proposa des filtres sur les valeurs : présence, égalité, bornes supérieures ou inférieures, combinaisons AND, OR et NOT.

Une application pouvait chercher l’interface qui portait une adresse précise, puis demander ses compteurs. Elle pouvait descendre dans la table ARP de cette interface, ou appliquer SET à plusieurs entrées correspondantes. Le choix était associatif : l’objet se reconnaissait par une propriété représentée, non par sa chaise momentanée dans la table.

Le mécanisme gardait une limite honnête. Si plusieurs dictionnaires satisfaisaient un BEGIN filtré, n’importe lequel pouvait être choisi. La spécification disait que l’expérience devait montrer s’il fallait traiter cette multiplicité comme une erreur. La syntaxe du filtre ne prouvait donc pas l’unicité de sa cible.

GET-RANGE pouvait aussi lire une tranche d’OctetString, notamment une représentation dépendante de la machine de sa mémoire. Mais une demande générale du contenu d’un dictionnaire excluait automatiquement la mémoire. L’arbre n’était pas une licence de tout extraire : même la forme de la découverte incorporait une limite.

La valeur renvoyée et l’effet physique

Pour SET et CREATE, la réponse contenait la partie de l’arbre après l’opération. DELETE ne renvoyait normalement rien ; les éléments qui n’avaient pas pu être supprimés pouvaient réapparaître. Une tentative d’écrire un champ non modifiable ne déclenchait pas nécessairement une erreur : l’agent renvoyait sa valeur actuelle, à comparer avec la valeur demandée.

RFC 1076 étendit ce modèle aux contrôles par un « registre virtuel de commande et d’état ». Écrire un code dans un objet pouvait provoquer un effet défini par l’implémentation, par exemple abaisser une interface. Lire cet objet pouvait indiquer un état courant.

Une réponse portant la valeur demandée prouvait ce que l’interface de gestion représentait après le traitement. Elle ne prouvait pas à elle seule que la porteuse avait disparu, que les routes avaient convergé, que les voisins avaient réagi, que la configuration survivrait à un redémarrage ou que les paquets avaient pris le chemin attendu. Le plan de commande et le résultat opérationnel exigeaient des observations différentes.

Une absence volontairement indécidable

RFC 1022 fournissait l’enveloppe HEMP pour requêtes, réponses, événements et erreurs. Il prévoyait des sections d’authentification et de chiffrement, mais la présence d’une place dans l’enveloppe ne démontrait aucune protection concrète ; le texte de 1987 n’attribuait encore aucun type de chiffrement.

RFC 1076 ne choisissait pas un système d’autorisation. L’environnement donnait à la requête un niveau ou des capacités, puis chaque objet appliquait son propre test. La protection pouvait empêcher GET, SET, CREATE ou DELETE, mais ne devait pas masquer un dictionnaire au point de faire échouer BEGIN et d’interrompre toute la requête.

Le compromis se lisait dans le « no-value ». Un objet inconnu, non implémenté ou interdit produisait la même réponse de longueur nulle. Une requête générique pouvait ainsi traverser des appareils différents sans s’arrêter sur chaque option absente. En revanche, le centre de gestion ne pouvait pas déduire de ce silence pourquoi la valeur manquait.

Lorsqu’une véritable erreur arrêtait l’interpréteur, celui-ci indiquait code, instance, position dans les octets, opération et description. Si des objets ASN.1 imbriqués étaient déjà ouverts dans la réponse, l’erreur était recopiée à chaque niveau non terminé puis une dernière fois à la fin. Le flux déjà émis devait rester décodable ; cette clôture ne constituait pas un retour arrière des opérations antérieures.

Ce qui survécut, ce qui ne doit pas être inventé

En août 1989, RFC 1109 signalait des implémentations SNMP chez plusieurs fournisseurs et dans plusieurs réseaux. Il relevait encore des difficultés de passage à l’échelle, de configuration, d’accès utilisateur et d’authentification des commandes. Le choix avait accéléré une base commune sans achever le problème.

RFC 1155 décrivit ensuite la SMI standardisée : noms hiérarchiques OBJECT IDENTIFIER, types ASN.1 restreints et magasin virtuel d’information. RFC 1157 fixa le protocole SNMP avec un ensemble plus réduit de Get, GetNext, Set et Trap, et consigna son statut opérationnel recommandé.

La ressemblance entre arbres, noms hiérarchiques et ASN.1 n’autorise pas à dessiner une filiation pour chaque objet. La preuve institutionnelle est plus étroite : RFC 1024 fut explicitement versé au chantier MIB. Les RFC ne donnent ni table de copie champ par champ ni compatibilité de fil. Dire que HEMS devint secrètement SNMP remplacerait une décision documentée par une généalogie imaginaire.

Sources et limites

RFC 1021 définit l’expérience, RFC 1022 son enveloppe, RFC 1024 ses objets, RFC 1052 la sélection, RFC 1076 le langage, RFC 1109 le suivi opérationnel, RFC 1155 la SMI ultérieure et RFC 1157 le cadre SNMP. Aucun ne fournit un recensement de déploiement de RFC 1076, des captures de production, une cartographie complète des héritages ou la preuve d’un effet sur une machine particulière.

L’histoire vérifiable tient en trois phrases. HEMS s’est retiré de la sélection commune. Son travail d’information est resté une entrée explicite. Son langage savait renvoyer un état représenté, non abolir la nécessité d’observer le réseau.