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

["Bogaert, Bart (Nokia - BE)" <[e-mail]>]

-----Original Message-----
From: Martin Bjorklund [mailto:[e-mail]] 
Sent: 24 January 2017 11:37
To: Bogaert, Bart (Nokia - BE) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

"Bogaert, Bart (Nokia - BE)" <[e-mail]> 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.
[Bart Bogaert] Having it as leafref allows to verify that the parent being
configured is actually existing in the entity model (or defined in the same
transaction).  Why would we remove the modelling capability to check this
consistency?

Bart


/martin


> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> -----Original Message-----
> From: netmod [mailto:[e-mail]] On Behalf Of Martin 
> Bjorklund
> Sent: 23 January 2017 11:59
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt
> 
> Juergen Schoenwaelder <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod