Hi Again!
Alex, can you elaborate a bit more on your requirements for alarm-history?
What are you missing in this module?
I want to make sure I understand your comment properly.
Stefan Vallin
ste...@wallan.se
+46705233262
> On 07 Oct 2016, at 09:42, Martin Bjorklund <m...@tail-f.com> wrote:
>
> Hi,
>
> stefan vallin <ste...@wallan.se> wrote:
>>> On 06 Oct 2016, at 00:22, Alex Campbell <alex.campb...@aviatnet.com>
>>> wrote:
>>>
>>> * Instead of shelved alarms, we have a simple boolean "disabled" setting
>>> * for each alarm; raised disabled alarms still appear as raised in the
>>> * all-alarms list (with another indication they're disabled), but do not
>>> * appear in the raised-alarms list.
>> Can be done with shelfing
>
> I think both are valid designs; either there is a flag in the
> alarm-list that marks an alarm as being shelved, or the shelved alarm
> is (conceptually) moved to a separate list. The design we chose is
> the latter, which has the benefit of not cluttering down the real
> alarm list with disabled stuff.
>
>>> With this model (and because ietf-entity.yang defines a hierarchy of
>>> entities) it is easy to display a hierarchical view of all entities
>>> and their associated alarms.
>>>
>>> In our model, entries in the all-alarms list can only be added when
>>> resources are added to the system, and can only be deleted when
>>> resources are removed from the system.
>> Alarm-inventory shall reflect the possible alarms, I will add your use
>> case to the description.
>>
>>>
>>>
>>>
>>> Other comments:
>>> * is-cleared feels like a double negation (false means "this alarm is
>>> * not not raised"); I would like to see it changed to is-raised
>> I think again your are confusing alarm-inventory and alarm-list. When
>> the alarm appears for the first time it is not cleared by the resource
>
> I understand Alex's concern, but since the normal state is that the
> alarm is not cleared, it makes sense that the node is 'is-cleared'.
>
>>> * I would like to see a YANG feature for past status changes, or perhaps
>>> * this part moved to a separate module augmenting ietf-alarms.
>> It is the “status-change” list, it shows all status changes
>
> I think Alex's point is that support for status-changes could be
> made optional, by introducing a YANG feature.
>
>>> * has-clear doesn't need to be a union of only one type
>> ?
>
> For some reason we have today:
>
> leaf has-clear {
> type union {
> type boolean;
> }
>
> (the reason for this is that originally this was a union of boolean
> and the enumeration 'unknown').
>
>
>
> /martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
