Summary

  • RFC 3433 did not treat entPhySensorValue as a self-describing measurement. Type, power-of-ten scale and fixed-point precision determined what the integer meant; operational status, timestamp and update-rate semantics bounded whether it was usable as a present observation.
  • A zero update rate was deliberately ambiguous among on-demand update, event-driven update and unknown rate. ok(1) meant the agent could obtain a value, not that the sensor was calibrated or the physical claim was true. Threshold alarms lived in another mechanism.

The integer on the screen was only the middle of the story

Suppose a management station retrieves the integer 315 from a physical sensor. It can display the number immediately. It cannot yet say whether the number means 31.5 degrees Celsius, 315 revolutions per minute, 315 watts, an arbitrary relative quantity, an overflow condition or something stale from an earlier poll.

RFC 3433, published in December 2002 as the Entity Sensor Management Information Base, standardized the missing context. Its plain text, RFC Editor record, IETF page, history, reference graph and errata search preserve a Standards Track representation contract. They do not establish what any particular router, switch or power shelf reported in practice.

The memo extended the Entity MIB with a sparse table for physical components whose class was sensor(8). Each sensor row reused the corresponding entPhysicalIndex. The agent was expected to create the sensor row when it created the physical-entity row and remove it when that entity disappeared. The original relationship used the Entity MIB in RFC 2737; the later version 4 in RFC 6933 preserves the larger physical-entity indexing frame.

Identity came first: before interpreting a number, an operator needed to know which physical component the agent said it described.

Three fields turned a raw value into a quantity

RFC 3433 defined a type, a scale and a precision alongside the value. The type distinguished volts AC, volts DC, amperes, watts, hertz, Celsius, relative humidity, RPM, airflow, truth value, other and unknown. The scale supplied an SI power of ten, from yocto to yotta. Precision explained fixed-point decimal placement or the number of accurate digits.

The three fields were not optional decoration. Together they supplied the semantics of entPhySensorValue. A temperature sensor spanning 0 to 100 degrees in tenths could report integer values from 0 to 1000, with scale units and precision 1. The integer 315 would then mean 31.5 degrees. With a different type, scale or precision, exactly the same stored integer would make a different claim.

The range also reserved -1,000,000,000 and +1,000,000,000 as underflow and overflow for fixed-point types. Treating either sentinel as an ordinary measurement would create a plausible-looking lie.

The design depended on SMIv2. RFC 2578 supplied the structure of management information, RFC 2579 its textual-convention machinery, and RFC 2580 conformance statements. RFC 2119 supplied the normative vocabulary.

Even the scale list needed provenance. Verified erratum 2008 corrected transposed labels in the published text: peta(14) is 10^15 and exa(15) is 10^18. A parser that knows only the numeric enumeration and a human who copies only the comment can otherwise disagree about magnitude.

Precision was not the same thing as accuracy

The word precision invites overclaiming. In RFC 3433 it encoded decimal placement or accurate digits for the returned fixed-point representation. It did not, by itself, certify calibration, uncertainty, traceability or an industry accuracy class.

That boundary later became explicit in RFC 7460, which described power and energy monitoring. Electricity measurement required ANSI and IEC accuracy classes that RFC 3433 did not carry. RFC 7460 therefore introduced a separate power-accuracy object and a different multiplier representation.

A device may report one decimal place without being accurate to one tenth of a unit. More digits can describe the encoding while saying little about systematic error. The representation can be internally precise and physically wrong.

entPhySensorUnitsDisplay also did not supersede the machine tuple. It offered a textual unit description for display. Software still had to use the type and scale fields rather than parse presentation text as authority.

Status described the agent’s knowledge

The operational-status field had three values. ok(1) meant the agent could obtain the sensor value. unavailable(2) meant it presently could not. nonoperational(3) meant the agent believed the sensor was broken, whether through a hard fault such as a disconnected wire or a soft fault such as an out-of-range, jittery or wildly fluctuating reading.

Those definitions were carefully epistemic. Status was what the agent could obtain or believed. An ok row did not prove calibration, correct placement, intact wiring outside the agent’s visibility or correspondence with the physical world. A nonoperational judgment did not diagnose a specific root cause.

The SNMP management framework overview in RFC 3410 helps place the row correctly: a MIB is a managed information model exposed by an agent. It is not a direct physical observation available without software, timing or access-control layers.

Freshness had a timestamp—and an ambiguous zero

entPhySensorValueTimeStamp recorded the value of sysUpTime when the agent last obtained the sensor’s status and/or value. entPhySensorValueUpdateRate reported the possibly estimated number of milliseconds between polling updates when the agent used a positive rate.

The interesting case was zero. The detailed object definition gave zero three meanings: the value was updated on demand, it was updated when the sensor changed, or the agent did not know the update rate. One numeral therefore combined two potentially fresh strategies with a declaration of ignorance.

The overview said zero meant the agent returned current data rather than the last polling interval, while the formal object text preserved the three-way ambiguity. A responsible collector cannot collapse those sentences into “zero guarantees live data.” It must retain the rate, the timestamp, the collection time, the status and any implementation knowledge that distinguishes on-demand, event-driven and unknown.

A positive rate is not a freshness guarantee either. It is a stated, possibly estimated polling interval. The current time minus sysUpTime and the last-update timestamp can show that a value is older than expected, but cannot prove the sensor’s own conversion time or physical accuracy.

The sensor table did not contain an alarm engine

RFC 3433 deliberately defined no specialized sensor threshold mechanism. It recommended a general mechanism such as the alarm and event groups in the Remote Network Monitoring MIB, RFC 2819.

That separation matters. A value crossing an operator-defined threshold, an alarm evaluator noticing the crossing, a notification being delivered, and an actuator changing state are different events. The Entity Sensor MIB row supplied a read-only representation. It did not prove that anyone had configured a threshold, received an alarm, shut down hardware or repaired a fault.

The clean boundary also prevents a common audit error: finding a high temperature value in a historical poll does not establish that the value was high under the correct scale, that the sensor was operational, that the record was fresh, or that a policy required action at that point.

Read-only data could still be sensitive

The memo identified entPhySensorValue as potentially sensitive because it could expose physical-sensor values. It warned that SNMPv1 alone was not a secure environment, even if the surrounding network used IPsec. Network membership did not decide which principal was allowed to retrieve a specific object.

The security section recommended the SNMPv3 User-based Security Model in RFC 3414 and the View-based Access Control Model in RFC 3415. Authentication, privacy and an authorized view were separate from the meaning of the sensor tuple.

A successful GET could establish that an authenticated management principal received what an agent exposed. It could not prove that the sensor was well calibrated, that the agent’s mapping to entPhysicalIndex was correct, or that the returned value described the current world.

Sources and limits

This interpretation also follows Heng Lu’s distinction among layers of reality and the discipline of treating running code as primary evidence. A specification field, an agent implementation, a retrieved MIB value, a physical voltage, an evaluated alarm and an operating outcome are related but non-interchangeable facts.

The 20-source packet defines the historical contract and its later boundaries. It does not prove a named implementation, deployment rate, sensor accuracy, physical incident, security breach, alarm delivery, remediation or business result. RFC 3433’s achievement was narrower and durable: it refused to let a bare integer masquerade as a complete measurement.