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

[Juergen Schoenwaelder <[e-mail]>]

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?

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). 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

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? 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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>