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

Joe Clarke via Datatracker <noreply@ietf.org> Mon, 18 March 2019 17:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ccamp@ietf.org
Delivered-To: ccamp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF69131184; Mon, 18 Mar 2019 10:00:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke via Datatracker <noreply@ietf.org>
To: <ops-dir@ietf.org>
Cc: draft-ietf-ccamp-alarm-module.all@ietf.org, ccamp@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Joe Clarke <jclarke@cisco.com>
Message-ID: <155292844015.26147.11067773612585181394@ietfa.amsl.com>
Date: Mon, 18 Mar 2019 10:00:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/bRRBhPJXytG3Cuwg6xpq3wO55Gc>
Subject: [CCAMP] Opsdir last call review of draft-ietf-ccamp-alarm-module-07
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 18 Mar 2019 17:00:40 -0000

Reviewer: Joe Clarke
Review result: Has Nits

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.

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.

The leaf "has-clear" seems like it would read better as "has-cleared" from an
English standpoint.  Thoughts?

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.

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

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



Section 3.6

s/the the disk full/the disk full/


Section 3.7

s/this criteria/these criteria/


Section 4.7



YANG Module section



s/alarm is not longer active using other/alarm is no longer active using other/