[CCAMP] Fw: New Version Notification for draft-vallin-ccamp-alarm-module-01.txt

[NICK HANCOCK <[e-mail]>]

Hi!

We have some questions and comments on the concept of shelving and how it is intended to be implemented and used within the YANG Alarm Module.


1. Alarm shelving and alarm suppression

3GPP TR 32-859 based on a presentation from ANSI/ISA 18.2 defines alarm shelving as one method of alarm suppression, the others being out-of-service alarms and alarms suppressed by design.

You effectively combined out-of-service alarms with alarm shelving deciding not to have separate lists for out-of-service alarms and shelved alarms. 3GPP TR 32-859 also defines 'a time limit for shelving', but such was not included as part of alarm shelving in the YANG Alarm Module. What was the reasoning behind these decisions?


2. Shelving and un-shelving alarms

This is our understanding of how alarms are shelved and un-shelved in the YANG Alarm Module:

An alarm will be shelved by a system when the alarm meets the ANDed criteria of one or more entries in the list 'shelf'.

So to shelve an existing alarm within the list 'alarm' an operator has to create an entry in the list 'shelf' or modify the criteria of one or more existing entries in the list 'shelf', so that the existing alarm is now included in the shelving criteria as defined by all entries within the list 'shelf'.
And to un-shelve an existing alarm within the list 'shelved-alarm' an operator has to delete an entry in the list 'shelf' or modify the criteria of one or more existing entries in the list 'shelf', so that the existing alarm is no longer included in the shelving criteria as defined by all entries within the list 'shelf'.

Is our understanding correct?

However: the action 'set-operator-state' connected to the list 'alarm' currently allows the value 'shelved' to be specified as a valid input for the leaf 'state'. How can this be reconciled with alarm shelving as described above?

Specifically, if the operator is able to explicitly shelve an alarm by means of this action, this would mean that there would be a shelved alarm in the list 'shelved-alarm', for which there is no entry in the list 'shelf' with criteria that meet the shelved alarm. In addition, there is no corresponding action connected to the list 'shelved-alarm' to enable an operator to un-shelve an alarm.


3. Shelf criteria

A shelf defines shelving criteria and these criteria are ANDed. But each of the leafs representing the criteria is also optional, which means that it would be valid to define a shelf with no criteria.
Since we see a valid use case where an operator wishes to shelf all alarms of a system with a single configuration, we thus believe would be very useful, if a shelf configured with no criteria would shelf all alarms.

Could the authors clarify what the intended behavior would be in the case of a shelf configured with no criteria?

To define an entry in the list 'x733-mapping' 'alarm-type-qualifier-match' was used instead of just 'alarm-type-qualifier'. Wouldn't the use of 'alarm-type-qualifier-match' instead of just 'alarm-type-qualifier' as a shelf criterion be a better and more flexible solution?


4. Shelving alarms for multiple resources

For maintenance purposes, it may be practical to be able to shelf all alarms for all resources associated with a given card within an equipment. In the current implementation, this would mean creating separate shelf entries, one for each affected resource located on the card. Wouldn't it be advantageous if the criterion 'resource' be a leaf-list instead of just a leaf?


5. Shelving based on perceived severity

We are aware that in some network implementations there is the requirement to be able to shelve alarms based on their severity.

The severity of an alarm is not included in the criteria of a shelf in the YANG Alarm Module. Was this considered? What are the authors view on supporting shelving based on the severity of an alarm?


6. Shelving an active alarm only until it is cleared

We are considering the use case, in which an operator is requiring to shelve an active alarm only until it is cleared, i.e., when the alarm is cleared, it should be automatically be un-shelved by the system.  This use case is currently not covered by the current implementation of the YANG Alarm Module, because alarms are shelved based only on the criteria defined by the entries in the list 'shelf', which apply independently of whether an alarm is active or cleared.

What are the authors views on supporting such a use case and how could this be implemented?


7. Notifications

When alarms are shelved, the system is to stop sending notifications for the shelved alarms.
We infer that at the point in time when an alarm is shelved, no notification would be sent as the change of the 'operator-state' of an alarm is never notified.

We are concerned that in the case of multiple clients, some clients will not be made aware that an alarm has been shelved.

Why was an explicit 'alarm shelved/un-shelved' notification, which would be sent when an alarm is shelved and when it is un-shelved, not implemented in the YANG Alarm Module?


if any of these topics have already been discussed before, please point us to where we can find the discussion.

Joey Boyd & Nick Hancock