Re: [CCAMP] Comments on draft-vallin-ccamp-alarm-module-01

[stefan vallin <[e-mail]>]

Hi Balazs!
Thanks for your comments!

See answers inline

br Stefan and Martin

> On 14 Nov 2017, at 03:36, Balazs Lengyel <[e-mail]> wrote:
> 
> Hello,
> 
> Generally the module is good, but some comments:
> 
> 4.5.1) Add as a recommendation: An alarm agent SHOULD describe how long it retains cleared/closed alarms: till manually purged or if it has an automatic removal policy.
> 
> 
OK, will add and clarify.
> 5.1.1) State that shelving is effectively a way for the operator to suppress an alarm type/resource. Using the word suppress or block would make it easier to understand why do we do shelving.
> 
> 
Ok.
> For us it is a common situation that the operator does not want to suppress an alarm type, just change the severity level e.g. stating that a particular alarm type is not critical just minor. I am missing this functionality
> 
> 
I have kept this out by design. I consider this being a function of the alarm application, the client. 
If the system, the server, has “wrong” severity levels that should be managed by the system by local means.

Furthermore this notion assumes that there is a one-to-one mapping between alarm types and severity levels.
This is not the case, an alarm can go [(warning), (minor), (minor, cleared), (major)]
For example, a utilisation alarm for a link 70%, 80%, 90%.

(Same reason that I omitted the ITU Alarm Severity Assignment Profile)


> typedef resource) It should be stated that when the resource is modeled both in YANG and in SNMP and possibly has other addresses (simple string, distinguished name) which should appear in the resource leaf/type. IS there a fixed precedence between these address types? IMHO there should be.
> 
> 
Ok, will clarify
The priority order is:
     typedef resource {
       type union {
1)         type instance-identifier {
           require-instance false;
         }
2)      type yang:object-identifier;
3)         type string;

Note well that there is the alt-resource*  leaf. 
       |  +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
       |     +--ro time-created             yang:date-and-time
       |     +--ro resource                 resource
       |     +--ro alarm-type-id            alarm-type-id
       |     +--ro alarm-type-qualifier     alarm-type-qualifier
       |     +--ro alt-resource*            resource


This lets a server put the instance-identifier in the resource leaf which is used as key, and the OID in the alt-resource leaf for example.

> typedef severity) Which severity should be assigned to a loss of redundancy type problem? E.g. Link to one of the 2 license servers down.
> 
> 
I think that we have good tactics on setting severity levels revisiting the original texts in X.733. It reasons about service affecting or not.
See below, so it would be minor or warning
         enum minor {
           value 3;
           description
             "The 'minor' severity level indicates the existence of a
              non-service affecting fault condition and that corrective
              action should be taken in order to prevent a more serious
              (for example, service affecting) fault.  Such a severity
              can be reported, for example, when the detected alarm
              condition is not currently degrading the capacity of the
              resource.";
         }
         enum warning {
           value 4;
           description
             "The 'warning' severity level indicates the detection of
              a potential or impending service affecting fault, before
              any significant effects have been felt.  Action should be
              taken to further diagnose (if necessary) and correct the
              problem in order to prevent it from becoming a more
              serious service affecting fault.";
         }

Note also that a consistent use of the severity level descriptions makes a “service affecting flag” redundant.

> container alarm-shelving)
> 
> - the description starts with "This list ..."
> 
> 
Will fix :)
> - Is it possible to unshelve an alarm? When will an alarm have operator-state un-shelved? If an un-shelved alarm is acknowledged, will the systems still remember it was unshelved? IMHO if we support unshelving it should be a separate property not part of operator state. I would need to know that the alarm was unshelved AND acknowledged, both.
> 
> 
Shelving and unshelving is done by configuration. See my response to the email from Joey and Nick from Adtran on this as well. 
alarm-shelving/shelf
Unshelving is deleting the corresponding shelf configuration.

Operator states shelved/unshelved can *not* be set by an operator, only read.
These states are set by the instrumentation.
Ack will stay in the operator-state history:
       +--ro operator-state-change* [time] {operator-actions}?
       |  +--ro time        yang:date-and-time
       |  +--ro operator    string
       |  +--ro state       operator-state
       |  +--ro text?       string

For example
operator-state-change* list
* T1:  joe, ack
* T2: joe, shelved (set by instrumentation)
* T3: joe, un-shelved (set by instrumentation)


> container alarm inventory)
> 
> - the description starts with "This list ..."
> 
> 
Will fix :)
> As this container contains alarm-types, it should be called "container alarm-TYPE-inventory"
> 
> 
Possibly, will consider changing the name
> container summary)
> 
> "This container gives a summary of number of alarms and shelved alarms"
> If the operator decided to suppress (shelve) an alarm, it 
> SHOULD NOT be part of the summary counters. I shelved it because 
> I am not interested, than don't count it. 
> If I try to assess my network node's health and I decided that typeX alarms are 
> not relevant for me, then an alarm count indicating I have 100 typeX suppressed alarms is misleading.
> We need counters that exclude shelved alarms.

I will improve the descriptions, the intent is exactly as you describe. The description above refers to the fact that there are
summary counter for alarms (not shelved) and a leaf  indicating shelved alarms.
         leaf shelves-active {
           if-feature alarm-shelving;
           type empty;
           description
             "This is a hint to the operator that there are active
              alarm shelves.  This leaf MUST exist if the
              alarms/shelved-alarms/number-of-shelved-alarms is > 0.";
         }

Will improve descriptions.

> 
> container shelved-alarms) The description does not allow for unshelving. Then why do we have such an operator state?
See my response to the email from Joey and Nick from Adtran on this as well. The mechanism is not clear as currently described.
Shelving and un-shelving can *only* be done by configuring/deleting a shelve.
The operator-state shelved and un-shelved can only be *read* not set.

I will work on improving this in next version.

         enum shelved {
           value 4;
           description
             "Alarm shelved.  Alarms in alarms/shelved-alarms/
              MUST be assigned this operator state by the server as
              the last entry in the operator-state-change list.";
         }
         enum un-shelved {
           value 5;
           description
             "Alarm moved back to alarm-list from shelf.
              Alarms 'moved' from /alarms/shelved-alarms/
              to /alarms/alarm-list MUST be assigned this
              state by the server as the last entry in the
              operator-state-change list.";
         }



> 
> regards Balazs
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: [phone]              email: [e-mail] <mailto:[e-mail]> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp