I also reviewed the ietf-alarms model. We are interested and intend to implement it replacing our proprietary model.

The model is flexible and covers all alarms scenarios we support.

IMO the operator and shelving functionality can potentially be moved to additional module augmenting a simpler ietf-alarms.yang allowing possible alternative models.

As I understand Alex he would like to see some solution adding some determinism by pairing known "resource" and {alarm-type-id,alarm-type-qualifier} tuples. This can be done in additional model since I see it as an additional feature not necessary to be part of the core ietf-alarms.yang and I see nothing preventing such additional model to be built on top of the current ietf-alarms.yang


On 10/11/2016 09:18 AM, stefan vallin wrote:

Alex, see inline on your comments.
Another thing, you had  an earlier comment:
"I would like to see a YANG feature for past status changes, or perhaps this 
part moved to a separate module augmenting ietf-alarms.”
Just to make sure I get your comment correctly.
Are you saying that you would like the alarm/status-change list to be a YANG feature 
to indicate “optionality"

    list status-change {
       if-feature alarm-status-changes;  <<<<<
       key time;
Alex Campbell <alex.campb...@aviatnet.com> wrote:

alarm-list holds a list of raised and cleared alarms (but not those
that have never been raised).
alarm-inventory holds a list of all possible alarm _types_.
If alarm-inventory were to hold a list of all possible alarms, that
would indeed resolve my concern. (It would be equivalent to our
all-alarms list)
But this only works for devices where you can (statically?) enumerate
*all* resources that possibly could be in an alarm state!  This does
not seem very scalable to me.  Or did I miss something in your

But other things than entities can have alarms. AND
instance-identifers are not “free-form”. It is a strange limitation to
limit alarms to the entity-model
I agree; however, it has the nice effects that it is possible to
enumerate all resources
So, we could consider the alarm-inventory to have an additional leaf “resource”.
I think that would resolve your issue?
Of course not all systems know that, but for those that do, this helps a lot, I 
I see that go well with another relevant comment you had that the 
alarm-inventory should have
a requirement that it needs to be updated when new cards are inserted for 
We might even add a notif for alarm-inventory changes.

On 11 Oct 2016, at 08:42, Martin Bjorklund <m...@tail-f.com> wrote:

See above.

and also that the resources and their
associated alarms form a hierarchy which can be visually displayed -
an operator can expand a tree to get progressively more detail on the
device status.
The top level of the tree shows "device has problems"; the next level
shows "line card 3 has problems"; the next level shows "Interface 3/2
has problems"; the next level shows "Interface 3/2 has no media".
However, I think the concepts of root cause resources and impacted
resources are more useful than this hierarchy.
Why wouldn't this be possible with the model we propose?
I think you are talking about a very useful application in the management 
This does not mean the exact same view need to available in the alarm interface.

netmod mailing list

netmod mailing list

Reply via email to