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?
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
