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

[Martin Bjorklund <[e-mail]>]

"Bogaert, Bart (Nokia - BE)" <[e-mail]> wrote:
> Hi,
> 
> If I'm not mistaken, the following BBF addition was also proposed as to be
> added to the IETF entity model.  Is there no consensus about this one?

Not many spoke up.  I think there was just one comment, and that was
not in favor of adding this.



/martin


> 
> 1. Enabling a reset of an entity by means of an action
> 
> module bbf-entity-reset-action {
>   yang-version 1.1;
> 
>   namespace "urn:broadband-forum-org:bbf-entity-reset-action";
> 
>   prefix "bbf-entity-reset-action";
> 
>   import ietf-entity {
>     prefix ent;
>   }
>   ...
> 
>   identity reset-type {
>     description
>         "Type of reset requested of entity.  Examples of resets can be:
>            hardware-reset, reset-with-selftest, reset-without-selftest,
>            software-reset, possibly others.";
>   }
> 
>   identity hardware-reset {
>     base reset-type;
>     description
>         "Hardware reset";
>   }
> 
>   augment "/ent:entity-state/ent:physical-entity" {
>     description
>         "Augment entity model with an action to request a reset of the
>           entity";
>     action reset {
>       description "Request a reset of the entity";
>       input {
>         leaf reset-type {
>           type identityref {
>             base "reset-type";
>           }
>             description
>                 "Type of reset requested of entity";
>         }
>       }
>     }
>   }
> }
> 
> 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