Résumé

  • RowStatus sépare trois actions uniquement inscriptibles — createAndGo, createAndWait, destroy — de trois états lisibles — active, notInService, notReady. Une demande n’est donc pas présentée comme le fait qu’elle cherche à produire.
  • createAndWait rend une ligne incomplète visible et récupérable, sans réserver exclusivement son index ni garantir son activation. Le retour arrière d’un seul SetRequest ne transforme pas les échanges ultérieurs, encore moins plusieurs équipements, en transaction atomique.

Commencer par ce qui manque

Le chemin createAndWait permet à un gestionnaire de commencer sans connaître chaque valeur obligatoire. Après avoir lu notReady, il inspecte les colonnes. Les instances requises mais encore absentes produisent noSuchInstance. Il peut alors les initialiser ; lorsque les éléments nécessaires sont réunis, la ligne passe à notInService.

Cette visibilité donne de la continuité au-delà d’une session cliente. Si le processus tombe, un opérateur ou un autre gestionnaire peut relire la ligne et distinguer un objet absent d’un objet créé mais inachevé. L’état intermédiaire devient une preuve partageable au lieu de rester une variable privée dans l’outil qui a lancé la tâche.

Il ne faut pas transformer ce bénéfice en garantie excessive. Quand le gestionnaire demande ensuite active, l’agent peut encore répondre inconsistentValue. Des colonnes toutes présentes peuvent former un ensemble invalide. Une ressource peut manquer. L’état du dispositif peut avoir changé depuis la création.

Les définitions propres à chaque table conservent aussi un rôle. Leur DESCRIPTION indique quelles colonnes peuvent changer pendant que la ligne est active ou hors service. Une table autorisant une modification après passage à notInService n’établit pas une règle universelle pour toutes les utilisations de RowStatus.

Le seuil appartient encore à l’agent

Un logiciel de gestion sait peut-être quel index il veut créer. Il peut même posséder plusieurs valeurs de colonne. Cela ne lui donne pas encore la réponse aux questions que l’agent doit trancher : toutes les informations obligatoires sont-elles présentes, les valeurs sont-elles compatibles, les ressources sont-elles disponibles et la ligne peut-elle effectivement servir à l’équipement ?

RFC 2579 encode cette différence dans la convention textuelle RowStatus. active et notInService sont des états qui peuvent être lus ou écrits. notReady peut être lu mais pas écrit. createAndGo, createAndWait et destroy sont des actions inscriptibles, mais ne sont jamais renvoyées par une lecture.

Écrire createAndWait ne colle donc pas cette étiquette sur la ligne. Si la création réussit, l’agent répond par un état qui décrit ce qu’il sait désormais. La ligne devient notReady quand les informations ne suffisent pas ; elle devient notInService quand il y en a assez pour tenter une mise en service.

Cette nuance protège deux vérités. Une ligne notReady peut déjà exister et consommer des ressources : l’opération n’a pas simplement échoué. Une ligne notInService n’est pas certifiée correcte : elle a seulement franchi le seuil nécessaire pour soumettre l’activation à une décision supplémentaire.

Une ressource oblige à prévoir la fin de l’attente

La création par étapes ouvre une fenêtre de reprise, mais elle permet aussi l’abandon. Une panne du gestionnaire, une coupure réseau ou une procédure oubliée peut laisser une ligne non utilisée qui continue à consommer de la mémoire, une entrée de table ou une ressource de mesure.

RFC 2579 confie alors une obligation à l’agent : détecter les lignes restées anormalement longtemps dans notReady ou notInService et les retirer. La durée doit être précisée par la DESCRIPTION de la colonne d’état. Ce n’est qu’en l’absence d’une telle précision que le RFC suggère environ cinq minutes.

Faire de cinq minutes un délai universel effacerait une décision appartenant à la table. Certaines ressources peuvent être rares et exiger une récupération rapide ; d’autres processus légitimes peuvent dépendre d’une approbation plus lente. Le nettoyage concerne aussi une ancienne ligne active laissée trop longtemps hors service, pas uniquement une création nouvelle.

L’agent détient la ressource ; il porte donc le mécanisme de dernier recours lorsque le client ne tient plus sa part du dialogue. La récupérabilité d’un état intermédiaire et sa durée de vie ne sont pas deux sujets séparés.

RMON a donné une durée à la création

Le SNMP décrit par RFC 1157 en mai 1990 cherchait délibérément la simplicité. Les fonctions de gestion étaient représentées comme la lecture et la modification de variables nommées, plutôt que comme un vaste répertoire de commandes propres à chaque appareil.

Une ligne conceptuelle complique ce modèle sans l’invalider. Sa création peut exiger plusieurs instances de colonne, un index non conflictuel, des valeurs sans défaut et une allocation de ressources. Plusieurs gestionnaires peuvent intervenir sur la même table. L’appareil lui-même peut également créer une instance. Une écriture distante ne suffit pas à dire comment exposer le travail incomplet, ni qui doit le supprimer si son auteur disparaît.

Le problème prit une forme opérationnelle dans la surveillance à distance. RFC 1271, publié en novembre 1991 pour RMON, étudiait des tables de contrôle où plusieurs gestionnaires partageaient des ressources de mesure limitées. Son EntryStatus comprenait createRequest, underCreation, valid et invalid. Le texte traitait des collisions, des entrées abandonnées et d’une chaîne de propriétaire destinée à rendre l’auteur d’une configuration intelligible aux autres gestionnaires.

Cette chaîne n’authentifiait personne et n’accordait aucun droit. Son intérêt historique est ailleurs : la création était reconnue comme une période visible, avec des ressources et une possibilité d’abandon, pas seulement comme le passage instantané de l’absence à la validité.

En avril 1993, RFC 1443 transforma cette pratique en convention RowStatus réutilisable et cita explicitement EntryStatus comme origine. RFC 1903 révisa le texte en 1996. La version de 1999 dans RFC 2579 fixa la sémantique détaillée utilisée ici. Le mécanisme général provient donc d’un apprentissage progressif au contact des tables de contrôle.

La garantie forte tient dans un seul message

SNMP ne laisse pas pour autant chaque colonne se modifier au hasard. Dans RFC 3416, le traitement d’un SetRequest commence par la validation des liaisons de variables. Les affectations de la même requête ont lieu comme si elles étaient simultanées entre elles. Si une affectation échoue ensuite, les autres sont annulées et l’agent renvoie commitFailed. S’il ne peut pas tout annuler, il renvoie undoFailed.

Cette règle donne une limite utile. Un gestionnaire peut inclure plusieurs colonnes et une action de création dans le même PDU, et bénéficier du traitement commun à cette requête. Mais une séquence comprenant createAndWait, une lecture, plusieurs compléments et une activation ultérieure comporte plusieurs requêtes déjà séparées dans le temps.

Une réponse antérieure ne reste pas en suspens jusqu’à la fin du parcours. Une déconnexion, un concurrent ou l’appareil peut intervenir entre les étapes. Le retour arrière du dernier SetRequest ne remonte pas dans le temps pour annuler les précédents.

La même prudence vaut à l’échelle du réseau. Les affectations « comme si elles étaient simultanées » concernent un seul PDU traité par une entité. Elles ne coordonnent pas plusieurs routeurs et ne créent pas un commit distribué. Les erreurs commitFailed et undoFailed décrivent justement les limites d’un mécanisme local, pas une autorité transactionnelle globale.

Une ligne visible ne devient pas une réservation

Une ligne hors service peut donner l’impression d’une place réservée. RFC 2579 enlève précisément cette assurance. Entre l’écriture de createAndWait et la demande ultérieure d’active, le dispositif géré peut créer sa propre instance. Les valeurs détenues par l’agent peuvent alors remplacer celles que le gestionnaire avait fournies.

Il s’agit d’une limite de la séquence, pas d’une anecdote de mise en œuvre. La ligne est observable pendant l’attente, mais le gestionnaire ne possède pas un verrou exclusif. Relire les colonnes importantes avant activation devient donc une vérification de concurrence, et non un confort facultatif.

La suppression suit la même séparation entre action et état. destroy peut être demandé qu’une ligne soit active, notInService ou notReady. En cas de réussite, toutes ses instances disparaissent. Il n’existe pas ensuite d’état durable destroy à relire : l’effet de l’action est l’absence de la ligne.

Des preuves plus petites qu’un succès général

RowStatus ne promet pas qu’une configuration complexe réussira. Il répartit des décisions vérifiables. Le gestionnaire demande une création, fournit les valeurs et choisit le moment où il sollicitera l’activation. L’agent détermine si l’instance peut être créée, si les informations suffisent, si l’ensemble est cohérent, si les ressources existent, et il nettoie les travaux abandonnés. La définition de la table précise les politiques de modification et de délai.

Une interface plus pauvre pourrait réduire tout cela à « succès » ou « échec ». Elle cacherait alors le lieu exact de l’arrêt et la personne qui doit agir. RowStatus a conservé le petit modèle de variables de SNMP tout en reconnaissant qu’une ligne a une histoire.

La ligne qui existe avant d’être prête n’est pas une contradiction. Elle permet de dire séparément : la demande de création a été acceptée ; certaines informations manquent encore ; l’équipement n’utilise pas la ligne ; personne ne peut encore prétendre que l’effet recherché est obtenu.

Sources