Résumé

  • Dans RFC 5190, l’absence de réponse à un SET laisse deux scénarios : la requête a été perdue, ou elle a été exécutée et seule la réponse a disparu. Relancer sans lire l’état peut répéter une modification déjà effective.
  • La transaction logique MIDCOM ne tient pas dans un seul message SNMP : la fin du dernier SET peut seulement déclencher le traitement, une notification annonce ensuite un état et des GET récupèrent le reste de la réponse.

Le défaut n’était pas dans le calcul de la durée. Il était dans le récit de l’automate. « Timeout » avait été traduit par « aucune écriture ». Une deuxième demande de réduction fut donc envoyée alors que la première valeur avait déjà commencé à décroître.

RFC 5190 refuse cette équivalence. Une transaction SET comprend une requête et une réponse, généralement transportées en UDP. L’une comme l’autre peut être perdue. Du point de vue du gestionnaire, le même silence peut désigner zéro changement ou un changement réel sans accusé reçu.

La conduite prudente consiste à relire avant de décider. Le document propose de vérifier le succès de la première écriture par GET puis de ne répéter le SET que si nécessaire. Il cite aussi snmpSetSerialNo, un délai de retransmission inférieur à la plus petite durée demandée et la possibilité de désactiver toute retransmission.

Ces moyens ne promettent pas une exécution universellement « exactement une fois ». Ils donnent des éléments pour distinguer des tentatives dans la portée du protocole. Le journal doit encore conserver la requête, le silence, la lecture de récupération et la décision de relance.

Le dernier SET ouvre le travail, il ne le clôt pas

Une requête MIDCOM peut être trop grande pour un seul message SNMP. Le client crée une ligne, renseigne les paramètres au moyen de plusieurs SET, puis écrit l’état administratif qui déclenche le traitement.

La réussite du dernier SET signifie que les paramètres requis sont en place et que le middlebox peut commencer. Entre cette étape et le résultat se trouvent les états checkingRequest et processingRequest. Les confondre avec reserved, enabled ou un état d’erreur donne au reçu d’écriture l’autorité d’un résultat qu’il n’a pas observé.

Une preuve exploitable conserve donc deux frontières : l’atomicité du SET SNMP et la progression de la transaction logique. Elle nomme chaque ensemble de varbinds, l’identité authentifiée, la ligne visée, l’heure et la réponse. Elle n’efface pas les états transitoires.

Ce point distingue RFC 5190 d’un simple guide RowStatus. L’enjeu n’est pas seulement de savoir si une ligne existe ou peut servir. Il est de reconstruire une opération plus large dont la signification a été répartie sur plusieurs messages.

La notification est un rendez-vous de lecture

Lorsque le traitement atteint un résultat, le middlebox peut émettre midcomSolicitedRuleEvent. Cette notification contient l’état opérationnel et la durée de vie. Elle n’emporte pas nécessairement les adresses, ports et détails d’erreur qui constituent la réponse utile.

Pour une durée positive, le client lit les paramètres positifs dans la table. Pour une durée nulle, il lit l’état et midcomRuleError. La notification indique donc où et quand poursuivre ; elle n’est pas toujours la réponse complète.

Une plate-forme qui stocke uniquement le trap fabrique une archive amputée. Elle sait qu’un état terminal a été signalé, mais pas nécessairement ce qui a été accordé, refusé ou renvoyé. À l’inverse, enrichir rétroactivement le trap avec des champs lus plus tard sans conserver leurs temps d’observation cache le décalage entre les sources.

Le bon objet d’évidence distingue les varbinds réellement reçus dans l’événement et les valeurs récupérées par GET. Il conserve aussi la clé de corrélation : propriétaire, groupe, indice de règle et transaction.

Le silence d’un trap n’est pas l’échec

Les notifications SNMP sont elles aussi susceptibles d’être perdues. RFC 5190 demande au client qui attend un événement de surveiller périodiquement la transaction. Après un délai choisi, il peut lire l’état de la ligne et découvrir que le traitement s’est terminé sans que le trap ait été reçu.

