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.
>
>
>>
>> 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.
>>
>> 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.
Joe
