Résumé

  • Une conversion conforme à RFC 6643 rend les objets SMIv2 accessibles en lecture par NETCONF ; elle ne transporte pas automatiquement leur capacité d’écriture vers YANG.
  • La persistance d’une ligne SNMP et celle d’une configuration NETCONF ne reposent pas sur le même contrat. Le maintien des noms et des types ne résout pas cette différence.
  • Des écarts documentés peuvent rendre certains nœuds configurables lorsque leurs sémantiques restent compatibles. Une telle extension locale ne vaut pas autorisation de retirer tout l’ancien dispositif d’administration.

« Permanent » ne veut pas dire « immuable »

Une ligne déclarée permanente peut encore être modifiée. Dans le vocabulaire de StorageType, défini par RFC 2579, ce qui lui est interdit est la suppression. Une ligne de type readOnly, en revanche, ne peut être ni modifiée ni supprimée. Toutes deux disposent d’un stockage stable ; elles ne donnent pourtant pas le même sens à une demande de changement.

Cette petite distinction suffit à compliquer une grande promesse : convertir un ancien modèle de gestion sans changer ce qu’il permet de faire. Un outil peut recopier un type, reconnaître un nom et afficher une valeur. Il ne peut déduire de ces seuls éléments les obligations attachées à la modification de cette valeur.

La difficulté apparaît aussi dans l’autre sens. Une ligne volatile disparaît au redémarrage. La rendre durable dans un nouveau système n’est pas nécessairement préserver son comportement ; ce peut être le modifier. Une amélioration apparente de la conservation peut donc constituer une décision fonctionnelle qui n’appartient pas au convertisseur.

Ce n’est pas ici le constat d’un incident. C’est une conséquence de définitions publiques. Elle oblige à poser une question moins commode que celle du nombre d’objets migrés : qui a décidé de ce que chaque écriture doit laisser derrière elle, et où cette décision est-elle conservée ?

La passerelle a un périmètre volontairement limité

RFC 6643, publié en juillet 2012, définit la conversion des modules MIB SMIv2 en modules YANG pour un accès en lecture seule par NETCONF. Le choix n’est pas implicite. Le conteneur supérieur généré pour les objets est config false, y compris lorsque certaines définitions sources indiquent des objets modifiables ou créables.

Le modèle conserve néanmoins de nombreuses informations. Les descriptions, références, types et identifiants d’objets suivent des règles de correspondance. La déclaration MAX-ACCESS est notamment portée par une extension smiv2:max-access. On peut ainsi retrouver dans le résultat l’indication qu’un objet était modifiable dans le modèle de départ.

Retrouver cette indication ne crée pas une opération de configuration. L’extension décrit une propriété de la définition source ; elle ne neutralise pas la classification du modèle cible. Un lecteur qui voit un ancien libellé d’accès doit encore examiner ce que le nouveau serveur expose réellement.

La conversion ne perd donc pas toute la sémantique, pas plus qu’elle ne la transforme entièrement en comportement exécutable. Une partie de la connaissance reste descriptive. Cette nuance est essentielle pour juger le produit livré : une passerelle d’observation peut être complète alors même qu’elle n’a jamais eu pour objet de remplacer le chemin d’écriture.

Deux endroits où ranger la persistance

La section 11 de RFC 6643 explique pourquoi une promotion automatique vers des nœuds de configuration ne serait pas fondée. En SNMP, les propriétés de persistance peuvent figurer dans la description de l’objet, appartenir à sa ligne conceptuelle ou être déterminées par une colonne utilisant StorageType. En NETCONF, les données de configuration relèvent des propriétés du magasin de données qui les contient.

La différence porte sur l’endroit où réside la promesse. Un programme de conversion sait transformer une déclaration. Il ne sait pas, par la seule grammaire, choisir à quel contrat de conservation cette déclaration doit désormais appartenir. Cela exige une analyse de l’objet et de sa destination.

Le modèle NETCONF de RFC 6241 ne permet pas davantage de tout résumer par « la configuration est sauvegardée ». Le modèle de base comprend la configuration courante, appelée running. Les magasins supplémentaires sont liés aux capacités annoncées par l’équipement. La possibilité d’écrire directement dans running correspond elle-même à une capacité.

Lorsqu’un équipement possède une configuration de démarrage distincte, une modification de la configuration courante ne s’y propage pas automatiquement. Une copie explicite vers startup met à jour ce qui sera chargé au démarrage. Il faut donc connaître le magasin visé et la capacité concernée avant d’affirmer ce qui survivra.

Ce point ne commande aucune intervention sur un équipement. Il décrit les informations qu’un dossier de migration devrait apporter. Deux valeurs identiques après une lecture immédiate peuvent dépendre de contrats de conservation différents. Le test visuel qui constate leur égalité ne suffit pas à démontrer leur équivalence fonctionnelle.

Un autre écart reste présent : les opérations de modification de configuration de RFC 6241 ne constituent pas un moyen générique de réécrire l’état opérationnel. Tout ce qui se lit n’est pas un réglage à rejouer. La sélection des futures écritures doit commencer par cette classification, avant même de discuter de leur durabilité.

