-----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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
