Re: [CCAMP] Opsdir last call review of draft-ietf-ccamp-alarm-module-07

stefan vallin <> Tue, 19 March 2019 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 519071313D6 for <>; Tue, 19 Mar 2019 08:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LjjfV_hK9-3Q for <>; Tue, 19 Mar 2019 08:16:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 509EE13140A for <>; Tue, 19 Mar 2019 08:16:54 -0700 (PDT)
Received: by with SMTP id l7so7901781ljg.6 for <>; Tue, 19 Mar 2019 08:16:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NXVWBhmbCVKFiizk2E14LX9zGHlchv2MMuWApWRLgaQ=; b=vboioNHqjaJtAAMfoqbcjqtmBRNh0M8Z9SoeiyxxsfDA/Cw2x+hmFc4nLikcBa5kcZ lJByBBGQ28wn1aCpWNqDJEHX2pZuFnbIi3VQ2lJ7WQ39XXOFikUe18QhAcs/zTDWWhKb DYcDqTbSugyU3FNCJcaM1HwV794vMfZRQPCWIBCGqywnUsTXkw1WOKibHqhnz5zLLSOq P9EzPC39C+rKo4DE/OoFH+8nw5N0fvVmY2HNJn8T4sb//8sPFRzjoad6SzNSYUtnYLmQ HISZZx/4r6ICAa7F6jSkzRzCx8yckinsQuA44drRNkyn7BW1QWvSiikx9zkgbTiCOM2D 13hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NXVWBhmbCVKFiizk2E14LX9zGHlchv2MMuWApWRLgaQ=; b=LVP1oZ6vYiwyaMO4HzVj62sxd7QZ+Z9kDKce54vtZxTV4tZZMxzDgIWwPtDNhV2DOc JpYK++UjR1tq8c0ulJm5QClTqM15eVrdbpR6D3KK/F3Sr72fL0IPbNm/Z8kPYtj3A1YG eYmVX+7AHrHabW4LBc2aUooOc1FMHHrxu6KGLFwRSdGHb26N2Q1diBKeS3yxQC9ICpJo r1g4wp+GMxzf15vVWqwVsJE/xW1XGH/5DjumctTjvnI31qSbmmJhIdmjrlGyQNGafWCn 9bvUJS6p7gfX1ODSG73c9t71038Kfjry3RMUaRTIovW8Gjvo4yUGhT1riXFlZKgsCWa7 5ALA==
X-Gm-Message-State: APjAAAWAzW4galX9azthGU7SXbmUwj+NdqBYAwcpwu1IU5y74bdjXWW7 aMd4JOHxSIcvE8ArHg1otR4fQA==
X-Google-Smtp-Source: APXvYqy70qvCGm0luef8rEwt9u24RBtWvvC6ew0ZaCLmX2AcIANOj9RMHsZ6lTHPyfKlVAchwS0GcQ==
X-Received: by 2002:a2e:4504:: with SMTP id s4mr2212435lja.150.1553008612577; Tue, 19 Mar 2019 08:16:52 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id e12sm2886753ljk.55.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 08:16:51 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: stefan vallin <>
In-Reply-To: <>
Date: Tue, 19 Mar 2019 16:16:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Joe Clarke <>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <>
Subject: Re: [CCAMP] Opsdir last call review of draft-ietf-ccamp-alarm-module-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Mar 2019 15:17:07 -0000


> On 19 Mar 2019, at 15:16, Joe Clarke <> wrote:
> On 3/19/19 10:07, stefan vallin wrote:
>>> Additionally, some of the features like alarm-history and alarm-shelving have a
>>> potential operational impact with respect to local server resources, and
>>> perhaps that's worth calling out.
>> Good comment: suggested edits 
>> (could of course go somewhere else than in the feature desc)
>>     feature alarm-history {
>>       description
>>         "This feature indicates that server maintains a history of
>>          state changes for each alarm.  For example, if an alarm
>>          toggles between cleared and active 10 times, these state
>>          changes are present in a separate list in the alarm.
>>          The alarm-history feature has an impact on server memory 
>>          resources.         
>>          ";
>>     }
>>     feature alarm-shelving {
>>       description
>>         "This feature indicates that the system supports shelving
>>          (blocking) alarms.
>>          Alarm shelving has an impact on server processing resources
>>          in order to match alarms against shelf criterion";
>>     }
> This is a good start, but people will miss this buried in the YANG
> module.  I think it deserves some text in the document itself.  With
> respect to resources, I recommend memory get called out especially
> since, as I recall, you want all changes to be recorded in the history.
Ok, I called out memory for alarm-history in my suggested edit above.
For alarm shelving it will mostly be processing resources and not memory 
since the shelved  alarms would anyhow stay in the larm list if not shelved.
I will suggest a text snippet in the document as well. 
>>> The leaf "has-clear" seems like it would read better as "has-cleared" from an
>>> English standpoint.  Thoughts?
>> Note well that this leaf is for the alarm *inventory*, not the alarm itself.
>> For the alarm itself the leaf is called "is-cleared".
>> The alarm inventory lists all candidate alarms and it is important for
>> operations to know if the server/instrumentation is capable of detecting
>> and generating alarm clear. So "has-clear" states that a specific alarm-type
>> will be cleared by the instrumentation when the alarm condition disappears.
>> I guess "has-clear" works in this context?
> Got it.  I do see the is-cleared, and I got a bit confused here.  After
> re-reading the has-clear leaf definition, I think will-clear makes more
> sense for this node.
Ok, we will consider change to "will-clear"
>>> Finally, I can see where it might be desirable to suppress alarm notifications
>>> without shelving them per se.  That is, the alarm remains in the list, but
>>> notifications are not sent.  That doesn't seem possible, and I'm wondering if
>>> it's worth considering.
>> It is possible using the /alarms/control/notify-status-changes choice:
>> leaf notify-all-state-changes {
>>             type empty;
>>             description
>>               "Send notifications for all status changes.";
>>           }
>>           leaf notify-raise-and-clear {
>>             type empty;
>>             description
>>               "Send notifications only for raise, clear, and re-raise.
>>                Notifications for severity level changes or alarm text
>>                changes are not sent.";
>>           }
>>           leaf notify-severity-level {
>>             type severity;
>>             description
>>               "Only send notifications for alarm state changes crossing
>>                the specified level.  Always send clear notifications.";
>>           }
>> You could consider turning all of by adding another leaf:
>> leaf notify-none {
>>   type empty;
>>   description
>>     "Don't send any notifications.";
>> }
>> Not sure if that would make sense, recommend to leave that out for further study.
>> Note well that you can always stop to subscribe to the notification stream.
> What if I want to control notifications on a per-alarm basis?  Like
> shelving filtering, but keeping the alarms on the list instead of a shelf.
We have excluded that by design. If we introduce too flexible notification filtering and at the same
time support alarm shelving it will be hard to understand what is going on at the end, with these
two mechanisms interfering. We had a fairly long thread in the CCAMP mailing group where we ended
up where we are right now.


> Joe