Juergen, I've been discussing internally here after observing that the current action definition has no output and hence it is not possible to report whether the reset is supported for a specific hardware instance. Further reflection is required on this.
Best regards - Vriendelijke groeten, Bart Bogaert -----Original Message----- From: Juergen Schoenwaelder [mailto:[email protected]] Sent: 24 January 2017 10:55 To: Bogaert, Bart (Nokia - BE) <[email protected]> Cc: Martin Bjorklund <[email protected]>; [email protected] Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt 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:[email protected]] > Sent: 24 January 2017 10:28 > To: Bogaert, Bart (Nokia - BE) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt > > "Bogaert, Bart (Nokia - BE)" <[email protected]> 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:[email protected]] On Behalf Of Martin > > Bjorklund > > Sent: 23 January 2017 11:59 > > To: [email protected] > > Cc: [email protected] > > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt > > > > Juergen Schoenwaelder <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
