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

stefan vallin <> Tue, 19 March 2019 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C6E51312A1 for <>; Tue, 19 Mar 2019 07:10:13 -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 CGX5E0oZ_Ux4 for <>; Tue, 19 Mar 2019 07:10:11 -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 8FB4D1312B8 for <>; Tue, 19 Mar 2019 07:10:08 -0700 (PDT)
Received: by with SMTP id y6so9244965ljd.12 for <>; Tue, 19 Mar 2019 07:10:08 -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=wu/u78buabgGIdOmu3adbsR/ZnURIszWlWkYzYI6umw=; b=HJ0lYtGRGC1uRzJ987gOd+fGU5yZlpyv4cHAt30g/BoQdvGgUccEsq8nYAoqAzvhw0 YIbZNMeoyBn+SUZYIwjMjo2RG/MrKDhTFK3p4v34tl9Njgdq+Zf8JjEyxWlMLDOJVoOT pMhQc7U3xUeRJ+Nblw0Wn4y5I7Q0gKClNVM42EmrfdsjkZuVetsj67fa+urkSJ4aO0oZ k29iWTyfHX+Nx42Kvm3T00MKp8/CxSgwPjcFaSXvdYsbdPXQXQcLdrYT8e6Qx/yW7K6b W7ClE8zf3pxSVXIhk9tqBoI9m3w/3QynW5un6K7I+IRiYqj9aNoZi8wH7zk58vW+Uqk/ OhlQ==
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=wu/u78buabgGIdOmu3adbsR/ZnURIszWlWkYzYI6umw=; b=Msc6xNsYsZ1y6P5evDKsxhYvL4j4vttNFgVhZBi3arMAsHKiPQvR0p9d2mnvsUSUvN JBajo30WcDdSJPCrmawI9xcNGbEseOCjy4eowFN6H/XMsBGSghyBseFxTIvopMykdtGz 9RzzubLTZ3uZD34mZ6hq3OhHZdq4hdM1jGlonOSblZ2bO92uMjSSO1K//80SBnNAbPWj UuPX73XflGygHc77uL3d5PGgehQNwPGRtasAYq1qww5XzRp2/fUyoMzIJgpneW19/4xH oxOkGg6TJjJluGfSSMjyymFN67hJxo0fRQNIENlEUyXBIUAaz6y5nuXAX6j6Gp6QQXqi rY+Q==
X-Gm-Message-State: APjAAAX0lxaPHLoTeyxe2krIIGk9NlfmtKrZb5y9uAOnPbRWqyDpWOA9 6E/aSxDFYZhKRYh9w2Oo1aQnMQ==
X-Google-Smtp-Source: APXvYqxma6T5QJ2zN5Q7I9dwVb3FbmpHo+rTmrc9qhNuSXqxU4w3ctLgvkIsa96pJvIMUcSAzDjpHA==
X-Received: by 2002:a2e:12c4:: with SMTP id 65mr10991294ljs.141.1553004606770; Tue, 19 Mar 2019 07:10:06 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id y25sm2793480lja.61.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 07:10:05 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: stefan vallin <>
In-Reply-To: <>
Date: Tue, 19 Mar 2019 15:10:05 +0100
Cc:,, "CCAMP (" <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <018701d4ddad$d34b5fc0$79e21f40$> <>
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 14:10:21 -0000

Adrian and Joe
Thanks for your discussion :)
I think we have come to agreement on the “shelving” term?
See my previous response on the notification suppression topic
br Stefan

> On 19 Mar 2019, at 11:55, Joe Clarke <> wrote:
> On 3/18/19 13:12, Adrian Farrel wrote:
>> Hi,
>> I see where Joe is coming from with the term 'Alarm Shelving', but I think it is a term of art in the alarm management world (entirely random example provided by duckduckgo...
>> Actually, I found the term to be quite evocative of the process.
> That's why I backed out my original comment.  As I read, it made more
> and more sense.  I was appreciative of the glossary to set the context,
> though.
>> His point about the impact on server resources is worth exploring.
>> And finally, yes, it seems to me that shelving and suppression of notifications seem to be approaching orthogonal. That is, suppression of notifications is not the same as suppression of alarms.
> I had originally thought to propose this as a name for shelving, but
> they are different as you say.  I see value in the suppression-only case
> for an operational standpoint.
> Joe
>>> Broadly speaking, I found the term "Alarm Shelving" to
>>> be confusing.  You do define this, but it is not something that many operators
>>> are familiar with.  I had originally thought alarm suppression was better, but
>>> after I read more, I see what you're trying to do with this.
>>> 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.
>>> 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.
>> Cheers,
>> Adrian
>> --
>> Want to buy a signed copy of a book of fairy stories for adults of all ages?
>> Send me an email and I'll bring one to Prague for you.
>> "Tales from the Wood"
>> "More Tales from the Wood"
>> "Tales from Beyond the Wood"