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:
>> Hi,
>> 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
> descripition?
>>> 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.

> /martin

netmod mailing list

Reply via email to