"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.
/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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
