Re: [CCAMP] draft-ietf-ccamp-alarm-module-04/Clause 4.4 Alarm List history

stefan vallin <stefan@wallan.se> Tue, 06 November 2018 07:13 UTC

Return-Path: <stefan@wallan.se>
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 82AB41277C8 for <ccamp@ietfa.amsl.com>; Mon, 5 Nov 2018 23:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wallan-se.20150623.gappssmtp.com
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 Njkfuj42Lq6A for <ccamp@ietfa.amsl.com>; Mon, 5 Nov 2018 23:13:22 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A44312777C for <ccamp@ietf.org>; Mon, 5 Nov 2018 23:13:21 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id i26so8063011lfc.0 for <ccamp@ietf.org>; Mon, 05 Nov 2018 23:13:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AzVChbYT0rKa56eqNca7zmZv9byNuCbVeLS09uaRlP0=; b=Z91Sl+Vpz319Bo71bLPzMP9/Msy4hurX8qZL3YuMTaJzCC92D5WeABUTdrpSij80oy 7zHaWDAZUU19HNWKwjpvLMVkRGC3E0Ue0w9eaIO+T8mSuhKPqX4OQ085EhALZpFuUGtl 2TzQO/8eadHj1SNt/aUgmJpVMRLJD2k4/PnvCzUzVFRbvtGb6W9d7w6kgGuwB64aZe4r D+SnoFe8cKEggUlmrXaEe7zexgnkMGgZCwBvLPYzMLHFvfLLWZPdp743UP6X2j3o3Vq4 +aufTXzjI93SOYxcp94MO8Tu9uYCy2NK2A8Ey28Zg4aPuAdpprWWqsOMqUeQ9A6SS3S1 U/Qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AzVChbYT0rKa56eqNca7zmZv9byNuCbVeLS09uaRlP0=; b=HgY6CI4bolK7BbyoQe2hfc/uKFH1HsvShf4gEWn/pqytwI/J0CQEqLfTcziLMM7WpT 53Epa84bFY3OFZMFQSnnSh4pptTLNOi0KXPG9L96ai7bZJCE5QwLytu/GYG2N3+hROH5 qZzzSwCQVUMaNzKl5EeY9lGC65dflnnFG7QgzqOPdHIeStxb4kXWetiSSrPc8qWmyeyc tv1GJ2qN6VHFvuDyogoowvvpDmukMIinDeteE+yI7ULUB97YJF4ntQs1Vofs4ySPcKhm UeSpYoNqb7d00Spbjol64e9ResTzDe0vccWG/EEsS7QjTjj9Tw15gh3JwHLAtFiBWTcO 74DQ==
X-Gm-Message-State: AGRZ1gK4wEOOtNAyNsnLSGCF1gPgOelw1hHEVZvwVPrf58wEdKZ+ZWmu Y9dknXjtG2MqnGb7GnN3whZ9pw4yZb0=
X-Google-Smtp-Source: AJdET5cajYxy54zYApYeeSRrnUXWOgKloBHfAaEtBsjXvlxSZNtM8p14Gus3uW3a/rzWV6kT2qL+ZQ==
X-Received: by 2002:a19:8f45:: with SMTP id r66mr15494801lfd.9.1541488399437; Mon, 05 Nov 2018 23:13:19 -0800 (PST)
Received: from [192.168.99.186] ([195.234.15.132]) by smtp.gmail.com with ESMTPSA id q124-v6sm7066138ljb.89.2018.11.05.23.13.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Nov 2018 23:13:18 -0800 (PST)
From: stefan vallin <stefan@wallan.se>
Message-Id: <DE6B0EC9-5B6A-4539-9308-E7BBA64E7180@wallan.se>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CD5B8EFD-FBBF-4B68-9EB8-3EF8524B4A0A"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 6 Nov 2018 08:12:20 +0100
In-Reply-To: <DM6PR05MB5849D57890F35AF753284EDB9CCA0@DM6PR05MB5849.namprd05.prod.outlook.com>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
To: Marta Seda <Marta.Seda@calix.com>
References: <DM6PR05MB5849D57890F35AF753284EDB9CCA0@DM6PR05MB5849.namprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/S0xMEk2GtuQEv_7HcsFD9KnWtoU>
Subject: Re: [CCAMP] draft-ietf-ccamp-alarm-module-04/Clause 4.4 Alarm List history
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, 06 Nov 2018 07:13:25 -0000

Hi Marta!
Hope the below description helps:

Assume the following alarm notifications:
[time, resource, alarm-type, perceived-severity]

T1, r1, a-t1, warning
T2, r1, a-t1, clear
T3, r1, a-t1, warning
T4, r2, a-t2, warning
T5, r2, a-t2, clear
T6, r2, a-t2, warning
T7, r1, a-t1, clear


I will use the following truncated data-model for the alarm-list to illustrate:
     +--ro alarm* [resource alarm-type-id alarm-type-qualifier]
        +--ro is-cleared                 boolean
        +--ro last-changed               yang:date-and-time
        +--ro perceived-severity         severity
        +--ro status-change* [time]
           +--ro time                    yang:date-and-time
           +--ro perceived-severity      severity-with-clear

The above notifications will result in the following alarm list

alarm[r1, a-t1]
   is-cleared: true
   last-changed: T7
   perceived-severity: warning
   status-change
     T7, clear
     T3, warning
     T2, clear
     T1, warning
alarm[r2, at-2]
   is-cleared: false
   last-changed: T6
   perceived-severity: warning
   status-change
      T6, warning
      T5, clear
      T4, warning


The alarm list has two alarms, last changed at T7 and T6.
For each alarm you have the time stamps for the associated notifications.
T7
   T7
   T3
   T2
   T1
and
T6
   T6
   T5
   T4


So in order to get the original list of notifications, the management application
would have to flatten this. And this is by design. From usability perspective it
is not the list of notifcations that matters, it is how they map to the aggregated
alarm state. The operator sees two alarms and their history rather than 7 notifications.


br Stefan


> On 5 Nov 2018, at 17:35, Marta Seda <Marta.Seda@calix.com>; wrote:
> 
> Hello Stefan,
> Some colleagues of mine that have been reviewing “draft-ietf-ccamp-module-04”.   We have a question about the structure used in Clause 4.4 for alarm history:
>   +--ro status-change* [time] {alarm-history}?
> 
>          |  +--ro time                  yang:date-and-time
> 
>          |  +--ro perceived-severity    severity-with-clear
> 
>          |  +--ro alarm-text            alarm-text
> 
>  
> The status-change list has a single time key.
>  
> If you wanted to troubleshoot and look at alarms that occurred during a specific time window (e.g., alarms that occurred in the past between time x and y), how could you do this in the present model?
>  
> Or is the idea that a manager above the NETCONF server would provide that functionality through its own instrumentation? 
>  
> Could you clarify the intent of the model?
>  
> Thanks.
>  
> Marta Seda
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org <mailto:CCAMP@ietf.org>
> https://www.ietf.org/mailman/listinfo/ccamp <https://www.ietf.org/mailman/listinfo/ccamp>