On 3/19/19 11:16, stefan vallin wrote:
> Hi!
>
>> On 19 Mar 2019, at 15:16, Joe Clarke <jclarke@xxxxxxxxx> wrote:
>>
>> On 3/19/19 10:07, stefan vallin wrote:
>>>> Additionally, some of the features like alarm-history and alarm-shelving have a
>>>> potential operational impact with respect to local server resources, and
>>>> perhaps that's worth calling out.
>>> Good comment: suggested edits
>>> (could of course go somewhere else than in the feature desc)
>>>
>>> feature alarm-history {
>>> description
>>> "This feature indicates that server maintains a history of
>>> state changes for each alarm. For example, if an alarm
>>> toggles between cleared and active 10 times, these state
>>> changes are present in a separate list in the alarm.
>>> ADDED:
>>> The alarm-history feature has an impact on server memory
>>> resources.
>>> ";
>>> }
>>>
>>>
>>> feature alarm-shelving {
>>> description
>>> "This feature indicates that the system supports shelving
>>> (blocking) alarms.
>>> ADDED:
>>> Alarm shelving has an impact on server processing resources
>>> in order to match alarms against shelf criterion";
>>> }
>>
>> This is a good start, but people will miss this buried in the YANG
>> module. I think it deserves some text in the document itself. With
>> respect to resources, I recommend memory get called out especially
>> since, as I recall, you want all changes to be recorded in the history.
> Ok, I called out memory for alarm-history in my suggested edit above.
> For alarm shelving it will mostly be processing resources and not memory
> since the shelved alarms would anyhow stay in the larm list if not shelved.
> I will suggest a text snippet in the document as well.
Sorry. I thought I had seen memory, but I got a bit distracted. Thanks
for drafting some supporting text.
>> What if I want to control notifications on a per-alarm basis? Like
>> shelving filtering, but keeping the alarms on the list instead of a shelf.
>>
> We have excluded that by design. If we introduce too flexible notification filtering and at the same
> time support alarm shelving it will be hard to understand what is going on at the end, with these
> two mechanisms interfering. We had a fairly long thread in the CCAMP mailing group where we ended
> up where we are right now.
Okay. The fact that shelving without history wouldn't be too much
different than per-alarm suppression us likely sufficient. I was trying
to think through some of the operational use cases I have. Do you
envision a non-shelved alarm to periodically generate notifications
while active, or is it one-and-done?
Joe
