Re: [CCAMP] I-D Action: draft-ietf-ccamp-alarm-module-01 / purging alarms

Hi Stefan,

I am trying to understand the expected behavior of the ‘purge-alarms’ RPC, specifically when the client requests alarms that are active to be purged from the alarm list.

If you delete an alarm that is active for a resource, does the alarm immediately reappear for that resource after the RPC has executed, assuming that the undesirable state in that resource still exists and the instrumentation still detects it? This would be my expectation.

The description statement of ‘purge-alarms’ explicitly says that the RPC can typically be used to delete alarms that are in a closed operator state. In the Internet-draft you also write “Closed alarms are good candidates for being deleted.”
But a closed alarm may still be active from the resource life-cycle point of view and thus should IMHO immediately reappear, i.e., a new entry in the list be created. However, if this were the case the list ‘operator-state-change’ would be initially empty, with the effect that a previously alarm closed by the operator would no longer be in the operator state closed. This may, however, not necessarily be undesirable.

In the case of an active alarm that also lacks a corresponding clear, i.e., has-clear = 'false', if the instrumentation is no longer able to detect the undesirable state that previously existed, then such an alarm would indeed be removed from the alarm list and would not reappear.

In the YANG descriptions and in the Internet-draft only the alarm list is discussed with respect to purging. What about the shelved-alarm list? There may, for example, be cleared alarms in that list that could also be purged, without necessarily having to first un-shelve those alarms.

Could you clarify?

Best regards
Nick
This message has been classified General Business by NICK HANCOCK on Monday, 23 April 2018 at 11:36:08.

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of stefan vallin
Sent: Thursday, February 08, 2018 1:42 PM
To: CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-alarm-module-01.txt

Hi All!
We have now posted a new version of the draft. Updates based on comments from Balazs, Joey and Nick.

The major changes are:
1) Changed typedef operator-state into
- writeable-operator-state (not including includes shelved and un-shelved)
   can be set by an operator
- operator-state that can be read (includes shelved and un-shelved)

2) Added a leaf to the alarms in the shelf that states the name of the shelf.

3) Shelf criteria resource changed from leaf to leaf-list

4) Shelf criteria alarm type qualifier changed to regexp

5) Added text: "A server SHOULD describe how long it retains cleared/closed alarms: until manually purged or if it has an automatic removal policy.

6) Clarified that shelving/unshelving is done by shelf configuration and cannot be performed on individual alarms.

7) Clarified presedence order of resource naming ( 1 YANG instance identifier, 2 SNMP OID, 3 string )

8) Clarified that the alarm summary numbers do not include shelved alarms

9) Added a typedef resource-match which is a flexible way to identify resources.
Used in shelf criteria and alarm inventory

10) Clarified that an empty shelf indicates "shelf all”.

11) Added security considerations

12) Added reviewers to ack

There are still some outstanding items on the mailing list (from Nick and Joey).
But we felt it was time to publish the changes from some earlier discussions, see below.
Please let us know if we forgot something. I will top-post including these issues, summarising the discussions.
- severity filtering/shelving, needs further discussion
- temporal ordering, needs further discussion
- tagging of alarm types in alarm inventory, needs further discussion
- notifications for changed shelves, will add this in a later version
- probable cause description field, will add this in a later version

/stefan & martin

Stefan Vallin
stefan@wallan.se<mailto:stefan@wallan.se>
+46705233262

On 08 Feb 2018, at 12:33, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane WG of the IETF.

       Title           : YANG Alarm Module
       Authors         : Stefan Vallin
                         Martin Bjorklund
            Filename        : draft-ietf-ccamp-alarm-module-01.txt
            Pages           : 62
            Date            : 2018-02-08

Abstract:
  This document defines a YANG module for alarm management.  It
  includes functions for alarm list management, alarm shelving and
  notifications to inform management systems.  There are also RPCs to
  manage the operator state of an alarm and administrative alarm
  procedures.  The module carefully maps to relevant alarm standards.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/<https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-01<https://tools.ietf.org/html/draft-ietf-ccamp-alarm-module-01>
https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-01<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-alarm-module-01>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-alarm-module-01<https://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-alarm-module-01>

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org<mailto:CCAMP@ietf.org>
https://www.ietf.org/mailman/listinfo/ccamp<https://www.ietf.org/mailman/listinfo/ccamp>