Hi!
Vladimir, you can exclude shelving and operator actions in your implementation.
These are YANG features that an implementation can exclude.
See RFC 6020 7.18.1. The feature Statement
br Stefan
Stefan Vallin, Ph. D.
ste...@wallan.se
+46705233262
> On 11 Oct 2016, at 11:10, Vladimir Vassilev <vladi...@transpacket.com> wrote:
>
> Hi,
>
> 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
>
> Vladimir
>
>
> On 10/11/2016 09:18 AM, stefan vallin wrote:
>> 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
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
