Hi!
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
agree.
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
example.
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
system.
This does not mean the exact same view need to available in the alarm interface.
>
>
>
> /martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
