Résumé

  • RowStatus ne présente pas six états équivalents : active, notInService et notReady décrivent ce que l'agent possède, tandis que createAndGo, createAndWait et destroy sont des actions demandées.
  • Le gestionnaire formule une intention et fournit des valeurs ; l'agent applique la définition de la MIB. Une ligne peut donc exister sans être complète, puis être complète sans être autorisée à servir.

Avant RowStatus, chaque table racontait sa propre histoire

Les premières MIB ressemblaient à des tables, mais le protocole ne leur donnait pas automatiquement la sémantique d'une base de données. RFC 1212 parle de lignes « conceptuelles » précisément parce que la relation entre colonnes relève d'une convention comprise par les applications.

Pour supprimer une ligne, une MIB pouvait prévoir une valeur entière telle que invalid. Pour en ajouter une, un gestionnaire envoyait un SetRequest vers des instances qui n'existaient pas encore ; l'agent pouvait accepter leur création ou la refuser. Des valeurs par défaut pouvaient compléter certains champs. Rien de tout cela ne répondait uniformément à la question la plus importante : à quel moment l'équipement pouvait-il utiliser la nouvelle configuration ?

L'ambiguïté devenait plus coûteuse lorsque plusieurs stations de gestion intervenaient. Réserver un indice, écrire quelques colonnes et activer une fonction n'étaient pas forcément une seule opération. Sans vocabulaire commun, une ligne partielle pouvait paraître valide à un outil et inexistante à un autre.

RMON a rendu visible la période de construction

La MIB RMON de RFC 1271 a fourni un ancêtre direct. Son EntryStatus séparait createRequest, underCreation, valid et invalid. Le premier gestionnaire qui créait avec succès une ligne à un indice donné l'obtenait ; un concurrent visant le même indice recevait une erreur. La ligne pouvait ensuite être complétée avant de devenir valide.

RMON proposait aussi une chaîne de propriétaire. Elle permettait aux outils de reconnaître l'auteur d'une ressource et de coopérer, mais le texte refusait d'y voir un contrôle d'accès. Un acteur non coopératif pouvait encore modifier ou supprimer la ligne. Le nom du propriétaire était une information de coordination, pas une frontière de sécurité.

Cette limite annonce la logique de RowStatus : donner une preuve étroite et observable sans lui attribuer une autorité qu'elle n'a pas.

Trois états observables, trois verbes d'action

RFC 1443 a introduit la convention RowStatus dans SNMPv2. RFC 2579 en porte la définition actuelle.

Lors d'une lecture, une ligne existante ne peut présenter que trois états. active(1) signifie qu'elle est disponible pour l'équipement géré. notInService(2) signifie qu'elle existe et qu'elle reste indisponible, alors que l'agent dispose d'assez d'informations pour tenter son activation. Cette valeur ne garantit ni cohérence interne, ni ressources suffisantes, ni succès futur. notReady(3) indique qu'il manque encore au moins une instance de colonne nécessaire.

Les trois autres valeurs n'apparaissent que dans les écritures. createAndGo(4) demande création et activation immédiates. createAndWait(5) demande de créer sans mettre en service. destroy(6) demande la suppression de toutes les instances de la ligne.

Un GET ne renvoie jamais ces trois verbes. De même, le gestionnaire ne peut pas écrire notReady : c'est le constat de l'agent. La même colonne transporte donc une commande dans un sens et une observation normalisée dans l'autre, sans confondre les deux.

L'activation immédiate ne laisse pas de brouillon

Pour createAndGo, le gestionnaire choisit un identifiant d'instance libre et envoie dans le même SetRequest les colonnes requises et la valeur d'action. L'agent peut fournir des valeurs par défaut pour le reste.

S'il dispose de tout ce qui est nécessaire, il crée la ligne et son état lisible devient directement active. Si une information indispensable manque, il répond inconsistentValue et ne crée pas la ligne. Un échec n'est donc pas une sauvegarde partielle. Il faut corriger la requête ou employer la création progressive lorsqu'elle est prise en charge.

