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

Martin Bjorklund <mbj@tail-f.com> Thu, 20 September 2018 08:31 UTC

Return-Path: <mbj@tail-f.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 A0BA0130E4F; Thu, 20 Sep 2018 01:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 m4lNIBwCWwVm; Thu, 20 Sep 2018 01:31:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF8124C04; Thu, 20 Sep 2018 01:31:10 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 6CD731AE02C9; Thu, 20 Sep 2018 10:31:07 +0200 (CEST)
Date: Thu, 20 Sep 2018 10:31:07 +0200
Message-Id: <20180920.103107.750560007019896412.mbj@tail-f.com>
To: KEE@kamstrup.com
Cc: ccamp@ietf.org, stefan@wallan.se, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <A81686D187412242AD51AAC709D0844334296B31@Exchange2010.kamstrup.dk>
References: <A81686D187412242AD51AAC709D0844334296B31@Exchange2010.kamstrup.dk>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/ghmvSKDcQ1qVL1aDN-AcNAemJ0k>
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: Thu, 20 Sep 2018 08:31:17 -0000

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
>