Un écart déclaré peut être un bon résultat

Il existe une voie pour les objets dont les sémantiques de persistance sont cohérentes entre les deux systèmes. RFC 6643 permet à une implémentation d’en rendre certains configurables et demande de documenter ce choix dans un module YANG de déviations séparé. Sa règle de conformité admet le passage de config false à true lorsque celui-ci ne change pas les autres sémantiques du nœud.

Le mot certains importe davantage que le changement du booléen. La règle ne démontre aucune équivalence pour les autres objets. Elle permet de prendre une décision locale et explicable au lieu de transformer l’ensemble du modèle au nom d’une migration uniforme.

L’exemple de la table de contrôle RMON2 détaille plusieurs nœuds et montre comment annoncer modules, révisions et déviations. Il rappelle qu’une déviation agit sur son nœud cible, sans constituer une modification indistincte de toute la descendance. Le détail de la hiérarchie fait donc partie de ce qui doit être examiné.

Il faut garder cette remarque distincte de l’héritage ordinaire de la propriété config. RFC 7950, qui définit YANG 1.1, décrit la valeur héritée lorsqu’une déclaration est absente, interdit les nœuds de configuration sous un nœud d’état et exige que le modèle résultant demeure valide après application des déviations annoncées. Un extrait isolé n’est pas le schéma effectif.

La déviation n’est ni une attestation d’essai ni une permission accordée à un utilisateur. Elle fournit une description de l’implémentation attendue. L’intérêt est de rendre l’exception inspectable : elle peut être reliée à une version, discutée et conservée sans réécrire silencieusement la base commune.

Le modèle généré ne devrait pas devenir une mémoire privée

RFC 6643 conseille de modifier d’abord le SMIv2 d’origine, avec ses informations de mise à jour et de révision, puis de refaire la conversion. Il déconseille la modification directe du YANG généré, tout en laissant place aux augmentations et déviations séparées.

La discipline peut paraître administrative tant que l’équipe initiale est présente. Elle devient opérationnelle lors du premier changement de fournisseur, du départ d’un ingénieur ou d’une nouvelle génération du modèle. Sans filiation claire, personne ne sait plus si la particularité d’un équipement vient du document d’origine, du convertisseur ou d’une correction locale.

Il est alors possible de posséder tous les fichiers et d’avoir perdu l’explication. Un fichier généré à la main peut fonctionner aujourd’hui ; il ne dit pas quelles modifications une prochaine génération doit conserver. Un module source intact peut sembler rassurant ; il ne décrit pas nécessairement les déviations réellement livrées.

L’erratum technique 4786, vérifié en août 2016, illustre une correction beaucoup plus étroite. Il évite de générer deux fois un même nœud feuille dans certaines traductions de notifications, lorsque l’objet courant appartient déjà à l’index. La correction concerne la structure produite. Elle n’ajoute ni écriture ni garantie de persistance.

Le suivi d’une telle correction doit donc conserver son périmètre. Vérifier le cas de génération concerné est pertinent ; prétendre qu’un nouveau correctif valide toute la migration ne l’est pas. La fiche du RFC permet de situer le document et son historique public, pas de certifier ce qui tourne chez un opérateur.

Le coût qui reste après la démonstration

Une plateforme d’observation unifiée peut rendre un service réel : moins de formats à présenter aux applications et une voie commune pour consulter des informations existantes. Il n’est pas nécessaire de lui attribuer des écritures qu’elle n’effectue pas pour justifier son intérêt.

Le risque économique vient plutôt d’un changement de catégorie dans la réception du projet. Si la démonstration porte sur la lecture mais que la décision de clôture supprime le budget de l’ancien outil de contrôle, une responsabilité demeure sans financement explicite. Les actions rares, les accès exceptionnels et les connaissances nécessaires à l’ancien chemin ne disparaissent pas avec la présentation commerciale.

Une organisation peut choisir de garder deux chemins. Ce n’est pas en soi un défaut de conception. Mais elle doit savoir lequel effectue les changements, lequel constate les valeurs et qui maintient chacun. L’économie annoncée ne devrait pas inclure la disparition d’une fonction encore utilisée.

Il faut également éviter de confondre lecture seule et absence de sensibilité. RFC 6643 renvoie aux considérations de sécurité des MIB d’origine et aux contrôles d’accès NETCONF. Un objet impossible à modifier par cette passerelle peut tout de même révéler une information qui doit rester protégée.

Ce que les textes permettent de conclure

La lecture proposée ici reprend la distinction de Lu Heng entre représentation et pouvoir exécutable ainsi que son analyse du décalage entre contrôle et conséquences. Leur application à ce mécanisme est une analyse de Daniel Kade, non une prise de position de Lu Heng sur SNMP ou YANG.

Les sources décrivent une conversion, des conventions de stockage, des règles de configuration et une correction vérifiée. Elles ne fournissent ni taux d’adoption, ni économie mesurée, ni incident, ni preuve de conformité d’un fournisseur. Aucun équipement n’a été modifié ou soumis à un essai pour cet article. Les scénarios d’acceptation sont hypothétiques et doivent être confrontés aux obligations propres à chaque exploitation.