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

[Juergen Schoenwaelder <[e-mail]>]

Assuming that not all hardware components support the same set of
reset types (or resets at all), how do I find out which reset types I
can apply to a specific hardware component? Or is the idea to let the
management system do trial and error pushing of reset buttons?

/js

On Tue, Jan 24, 2017 at 09:48:00AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]] 
> Sent: 24 January 2017 10:28
> 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:
> > 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.
> [Bart Bogaert] Ok... don't these people require the need to offer an
> explicit reset capability of a HW entity to operators?  I would expect that
> this is something that could be made available generically (possibly under a
> feature if not everybody wants to implement this) rather than having various
> own implementations to achieve the same...
> 
> Bart
> 
> /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



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