Juergen Schoenwaelder <[email protected]> wrote: > Hi, > > I wonder when we use 'state' and when 'status' - is there a subtle > distinction or should be just consistently use lets say 'state', i.e., > changed to alalarm-status to alarm-state and standby-status to > standby-state?
The reason in this case is that we just used the MIB names. This said, I agree that "standby-state" and "alarm-state" are better. BTW, RFC 4268, which defines the original objects, says: The terms "state" and "status" are used interchangeably in this memo. > I also wonder about the mapping of the MIB object names to YANG leaf > names: > > +-------------------------------------+-----------------------------+ > | YANG data node in /hardware- | ENTITY-SENSOR-MIB object | > | state/component/sensor-data | | > +-------------------------------------+-----------------------------+ > | data-type | entPhySensorType | > | data-scale | entPhySensorScale | > | precision | entPhySensorPrecision | > | value | entPhySensorValue | > | oper-status | entPhySensorOperStatus | > | sensor-units-display | entPhySensorUnitsDisplay | > | value-timestamp | entPhySensorValueTimeStamp | > | value-update-rate | entPhySensorValueUpdateRate | > +-------------------------------------+-----------------------------+ > > Is the 'data-' prefix needed? If so, why is the a prefix not used for > 'precision' (scale and precision really go hand in hand). Unclear. I think I'm the one to blame for this inconsistency, and it goes back to the very first commit, but I can't remeber why. > Why is it > 'sensor-units-display' and not just 'units-display'? One option could > be: > > value-type > value-scale > value-precision > value > oper-status > units-display > value-timestamp > value-update-rate Yes this is better. > RFC 3433 points out that entPhySensorType and entPhySensorScale and > entPhySensorPrecision SHOULD NOT change during operation. What about > the YANG objects? I actually do not know what the SHOULD buys a client > since you can't rely on it. To be robust, you have to fetch an n-tuple > anyway and be prepared that a sensor may have changed its properties. > Should there be explicit text providing guidance that it is better to > fetch the whole n-tuple? This is certainly the simplest solution. Any comments? > Or alternatively, if supporting caching of > values is a goal, we may need to provide a > 'sensor-data/properties-last-changed' object that allows to make > caching of value properties robust. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
