One more comment: The BBF proposal defines 'contained-in' as a leafref, the current version of the hardware model has defined 'parent' as a string. In the state container parent is defined as a leafref. Parent type should be the same in both config and state container.
Best regards - Vriendelijke groeten, Bart Bogaert -----Original Message----- From: netmod [mailto:[email protected]] On Behalf Of Martin Bjorklund Sent: 23 January 2017 11:59 To: [email protected] Cc: [email protected] Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
