Re: [CCAMP] draft-ietf-ccamp-alarm-module-02

[Karen Elisabeth Egede Nielsen <[e-mail]>]

Hi,

Thanks a lot.

I hope that you can accept the follow up right below:

* Would it not be relevant in the draft to outline the relation to the alarm-state in RFC8348 ?

** Possibly even in the substance of the document rather then in an appendix  - assuming that the two are seen as complementary mechanisms potentially based on the same underlying alarm framework (that you define in this draft)

** In the draft you have "closed" state of an alarm. Wouldn't it be relevant, in your opinion. with this alarm framework in mind, also to have the closed state in the alarm-state object of RFC8348 ?

* The same question (should be included in alarm-state of RFC8348) for the shelved alarms ?

Something else:

* Assuming that one has an alarm which have no clear  (see next question below) or where clear may not always come.
   Would an operator close of this alarm make it disappear from the active alarms summary ? Can that be an implementation decision  - possibly depending on the alarm type, possibly configurable ?

* RFC3877 has the following statement: "Alarms SHOULD  be modelled so Notifications are sent on alarm Clear."  
I did not find this statement in the substance of the draft nor in Appendix F (But it may have escaped me).  
Is this also the mindset of this draft ?

* It is correctly understood that the Alarm Summary and the Alarm list contains the alarms which are presently in the system - i.e. which have not been purged ?
  * Would it be relevant for the Alarm Summary list to tell when alarms was last purged due to administrative action ?

* Are you considering to implement support for statistics ?


BR, Karen

-----Original Message-----
From: Martin Bjorklund <[e-mail]> 
Sent: 20. september 2018 10:31
To: Karen Elisabeth Egede Nielsen <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: draft-ietf-ccamp-alarm-module-02

Hi,

Karen Elisabeth Egede Nielsen <[e-mail]> wrote:
> Hi,
> 
> This draft is new to me and modelling of alarm management also 
> somewhat....
> 
> Could you enlighten me on the relationship, if any, in between the 
> alarm module of this draft and the Device/resource alarm state within 
> RFC8348 (equivalently the EntityAlarmStatus of RFC4268) ?

The "alarm-state" in RFC 8348 (and EntityAlarmStatus in RFC 4268) is just a summary of the alarms that may be active on the specific hardware component.  It doesn't say anything about how alarms are reported, and it doesn't provide any details of the alarms; it is just a bitmask.

The alarm-module draft OTOH, specifies how alarms are reported, generically.  It also provides a list of all active alarms.

> E.g.  are the two they considered complementary mechanisms (modules), 
> just different view glasses, or are they non-compatible or redundant 
> ..?

So if both modules are implemented (they don't have to be), the information can be viewed as redundant or just different views.


/martin



> 
> Many Thanks in advance !
> 
> 
> BR, Karen Nielsen
>