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

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

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:[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