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

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

HI Stefan, Martin,

Thanks a lot.
Pls see inline below.

BR, Karen

<snip>

> >
> > 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)
> We can add a short description on the relationship between the Alarm
> Module and RFC8348.
> As Martin stated they serve different purposes:
> "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, specifies how alarms are reported, generically.  It also
> provides a list of all active alarms."
> 
> The mapping between the data-models are outlined below.
> Alarm YANG.                                 RFC 8348
> alarm list
> * resource                                      corresponds  to /hardware/component/
> * is-cleared                                    no bit set in
> /hardware/component/state/alarm-state
> * perceived-severity                       corresponding bit set in
> /hardware/component/state/alarm-state
> * operator-state-change/state.      if the alarm is acked by the operator it
> could correspond to under-repair
> 
[Keen] I would appreciate that very much. Thanks !
> >
> > ** 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 ?
> This would be an update to RFC 8348, and is out of scope for this work
[Keen] Yes. However the IETF makes comprehensive standards. 
The present gap in between this work (which I support) and RFC8348 is actually also one of the reasons why I think that it is important to 
explicitly relate to  RFC8348 in this work (draft in subject).

For our usecase (IoT) I think that it will be relevant to implement a solution inline with this draft. However I also believe that we would like to implement support for alarm-state object of RFC8348, in this case then for usefulness extended with the "closed" state.

> >
> > 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 ?
> The general answer is no, as stated in the document, there is no automatic
> purge/deletion of an alarm on clear from the resource or close from the
> operator.
> This is by design, from an ops perspective it makes sense to be able to view
> the alarm even after it is cleared/closed.
> You might want to study the root cause afterwards to perform proactive
> actions for it not to appear again for example.
> 
[Keen] Yes that makes good sense.

> But as you say, you can make it an implementation decision, "purge on
> clear", "purge on close".
> If it is hard-coded per alarm-type, describe it in the alarm inventory You can
> also make it configurable per alarm type by augmenting the alarm profile
> with a purge-policy: "purge on clear", "purge on close"
> >
[Keen] Thanks.

> > * 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 ?
> According to this alarm module an alarm-notification will be sent with
> perceived-severity set to cleared

[Keen] Is that stated explicitly in the draft ?
Will you associate a keyword  with this statement ?

> >
> > * 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 ?
> Correct
> >  * Would it be relevant for the Alarm Summary list to tell when alarms was
> last purged due to administrative action ?
> We do not want to load the alarm module with more features at this point,
> this could be done in the management application/client.
> >
[Keen] It might be prudent to have this state in the server as well (?)

> > * Are you considering to implement support for statistics ?
> What do you mean with statistics?
> a) Statistics on alarms or do you mean a b) performance monitoring
> module?
> It a, no, that is up to the management application If b, that is a separate
> module not within this one

[Keen] I was referring to the first. Here first and foremost statistics on received alarms divided on severity level.

Yes it can be done in the management application, but I am not sure why it is necessarily "up to the management application" to do this ?

Would some global statistics in the server not make sense - or do you have specific reasons for placing all statistics in the management application layer ?

BR, Karen

> 
> >
> >
> > 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
> >>