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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E05D112716C for <>; Tue, 19 Mar 2019 07:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ALs8b_rWFsQx for <>; Tue, 19 Mar 2019 07:07:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 346E013128D for <>; Tue, 19 Mar 2019 07:07:18 -0700 (PDT)
Received: by with SMTP id u9so14387222lfe.11 for <>; Tue, 19 Mar 2019 07:07:18 -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=3ESaj/HfPv2409i2ATurerEIEYwm8Jxo55g6Nfu32cA=; b=qRHeTzQ4xSqxAaiy4Uancae5E4tuqpFH4fVqw4JAHPv5ceINp41JEfEBCjt6aESW1J mPqqdCpakvUOWMOCW92tE3m5mqFp2KCI84Pu45kdPcRXNRZcihL9eiyrvElJcGbIMYxQ uC9DlojHEKa0OUHcFMFFlfcmpuoNv3mtAXptc9yIzwvjLJ2FeEad3WckaeUvCFepUTvp asVHK3pb8ZWP6R5Cd6fzw9S6BGQ5Qnm5CIpbrZBJx1gow70fKYM4+ogfCJElDnHOhj7x CuCatxz5NKeU8rHLPXtF3+TR8SeBl9bqspoH3UeGWmR8wUZhYAsp42fLRs8jAcVrmrwy hDzQ==
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=3ESaj/HfPv2409i2ATurerEIEYwm8Jxo55g6Nfu32cA=; b=nn6E/ilWZalWa5TAChsPccb8RM1Nkmkeu2ZW8BGCmTc58uOUjMR37tH9Bejh0tV6Hh hd2sU6xpoYLToci1ZVdgDcE18L9gB6NfWRWJrJuNG1T6xD6AOXvFIaaFQrIdevnMEQyp 0YVRAJXp692C3g6jZxY6ZGD+TXyOqMqA4LIfUeHyo753HGNvyrkHmbAhOdEH2wpLpmhl c+i9uGmdFYu2dNzWnjD6lFUwkaxHszYY94fPLgKTY4J5jAyi3F2XUn31vqbGx4y0027R IH7C6okiO8fonCNB53bBwOebPRXBb4RI3E/NqzzsgOEMuITM+5Uh29lqeu9DSY0nEKwI 6YQA==
X-Gm-Message-State: APjAAAWPhZn5Yk/IHDWKhjmv7bhK6zrnJiB3W0NsLAz4OmMvdxITuLnQ bI6pkwnzqgylt0gerjLRiUbdzw==
X-Google-Smtp-Source: APXvYqwLLmHVjUb5dSp8PC9GWoJHTYo6QMJCN6FOcmQ8A6E2Lp5VsEMTlO+tkscOHDjpXMuPjZ4YyQ==
X-Received: by 2002:a19:ee11:: with SMTP id g17mr4362693lfb.117.1553004436358; Tue, 19 Mar 2019 07:07:16 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id t28sm2777977lje.9.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 07:07:15 -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 15:07:14 +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 14:07:22 -0000

Hi Joe!
Thanks for your review and comments!
See inline

br Stefan

> I have been assigned to review this draft on behalf of the OPS DIR.  Overall, I
> found the draft ready with some nits.  I found relatively easy to read and
> well-thought-through.  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.
Good :)
> 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 {
         "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 

     feature alarm-shelving {
         "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";

> 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?
> 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;
               "Send notifications for all status changes.";
           leaf notify-raise-and-clear {
             type empty;
               "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;
               "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;
     "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.

> My per-section nits (typos) are found below.
Will correct

> Section 3.2
> s/an hierarchy/a hierarchy/
> ===
> Section 3.5.1
> In the example, ((GigabitEthernet0/25, link-
>   alarm,""), false, T, major, "Interface GigabitEthernet0/25 down"), maybe
>   replace 'T' with a sample timestamp.  It took me a few seconds to grok that
>   as I was associating it with a boolean.
> ===
> Section 3.5.2
> s/criteria/criterion/
> ===
> Section 3.6
> s/the the disk full/the disk full/
> ===
> Section 3.7
> s/this criteria/these criteria/
> ===
> Section 4.7
> s/alarn/alarm/
> ===
> YANG Module section
> s/identifiying/identifying/
> s/exampla/example/
> s/alarm is not longer active using other/alarm is no longer active using other/