Cette règle donne à l'opération unique un sens net. « Créer et mettre en service » n'est vrai que si les deux étapes aboutissent ensemble.

La création progressive assume l'inachèvement

Avec createAndWait, la réussite signifie d'abord que la ligne existe. Si elle est incomplète, sa lecture donne notReady. Après fourniture des colonnes indispensables, l'agent peut la faire passer à notInService. Elle est alors suffisamment renseignée pour une tentative d'activation, mais l'équipement ne l'utilise pas encore.

Le gestionnaire demande ensuite active. L'agent peut accepter ou répondre inconsistentValue si l'état courant, les valeurs ou les ressources ne permettent pas l'opération. Une ligne complète n'est pas une promesse d'activation.

Cette méthode négociée n'est pas universellement obligatoire. Un agent peut refuser createAndWait avec wrongValue et exiger une création complète en une seule requête. Il peut aussi refuser de retirer une ligne active du service ou de la détruire lorsqu'elle est utilisée.

Une ligne abandonnée n'est pas gratuite. RFC 2579 exige que l'agent détecte les lignes restées anormalement longtemps en notReady ou notInService et les retire. La DESCRIPTION de la MIB devrait préciser ce délai ; à défaut, le RFC suggère environ cinq minutes, temps de réflexion humain compris. Ce chiffre est une recommandation, pas une mesure de tous les produits.

La convention ne remplaçait pas la définition de la MIB

RowStatus fournit le squelette du cycle de vie, mais la MIB doit encore définir les organes. Sa DESCRIPTION doit indiquer quelles colonnes ont besoin de valeurs valides avant activation et lesquelles peuvent être modifiées quand la ligne est active.

RFC 4181 a renforcé cette discipline. Pour une table dont les lignes sont créées dynamiquement par des applications, une colonne RowStatus en read-create est normalement attendue. La persistance après redémarrage, le rôle éventuel de StorageType, les créations ou suppressions effectuées par l'agent et les restrictions de modification doivent être documentés.

Le standard ne décide donc pas de chaque politique opérationnelle. Il rend les décisions locales exprimables et contrôlables dans une grammaire commune.

« Comme simultanément » ne veut pas dire partout

Une création place souvent plusieurs colonnes et le changement de statut dans le même message. RFC 3416 décrit le SetRequest comme deux phases conceptuelles : validation de toutes les liaisons de variable, puis modification si elles sont toutes acceptées. Les affectations ont lieu comme si elles étaient simultanées par rapport aux autres affectations de cette requête.

Si la modification échoue, l'entité tente d'annuler les autres et répond commitFailed. Si l'annulation complète est impossible, elle répond undoFailed. Cette dernière possibilité fixe la frontière réelle de la promesse.

L'atomicité concerne une requête reçue par une entité SNMP. Elle ne relie pas plusieurs routeurs, ne prouve pas la persistance après redémarrage et ne démontre pas que le plan de données produit l'effet attendu. Le succès de gestion est une preuve locale ; l'effet de service doit être observé séparément.

Une existence honnête vaut mieux qu'un faux feu vert

La longévité de RowStatus vient de sa modestie. Le gestionnaire possède l'intention. La MIB définit le contrat. L'agent juge la représentation et la transition. L'équipement en fonctionnement fournit la réalité opérationnelle.

Une ligne visible peut rester incomplète. Une ligne complète peut rester hors service. Une demande d'activation peut être refusée. Même active n'affirme ni durabilité, ni sécurité, ni bon acheminement du trafic. Ces limites ne diminuent pas la valeur du statut ; elles la rendent fiable.

Sources et limites

RFC 1212 et RFC 1271 décrivent les conventions antérieures et le précédent RMON. RFC 1443 et RFC 2579 définissent le cycle de vie. RFC 3416 borne la sémantique de SetRequest, et RFC 4181 précise les devoirs des auteurs de MIB. Ces textes ne mesurent ni déploiement actuel, ni conformité des fournisseurs, ni politique de sécurité, ni effet réel sur le trafic. L'analyse en termes d'intention, de préparation et de service est une lecture du mécanisme.