Résumé

  • Dans RFC 3433, entPhySensorValue n’était pas une mesure autonome. Le type, l’échelle décimale et la précision donnaient son sens à l’entier ; l’état opérationnel, l’horodatage et le rythme de mise à jour limitaient ce que l’on pouvait dire de son actualité.
  • Un rythme nul pouvait signifier une acquisition à la demande, une mise à jour sur événement ou un rythme inconnu. ok(1) disait que l’agent obtenait une valeur, non que le capteur était étalonné ni que le monde physique confirmait cette valeur. Les seuils d’alarme relevaient d’un autre mécanisme.

Le tableau de bord affichait 315, pas encore une mesure

Une station de supervision reçoit l’entier 315. Elle sait l’imprimer. Elle ignore encore s’il s’agit de 31,5 degrés Celsius, de 315 tours par minute, de 315 watts, d’une grandeur relative, d’un marqueur de dépassement ou d’une ancienne lecture conservée entre deux scrutations.

RFC 3433, publié en décembre 2002 sous le titre Entity Sensor Management Information Base, normalisait le contexte manquant. Son texte brut, sa fiche RFC Editor, sa page IETF, son historique, ses références et la recherche d’errata décrivent un contrat Standards Track. Ils ne rapportent aucune mesure d’un équipement actuel.

Le module ajoutait une table clairsemée à l’Entity MIB pour les composants physiques classés sensor(8). La ligne de capteur reprenait le même entPhysicalIndex que l’entité physique. L’agent devait créer les deux ensemble et supprimer la ligne du capteur lorsque l’entité disparaissait. Le texte s’appuyait alors sur l’Entity MIB de RFC 2737 ; la version 4 de RFC 6933 a ensuite maintenu ce cadre d’indexation physique.

Avant de demander « combien ? », le système devait donc répondre « quel composant l’agent prétend-il décrire ? ».

Le sens se trouvait dans un triplet

RFC 3433 plaçait à côté de la valeur un type, une échelle et une précision. Le type distinguait tension alternative ou continue, courant, puissance, fréquence, température Celsius, humidité relative, tours par minute, débit d’air, vérité logique, autre valeur et valeur inconnue. L’échelle appliquait une puissance de dix, de yocto à yotta. La précision donnait la position décimale d’un nombre fixe ou le nombre de chiffres exacts.

Ces champs formaient la sémantique de entPhySensorValue. Un capteur de température allant de 0 à 100 degrés par pas de 0,1 pouvait déclarer l’échelle units, la précision 1 et retourner des entiers de 0 à 1000. Dans ce contrat seulement, 315 devenait 31,5 degrés. Le même entier, avec un autre type ou une autre échelle, constituait une autre affirmation.

Pour les types à point fixe, un milliard négatif et un milliard positif étaient réservés à la sous-capacité et au dépassement. Les traiter comme des observations ordinaires créait une fausse valeur extrême.

La construction reposait sur SMIv2 : RFC 2578 définissait la structure de l’information de gestion, RFC 2579 les conventions textuelles, RFC 2580 les déclarations de conformité, et RFC 2119 la force des mots normatifs.

Même la liste des échelles avait besoin d’une provenance. L’erratum vérifié 2008 corrigeait l’inversion de deux commentaires : peta(14) correspond à 10^15 et exa(15) à 10^18. Un programme lisant l’énumération et un opérateur recopiant le commentaire pouvaient autrement diverger de trois ordres de grandeur.

La précision du codage n’était pas une classe d’exactitude

Le mot précision invitait à en dire trop. Ici, il décrivait la place de la virgule ou le nombre de chiffres exacts de la représentation fixe. Il ne certifiait pas à lui seul l’étalonnage, l’incertitude, la traçabilité ou une classe réglementaire.

RFC 7460, consacré plus tard au suivi de l’énergie, a rendu la distinction explicite. Le modèle de RFC 3433 ne portait pas les classes d’exactitude ANSI ou IEC exigées pour l’électricité. RFC 7460 a donc défini un objet séparé pour l’exactitude de puissance.

Un appareil peut livrer une décimale sans être exact au dixième. Ajouter des chiffres rend le format plus détaillé ; cela n’efface ni biais systématique ni mauvais étalonnage.

entPhySensorUnitsDisplay fournissait un libellé humain. Il n’annulait pas l’autorité du type et de l’échelle pour l’interprétation machine. Une application ne devait pas reconstruire le modèle de données en devinant le texte d’affichage.

L’état décrivait ce que savait l’agent

Trois états existaient. ok(1) signifiait que l’agent pouvait obtenir la valeur. unavailable(2) indiquait qu’il ne le pouvait pas actuellement. nonoperational(3) disait que l’agent croyait le capteur défaillant, à cause d’une panne dure comme un fil débranché ou d’un comportement mou comme une mesure hors plage, instable ou violemment fluctuante.

Cette formulation bornait l’autorité. ok ne prouvait ni l’étalonnage, ni le placement physique, ni la justesse de la correspondance entre le capteur et son index. nonoperational ne livrait pas un diagnostic causal complet.

L’introduction au cadre de gestion SNMP dans RFC 3410 rappelle qu’une MIB est un magasin virtuel présenté par un agent. Entre le phénomène physique et la ligne lue se trouvent le capteur, son pilote, l’agent, son horloge, sa stratégie de collecte et le contrôle d’accès.

Le zéro du rythme de mise à jour gardait trois histoires

entPhySensorValueTimeStamp enregistrait le sysUpTime auquel l’agent avait obtenu pour la dernière fois la valeur et/ou l’état. Un entPhySensorValueUpdateRate positif déclarait, en millisecondes, l’intervalle de scrutation, éventuellement estimé.

Le zéro était plus délicat. La définition détaillée lui attribuait trois cas : mise à jour à la demande, mise à jour lorsque la valeur change, ou ignorance du rythme par l’agent. Deux stratégies pouvaient produire une valeur très récente ; la troisième avouait qu’on ne savait pas.

Le résumé du document opposait le zéro à une ancienne valeur de scrutation, mais l’objet normatif conservait cette ambiguïté. Traduire automatiquement zéro par « temps réel » supprimait l’information la plus importante. Il fallait garder le rythme, l’horodatage, l’heure de collecte, l’état et, si elle était connue, la stratégie d’implémentation.

Un rythme positif n’était pas davantage une garantie. Il indiquait une intention ou une estimation de scrutation. Le décalage entre sysUpTime, l’horodatage et l’instant de collecte pouvait révéler une valeur trop ancienne, sans prouver quand le capteur avait physiquement effectué sa conversion.

Le seuil et l’alarme vivaient ailleurs

RFC 3433 ne définissait aucun seuil spécialisé. Il recommandait un mécanisme général tel que les groupes Alarm et Event de la RMON MIB, RFC 2819.

Une lecture qui franchit un seuil, un évaluateur qui détecte le franchissement, une notification qui arrive et un actionneur qui réagit sont quatre événements distincts. La table Entity Sensor était en lecture seule. Elle ne prouvait ni la configuration d’une règle, ni la réception d’une alarme, ni un arrêt, ni une réparation.

Cette séparation protège aussi l’audit. Une ancienne valeur élevée ne démontre pas qu’elle avait la bonne échelle, que le capteur était opérationnel, que la donnée était fraîche ou qu’une politique exigeait une action.

Une valeur en lecture seule pouvait rester sensible

Le document identifiait entPhySensorValue comme potentiellement sensible. SNMPv1 n’offrait pas à lui seul un environnement sûr ; même un réseau protégé par IPsec ne décidait pas quels utilisateurs avaient le droit de lire chaque objet.

RFC 3433 recommandait le modèle utilisateur SNMPv3 de RFC 3414 et le contrôle d’accès par vues de RFC 3415. Identité du principal, confidentialité et vue autorisée étaient des preuves d’accès, séparées de la sémantique physique du nombre.

Un GET réussi pouvait établir qu’un principal autorisé avait reçu la représentation publiée par l’agent. Il ne certifiait pas le capteur, son étalonnage, sa correspondance avec l’index ni l’actualité du monde observé.

Sources et limites

Cette lecture suit aussi les distinctions proposées par Heng Lu entre couches de réalité et la pratique du code en fonctionnement comme preuve primaire. Champ de spécification, comportement d’agent, réponse GET, tension physique, événement d’alarme et résultat d’exploitation sont liés sans être équivalents.

Les vingt sources établissent le contrat historique et ses limites ultérieures. Elles n’établissent aucun déploiement nommé, taux d’adoption, exactitude réelle, incident, intrusion, livraison d’alarme, réparation ou résultat commercial. La contribution de RFC 3433 était plus modeste et plus solide : empêcher un entier nu de passer pour une mesure complète.