Résumé

  • RFC 3434 représentait une grandeur de grande capacité par un module absolu et un état séparé ; zéro accompagné de valueNotAvailable(1) signifiait échec de lecture, pas mesure nulle.
  • La ligne d’alarme survivait, les tentatives manquées étaient comptées et un delta sans échantillon précédent devenait indisponible ; franchissement, événement, notification et action restaient des preuves distinctes.

Le chiffre qui ne savait rien

À la fin d’un intervalle, hcAlarmAbsValue devait contenir une valeur. Si l’instance surveillée ne pouvait pas être lue, RFC 3434 prescrivait zéro dans ce champ et valueNotAvailable(1) dans hcAlarmValueStatus. Le premier objet répondait à la forme du stockage ; le second disait ce que l’agent savait réellement.

Cette paire était indivisible. Le statut pouvait aussi déclarer une valeur positive ou négative, car un delta de compteur peut descendre même si le compteur brut est non négatif. Une exportation qui gardait le module mais supprimait l’état transformait trois situations — positif, négatif, inconnu — en une seule colonne rassurante.

Le texte brut, la notice RFC Editor, le dossier IETF, son historique et ses références datent et décrivent la norme. Ils ne prouvent aucun déploiement ni aucun incident réel.

Pourquoi soixante-quatre bits changeaient l’alarme

Le groupe d’alarmes de RFC 2819 surveillait des objets de 32 bits. Avec l’augmentation des débits, ce cadre devenait trop étroit. RFC 2863 montrait qu’un compteur d’octets sur 32 bits pouvait boucler en un peu plus de 57 minutes à 10 Mbit/s, en 5,7 minutes à 100 Mbit/s et en 34 secondes à 1 Gbit/s dans le cas décrit. Sonder assez vite pour ne jamais manquer un tour n’était plus une stratégie durable.

RFC 3434 créa donc une table indépendante pour Counter64 et CounterBasedGauge64, convention définie par RFC 2856. Elle conserva l’apparence opérationnelle de RMON et réutilisa sa table d’événements, mais elle ne fit pas passer une valeur large dans un récipient ancien.

Les seuils eux-mêmes étaient composites. Chaque seuil montant ou descendant utilisait un mot bas, un mot haut et un état de signe. Le module résultait du mot bas plus le mot haut multiplié par deux à la puissance trente-deux. Supprimer un composant changeait silencieusement la valeur.

La configuration persistait, l’observation non

Une différence essentielle avec l’ancienne table était la survie de la ligne lorsque la variable ne répondait pas pendant un intervalle. L’alarme configurée n’était pas détruite. hcAlarmValueFailedAttempts comptait les sondages sans valeur tant que la ligne restait active.

Cette persistance ne validait pas le contenu. Elle séparait la continuité de la règle de la continuité de l’observation. Le compteur d’échecs établissait qu’une récupération avait manqué ; il ne disait pas si la cause était un contrôle d’accès, un objet disparu, une surcharge, une erreur interne ou un problème de calendrier.

La distinction devenait plus profonde en mode delta. Pour calculer la variation, l’agent devait soustraire l’échantillon précédent du courant. Si le précédent manquait, aucun delta honnête n’existait. Même si la lecture actuelle réussissait, elle ne pouvait pas recréer son prédécesseur. Le statut du delta devait donc rester indisponible.

Un seuil n’était pas une livraison

Les seuils montants et descendants formaient une hystérésis. Un événement montant naissait lors du passage d’une valeur antérieure inférieure vers une valeur courante supérieure ou égale au seuil. Il ne pouvait être réarmé qu’après un retour jusqu’au seuil descendant. La règle inverse gouvernait l’événement descendant. Une politique de démarrage pouvait produire un événement lors du premier échantillon valide déjà hors limite.

Mais l’association avec un événement était encore une autre étape. Un index égal à zéro signifiait qu’aucun événement n’était associé. Un index non nul sans ligne correspondante dans la table des événements ne prouvait rien de plus. Franchissement, création d’événement, émission, réception, lecture humaine et correction appartenaient à des horloges différentes.

Le pointeur augmentait le pouvoir de lecture

La variable surveillée pouvait désigner un objet entier au-delà de RMON. RFC 3434 signalait une faiblesse structurelle : les vues SNMP contrôlaient l’accès aux objets, mais elles ne pouvaient pas limiter proprement la valeur du pointeur à un sous-ensemble lisible. L’écriture du pointeur ne devait donc être accordée que dans une vue capable de lire tous les objets de la sonde.

RFC 3410 décrit le cadre de gestion, RFC 3414 le modèle de sécurité fondé sur l’utilisateur et RFC 3415 le contrôle d’accès par vues. Leur présence dans les références n’atteste pas une configuration sûre. De même, RFC 2578, RFC 2579, RFC 2580 et RFC 2119 structurent le langage de la MIB, pas le comportement d’un produit précis.

Le registre SMI de l’IANA conserve le contexte d’identifiant. La recherche d’errata borne les corrections connues lors de la capture. Ni l’un ni l’autre ne mesure l’usage actuel.

Préserver l’inconnu

L’enseignement durable est simple : l’inconnu coûte plus de colonnes qu’un zéro, mais il vaut davantage. Une plateforme qui garde le module, l’état, le mode d’échantillonnage, le lien avec l’échantillon précédent, la ligne et le compteur d’échecs peut raconter ce qui s’est vraiment passé. Une plateforme qui aplatit ces champs invente une mesure.

La réflexion de Heng Lu sur les couches de réalité aide à comprendre pourquoi le zéro affiché devient vite plus puissant que le statut qui le réfute. Son plaidoyer pour le code exécutable et des affirmations bornées rappelle que la valeur d’une norme réside dans les distinctions qu’une implémentation conserve.

RFC 3434 ne garantissait pas une alarme utile. Il empêchait au moins un échec d’observation de se déguiser correctement en calme mesuré.

Sources