Résumé

  • La RFC 1095 place CMOT et SNMP au même rang de Draft Standard et de protocole Recommended. La politique antérieure donnait à SNMP l’urgence du court terme et à CMIS/CMIP l’ambition du long terme, mais demandait des expériences sur les deux voies.
  • Un MIB Internet commun permettait de nommer les mêmes objets. Il ne produisait ni la même application ni le même dialogue : CMOT exigeait un profil précis reliant CMIS, CMIP, ACSE, ROSE, ASN.1 et une présentation légère à TCP ou UDP.
  • Le texte se limite à un domaine de gestion, laisse les applications hors norme et rend facultatifs plusieurs paramètres de contrôle d’accès. Une association acceptée est donc une compatibilité de protocole, non un mandat institutionnel ni la preuve de l’effet sur la machine.

Le mot « recommandé » n’annonçait pas encore le gagnant

La mémoire technique aime les lignes droites. SNMP apparaît comme la solution pragmatique qui s’est imposée ; CMOT, comme l’ambition ISO devenue trop lourde. Or la RFC 1095 conserve une scène plus indécise. L’Internet Activities Board y attribue exactement le même statut à deux protocoles : Draft Standard et Recommended.

Le premier est SNMP. Le second, Common Management Information Services and Protocol over TCP/IP, adapte CMIS/CMIP à l’environnement Internet. Une implémentation gérable devait en adopter au moins un. L’IAB attendait des constructeurs et des utilisateurs des comptes rendus d’expérience sur chacun.

Cette égalité administrative ne gommait pas la chronologie. Dans la RFC 1052, publiée un an plus tôt, SNMP répondait au besoin immédiat parce que son logiciel existait déjà. CMIS/CMIP devait fournir, à plus longue échéance, une architecture développée et éprouvée sur le terrain, susceptible d’alimenter les travaux internationaux.

Il s’agissait d’un portefeuille de risques. L’Internet en croissance ne pouvait attendre un système parfait ; il ne voulait pas non plus renoncer à explorer une architecture plus large. La recommandation autorisait et encourageait l’essai. Elle ne disait rien d’une égalité du parc installé.

La RFC 1109, issue d’une revue de juin 1989, rend ce décalage mesurable sans le dramatiser. Elle cite des implémentations SNMP déjà en réseau. Elle ne recense aucune implémentation CMOT publiquement disponible lors de la réunion, mais mentionne des projets et une démonstration prévue. Les prototypes CMOT montrés à Interop ’88, invoqués par la RFC 1095, prouvaient une faisabilité ; ils ne constituaient pas un marché.

Le même dictionnaire n’écrit pas la même application

Le compromis le plus fin concernait les données. La RFC 1052 avait demandé à un groupe distinct de définir un MIB commun, utilisable par le groupe SNMP comme par le groupe Netman. Quinze mois plus tard, la RFC 1109 parlait d’environ cent variables obligatoires acceptées par les deux.

Un compteur IP ou une entrée de routage pouvait ainsi conserver son identité lorsque le mécanisme de requête changeait. Le MIB offrait une continuité sémantique et devait, dans la projection de l’époque, faciliter un passage de SNMP vers CMIP.

Mais un dictionnaire partagé ne fournit ni grammaire conversationnelle ni outil d’exploitation. Il ne décide pas comment sélectionner une instance, limiter la portée d’une opération, filtrer une réponse, annoncer un événement, négocier une session ou présenter une erreur. Deux logiciels peuvent demander le même objet par des services profondément différents.

La RFC 1109 le reconnaît en plaçant l’efficacité du système dans les outils accessibles aux opérateurs. Les interfaces de service des deux familles ne savaient pas formuler une requête historique ni programmer une action future. Le MIB disait ce qui pouvait être nommé, pas ce qu’un poste de contrôle savait en faire.

La longueur de la RFC 1095 vient de cette lacune productive. Puisque les objets étaient communs, il fallait définir comment un ensemble particulier d’options CMIS/CMIP transporterait leur sens sans ambiguïté entre fabricants.

Le profil transformait une famille de normes en rendez-vous

CMOT ne se résumait pas à CMIP posé sur un socket. ASN.1 décrivait les données ; ACSE organisait l’association applicative ; ROSE portait les opérations ; CMIS et CMIP donnaient services et messages ; le SMI et le MIB Internet fournissaient les objets ; la RFC 1085 assurait la présentation légère.

La deuxième moitié de la RFC 1095 est donc un relevé de décisions. Quels groupes fonctionnels négocier ? Comment identifier classe et instance ? Que signifient portée, filtre et synchronisation ? Quels PDU et quelles options un pair doit-il comprendre ? Comment sérialiser ACSE, ROSE et CMIP sur le service de présentation retenu ?

La présentation légère évitait d’installer toutes les couches OSI de présentation, de session et de transport dans une machine Internet. Elle préservait les services attendus par les éléments applicatifs, puis les raccordait directement aux transports TCP/IP.

Le mot « léger » n’abolissait toutefois pas les choix. Dire qu’un produit prend en charge CMIP ne révèle ni le contexte d’application, ni les unités fonctionnelles, ni la version du MIB, ni le codage, ni le transport. L’interopérabilité naît de l’intersection de ces paramètres, pas du nom imprimé sur la boîte.

Un profil est donc autant une réduction qu’une frontière. Il élimine des variantes afin que deux réalisations indépendantes puissent tenter un dialogue. Il ne garantit ni la qualité de l’application, ni la conformité du matériel, ni la légitimité de l’organisation qui envoie la commande.

TCP et UDP gardaient leurs promesses propres

La RFC 1085 proposait un service fondé sur TCP, qualifié de haute qualité, et un service fondé sur UDP, qualifié de basse qualité. Elle insistait : basse qualité signifie réellement basse qualité. L’abstraction de présentation ne devait pas faire croire qu’UDP avait acquis connexion, ordre et reprise.

CMOT pouvait emprunter les deux. La RFC 1095 attribuait les ports 163 aux gestionnaires et 164 aux agents, pour TCP comme pour UDP. Sur UDP, la taille maximale de 484 octets devait éviter la fragmentation IP dans le cadre retenu. Quant à la découverte, elle pouvait dépendre d’un annuaire, d’une table locale ou d’une tentative d’association.

L’adresse d’un agent ne suffisait donc pas à décrire son accès. Il fallait connaître le transport, le rôle, le profil et l’origine de la correspondance. Une connexion TCP ouverte et un datagramme UDP reçu sont des observations de nature différente. Aucune ne confirme l’autorité humaine située derrière le gestionnaire.

Cette décomposition améliore aussi le diagnostic. Un silence peut provenir du réseau, de la présentation, du contexte d’association, d’une fonction CMIS absente, d’un refus d’accès ou de l’objet géré. L’étiquette générale « CMOT en panne » détruit la chaîne causale.

Le domaine de gestion n’était pas une route

La RFC 1095 décrit managers, agents, objets et cinq domaines fonctionnels de la gestion OSI. Elle refuse en revanche de standardiser les applications concrètes chargées de les exploiter. Le but est une architecture minimale d’interopérabilité multiconstructeur ; l’interface de l’opérateur reste concurrentielle.

Le texte écarte également les relations entre domaines de gestion. Un seul domaine entre dans son architecture. Cette limite est administrative avant d’être topologique.

Un domaine désigne les systèmes qui peuvent commander, les équipements qui répondent, les politiques applicables et la responsabilité de leurs effets. Un paquet IP franchit une frontière si le routage le permet. Le pouvoir d’une administration sur les équipements d’une autre ne se transmet pas par cette route.

CMOT pouvait décrire la forme d’une requête entre manager et agent. Il ne créait pas le mandat permettant à une organisation de modifier le réseau voisin. La fédération exigeait des accords, des identités et des responsabilités au-dessus du profil.

La symétrie technique doit donc rester à sa place. Deux machines peuvent disposer de rôles compatibles et d’un format commun. Les pouvoirs institutionnels restent orientés, bornés et révocables.

L’association ouvrait le protocole, pas le domaine

ACSE établissait une association avant l’échange d’opérations de gestion. Les pairs négociaient contexte d’application et unités fonctionnelles. Une acceptation prouvait qu’ils avaient trouvé un langage compatible.

Elle ne prouvait ni l’identité civile de l’opérateur ni sa délégation. Les paramètres de contrôle d’accès au niveau de l’association et de la requête étaient facultatifs. La RFC 1095 recommandait le traitement au moment de l’association et attendait de futurs mécanismes d’authentification Internet ; elle permettait aussi au récepteur d’ignorer le champ par requête. Une méthode temporaire simple pouvait n’être qu’un mot de passe non chiffré.

Ces phrases témoignent d’une conscience du problème, non de sa résolution. Quelques mois plus tard, la RFC 1109 range encore le contrôle de l’utilisateur et l’authentification des commandes et réponses parmi les lacunes des deux protocoles.

Il faut donc conserver l’ordre des verdicts. La portée réseau autorise une tentative. Le profil et l’association autorisent un dialogue. L’authentification attribue un message à un principal selon une méthode. La politique autorise une opération. Chaque étage a besoin de sa propre preuve.

La réponse ne mesurait pas encore l’effet

CMIS offrait des opérations structurées de lecture, de modification et de notification. La RFC 1095 exigeait une synchronisation au mieux, mais rendait la synchronisation atomique facultative. Elle ne transformait pas toute opération en transaction sur le monde physique.

Une réponse positive montre que la pile profilée a reçu et traité une demande et que l’agent a formulé le résultat prévu. Elle ne montre pas, à elle seule, qu’une carte a changé de mode, qu’un trafic a basculé, que la configuration survivra au redémarrage ou que l’utilisateur final verra un bénéfice.

Ces affirmations demandent une relecture, un événement, un compteur indépendant, un contrôle de persistance ou une observation extérieure. Lorsque commande et confirmation proviennent du même agent, leur origine commune doit rester visible.

La séparation ne rabaisse pas le protocole. Elle précise son mérite. CMOT fixe messages et sémantique ; l’instrumentation traduit cette sémantique en action ; la machine et le réseau produisent l’effet. La réussite de l’un n’absorbe pas le verdict du suivant.

La révision de 1990 confirme le rôle du profil

La RFC 1189 remplaça la RFC 1095 après le passage de CMIS/CMIP aux normes ISO définitives. Elle supprima le tutoriel, déplaça la sémantique du MIB vers un autre document, reprit des accords d’implémentation actualisés et modifia la négociation d’association tout en reconnaissant l’ancien nom de contexte.

Cette évolution montre qu’un nom de protocole ne contient pas sa version opérationnelle. Quand la norme de base bouge, le profil doit dire quelles options et quels contextes peuvent encore se rencontrer.

Elle laisse intacte la leçon de 1989. Deux protocoles pouvaient être recommandés et partager les mêmes objets sans devenir le même système. Le profil approchait syntaxe et transport jusqu’au point d’interopérabilité. L’autorité du domaine, l’application et la preuve de l’effet restaient des décisions distinctes.

Sources