"Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > 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.
The reason for the 'string' in the config tree is that when it is pre-configured, it doesn't really refer to a component in the state tree. If it eventually matches a real component, the server will instantiate an entry in the state tree, and at this point the parent *is* a proper reference to another component. Note that the underlying type is the same in both cases. /martin > > Best regards - Vriendelijke groeten, > Bart Bogaert > -----Original Message----- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Martin Bjorklund > Sent: 23 January 2017 11:59 > To: j.schoenwael...@jacobs-university.de > Cc: netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
