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?
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). 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 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? 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. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
