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

[Martin Bjorklund <[e-mail]>]

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