Hi Joe!
Thanks for your review and comments!
See inline
br Stefan
>
> I have been assigned to review this draft on behalf of the OPS DIR. Overall, I
> found the draft ready with some nits. I found relatively easy to read and
> well-thought-through. Broadly speaking, I found the term "Alarm Shelving" to
> be confusing. You do define this, but it is not something that many operators
> are familiar with. I had originally thought alarm suppression was better, but
> after I read more, I see what you're trying to do with this.
Good :)
>
> 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";
}
>
> 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?
>
> 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.
>
> My per-section nits (typos) are found below.
Thanks!
Will correct
>
> Section 3.2
>
> s/an hierarchy/a hierarchy/
>
> ===
>
> Section 3.5.1
>
> In the example, ((GigabitEthernet0/25, link-
> alarm,""), false, T, major, "Interface GigabitEthernet0/25 down"), maybe
> replace 'T' with a sample timestamp. It took me a few seconds to grok that
> as I was associating it with a boolean.
>
> ===
>
> Section 3.5.2
>
> s/criteria/criterion/
>
> ===
>
> Section 3.6
>
> s/the the disk full/the disk full/
>
> ===
>
> Section 3.7
>
> s/this criteria/these criteria/
>
> ===
>
> Section 4.7
>
> s/alarn/alarm/
>
> ===
>
> YANG Module section
>
> s/identifiying/identifying/
>
> s/exampla/example/
>
> s/alarm is not longer active using other/alarm is no longer active using other/
>
