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.
>
>>
>>
>>>
>>> The leaf "has-clear" seems like it would read better as "has-cleared" from an
>>> English standpoint. Thoughts?
>> Note well that this leaf is for the alarm *inventory*, not the alarm itself.
>> For the alarm itself the leaf is called "is-cleared".
>> The alarm inventory lists all candidate alarms and it is important for
>> operations to know if the server/instrumentation is capable of detecting
>> and generating alarm clear. So "has-clear" states that a specific alarm-type
>> will be cleared by the instrumentation when the alarm condition disappears.
>> I guess "has-clear" works in this context?
>
> Got it. I do see the is-cleared, and I got a bit confused here. After
> re-reading the has-clear leaf definition, I think will-clear makes more
> sense for this node.
Ok, we will consider change to "will-clear"
>
>>>
>>> Finally, I can see where it might be desirable to suppress alarm notifications
>>> without shelving them per se. That is, the alarm remains in the list, but
>>> notifications are not sent. That doesn't seem possible, and I'm wondering if
>>> it's worth considering.
>> It is possible using the /alarms/control/notify-status-changes choice:
>> leaf notify-all-state-changes {
>> type empty;
>> description
>> "Send notifications for all status changes.";
>> }
>> leaf notify-raise-and-clear {
>> type empty;
>> description
>> "Send notifications only for raise, clear, and re-raise.
>> Notifications for severity level changes or alarm text
>> changes are not sent.";
>> }
>> leaf notify-severity-level {
>> type severity;
>> description
>> "Only send notifications for alarm state changes crossing
>> the specified level. Always send clear notifications.";
>> }
>>
>> You could consider turning all of by adding another leaf:
>> leaf notify-none {
>> type empty;
>> description
>> "Don't send any notifications.";
>> }
>> Not sure if that would make sense, recommend to leave that out for further study.
>> Note well that you can always stop to subscribe to the notification stream.
>
> 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.
/stefan
> Joe
