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

[Joe Clarke <[e-mail]>]

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