Re: [CCAMP] draft-ietf-ccamp-alarm-module-02
Karen Elisabeth Egede Nielsen <KEE@kamstrup.com> Tue, 02 October 2018 07:27 UTC
Return-Path: <KEE@kamstrup.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421DD130DCA; Tue, 2 Oct 2018 00:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LUXzQViWK9R; Tue, 2 Oct 2018 00:27:23 -0700 (PDT)
Received: from mail.kamstrup.com (mail.kamstrup.com [185.181.20.38]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104BF130DC3; Tue, 2 Oct 2018 00:27:22 -0700 (PDT)
Received: from EXCHANGE2010.kamstrup.dk ([::1]) by Exchange2010.kamstrup.dk ([::1]) with mapi id 14.03.0415.000; Tue, 2 Oct 2018 09:27:20 +0200
From: Karen Elisabeth Egede Nielsen <KEE@kamstrup.com>
To: stefan vallin <stefan@wallan.se>
CC: Martin Bjorklund <mbj@tail-f.com>, "ccamp@ietf.org" <ccamp@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: draft-ietf-ccamp-alarm-module-02
Thread-Index: AdRQCodrkWYiLZVDQVapWZ9icZtUKAAoPuyAAA5MvzACSI7fgAAFRodw
Date: Tue, 02 Oct 2018 07:27:20 +0000
Message-ID: <A81686D187412242AD51AAC709D08443342B21A8@Exchange2010.kamstrup.dk>
References: <A81686D187412242AD51AAC709D0844334296B31@Exchange2010.kamstrup.dk> <20180920.103107.750560007019896412.mbj@tail-f.com> <A81686D187412242AD51AAC709D0844334297C1E@Exchange2010.kamstrup.dk> <06297C39-B42A-492C-ABB5-3EB3C094F35D@wallan.se>
In-Reply-To: <06297C39-B42A-492C-ABB5-3EB3C094F35D@wallan.se>
Accept-Language: en-US, da-DK
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.19.187]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/oaQmBG_Zd4CnKq9E4CWJASjW3Uk>
Subject: Re: [CCAMP] draft-ietf-ccamp-alarm-module-02
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Oct 2018 07:27:26 -0000
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 <mbj@tail-f.com> > > Sent: 20. september 2018 10:31 > > To: Karen Elisabeth Egede Nielsen <KEE@kamstrup.com> > > Cc: ccamp@ietf.org; stefan@wallan.se; netmod@ietf.org > > Subject: Re: draft-ietf-ccamp-alarm-module-02 > > > > Hi, > > > > Karen Elisabeth Egede Nielsen <KEE@kamstrup.com> 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 > >>
- [CCAMP] draft-ietf-ccamp-alarm-module-02 Karen Elisabeth Egede Nielsen
- Re: [CCAMP] draft-ietf-ccamp-alarm-module-02 Martin Bjorklund
- Re: [CCAMP] draft-ietf-ccamp-alarm-module-02 Karen Elisabeth Egede Nielsen
- Re: [CCAMP] draft-ietf-ccamp-alarm-module-02 stefan vallin
- Re: [CCAMP] draft-ietf-ccamp-alarm-module-02 Karen Elisabeth Egede Nielsen