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

[stefan vallin <[e-mail]>]

Thanks!
We will clarify
Br Stefan

> 1 nov. 2018 kl. 16:55 skrev NICK HANCOCK <[e-mail]>:
> 
> Hi Stefan,
>  
> I would like to briefly come back to a topic that we discussed by in May: purging alarms.
>  
> Specifically to the subsequent behaviour of the system when a client purges active alarms from the alarm list (or shelved alarm list).
> You clarified this situation with your reply
> “If the instrumentation state of the alarm changes at a later point a new alarm entry, (same keys of course), would appear.”
>  
> However, I do not see any reference to this expected behaviour when describing purging alarms in either the Internet draft or the YANG module itself.
> I believe it is important to describe the expected behaviour explicitly for interoperability reasons, otherwise vendors may implement differing behaviours in their systems with this regard.
>  
> What is your opinion?
>  
> Best regards
> Nick
>  
> From: stefan vallin [mailto:[e-mail]] 
> Sent: Wednesday, May 02, 2018 4:30 PM
> To: NICK HANCOCK
> Cc: CCAMP ([e-mail])
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-alarm-module-01 / purging alarms
>  
> Hi Nick!
> Thanks for your comments, really important feedback.
> See inline:
>  
> 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.
>  
> I would expect not, the client should know what it is doing, this is an administrative action and it is a matter of defining the right filters.
> Really annoying if I deliberately delete an alarm and it pops up.
> If the instrumentation state of the alarm changes at a later point a new alarm entry, (same keys of course), would appear.
> Furthermore, as you mention, alarms without a clear would not work in your proposal.
>  
> On the other hand your question made me think of another mechanism which would address your issue and also the case of "mid level managers" in SNMP lingo.
> Say you have an NMS with an alarm list for a large set of devices. You might want to be able to “synchronise” the alarm list in the NMS versus the devices. Or just the instrumentation in the same device for that matter. We could think of having an action/RPC “synchronise-alarms”. In your case it would update the alarm list versus the instrumentation state, in the NMS case it would reach out to the devices and make sure the alarm list represents what is out there.
>  
> Opinions from the Nick and the list?
>  
> 
> 
>  
> 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.
>  
> Good catch, need to update the draft to support administrative actions on the shelved alarms as well!
>  
> br Stefan
>  
> 
> 
>  
> 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:[e-mail]] On Behalf Of stefan vallin
> Sent: Thursday, February 08, 2018 1:42 PM
> To: CCAMP ([e-mail])
> 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
> [e-mail]
> [phone]
>  
> On 08 Feb 2018, at 12:33, [e-mail] 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/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/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
> 
> 
> 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/
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>