Le document présente le polling comme plus coûteux mais plus fiable. Cette fiabilité est relative : la lecture peut être répétée, alors qu’un datagramme de notification perdu ne revient pas. Elle ne transforme pas plusieurs GET en instantané atomique.

Pendant une lecture longue, des règles peuvent apparaître, changer ou disparaître. Le client doit intégrer les notifications reçues pendant la séquence ou recommencer la transaction de surveillance. Le résultat est une reconstruction versionnée, pas une photographie parfaite.

Un indicateur « trap manquant » doit donc ouvrir une enquête de statut, non conclure à l’échec. Il faut séparer absence d’événement, absence de ligne, état transitoire, état terminal et absence de résultat complet.

La ligne de résultat a une date de péremption incertaine

La table MIDCOM contient des règles en construction, rejetées, actives et terminées. Après une erreur ou une terminaison, midcomRuleStorageTime indique un temps restant avant disparition.

Mais le texte précise que cette conservation n’est pas garantie jusqu’au dernier tick. L’implémentation peut supprimer plus tôt une ligne terminée. À cet instant, les informations qu’elle portait ne sont plus disponibles.

Le collecteur court donc contre deux délais : celui de la notification attendue et celui de la conservation locale. Une récupération tardive peut voir le trap sans la ligne, ou ne voir ni l’un ni l’autre après une opération pourtant réelle.

L’absence finale ne prouve pas l’absence initiale. Pour préserver l’historique, l’opérateur doit copier l’état, l’erreur, les valeurs accordées, les horodatages et la politique de conservation tant que la ligne existe encore.

Plusieurs auteurs peuvent produire une seule ligne incohérente

Si les paramètres nécessitent plusieurs SET, une seconde application possédant les mêmes droits peut modifier la ligne avant le déclenchement final. Chaque message peut être authentifié et autorisé séparément ; l’ensemble peut pourtant ne correspondre à l’intention complète d’aucun client.

RFC 5190 recommande d’éviter ces accès concurrents : horaires séparés, indices de groupe différents ou plages d’indices de règles non chevauchantes. Ce sont des disciplines d’exploitation, pas un verrou implicite.

Le journal doit conserver l’auteur de chaque mutation, la version de ligne et le plan de paramètres attendu. Une identité commune dans l’index ne suffit pas à attribuer la composition finale. Le principe vaut surtout lors d’un basculement, lorsque deux contrôleurs croient légitimement reprendre la main.

Une chaîne de preuve, pas un voyant

Commencer par une identité immuable de l’opération logique : intention, middlebox, règle, groupe, interface, paramètres et propriétaire responsable. Ajouter ensuite chaque SET avec principal, droits VACM, varbinds, numéro de série, réponse ou timeout.

Enregistrer le SET déclencheur sans le nommer « terminé ». Suivre les transitions opérationnelles. Noter si la fin a été connue par notification ou polling. Stocker exactement le contenu de l’événement, puis les GET qui complètent les paramètres positifs ou la cause d’échec.

Conserver le temps de stockage annoncé, l’instant de copie et la disparition éventuelle de la ligne. Enfin, relier cette preuve de contrôle aux ressources NAT ou pare-feu, aux captures de paquets, au reçu distant et au résultat applicatif.

Une réponse SET perdue peut rester ambiguë. L’objectif n’est pas de masquer cette incertitude, mais d’empêcher qu’une répétition automatique ne la transforme en seconde action invisible.

Sources

  1. RFC 5190 HTML
  2. RFC 5190 texte
  3. Notice RFC 5190
  4. Datatracker RFC 5190
  5. Historique RFC 5190
  6. Références RFC 5190
  7. Errata RFC 5190
  8. RFC 5189
  9. Notice RFC 5189
  10. RFC 3416
  11. RFC 3418
  12. RFC 3414
  13. RFC 3415
  14. RFC 2578
  15. RFC 2579
  16. RFC 2580
  17. RFC 3304
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy