Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

"Bogaert, Bart (Nokia - BE)" <bart.bogaert@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-bounces@ietf.org] On Behalf Of Martin Bjorklund
> Sent: 23 January 2017 11:59
> To: j.schoenwaelder@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> Juergen Schoenwaelder <j.schoenwaelder@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