Re: [CCAMP] Opsdir last call review of draft-ietf-ccamp-alarm-module-07

[Joe Clarke <[e-mail]>]

On 3/19/19 11:16, stefan vallin wrote:
> Hi!
> 
>> On 19 Mar 2019, at 15:16, Joe Clarke <[e-mail]> 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