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 <[email protected]> > > Sent: 20. september 2018 10:31 > > To: Karen Elisabeth Egede Nielsen <[email protected]> > > Cc: [email protected]; [email protected]; [email protected] > > Subject: Re: draft-ietf-ccamp-alarm-module-02 > > > > Hi, > > > > Karen Elisabeth Egede Nielsen <[email protected]> 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 > >> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
