[CCAMP] Warren Kumari's No Objection on draft-ietf-ccamp-alarm-module-08: (with COMMENT)

Warren Kumari via Datatracker <noreply@ietf.org> Mon, 08 April 2019 21:35 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 7939C120627; Mon, 8 Apr 2019 14:35:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ccamp-alarm-module@ietf.org, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, ccamp-chairs@ietf.org, daniele.ceccarelli@ericsson.com, ccamp@ietf.org, jclarke@cisco.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <155475933548.30143.7125328513195195530.idtracker@ietfa.amsl.com>
Date: Mon, 08 Apr 2019 14:35:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/2BTT9ezV1p-G0-5X8Lkfo8d55Vc>
Subject: [CCAMP] Warren Kumari's No Objection on draft-ietf-ccamp-alarm-module-08: (with COMMENT)
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, 08 Apr 2019 21:35:36 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-ccamp-alarm-module-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Roman's DISCUSS, especially #2.

Also, please see the OpsDir review here -- I believe that you have already
discussed it with the reviewer (Thank you, Joe Clarke!), but wanted to make
sure that you also catch the nits.

Like Joe, and others, I find the term "Alarm Shelving" to be confusing -  it
may be a formal term of art, but I've working in / with many NOCs, and have
never heard the term used; if anything the terminology I'm familiar with "Shut
up stupid alarm! I'll suppress it for now....". Shelving evokes memories of
https://pics.me.me/10-ill-just-put-this-over-here-with-the-rest-32772452.png I
would suggest introducing the term earlier, and more fully describing it as a
courtesy to other readers.

"X.733 and especially 3GPP were not really clear on this point." - this sounds
(unncessarily) rude - I would suggest perhaps "The X.733 and 3GPP Alarm IRP
documents are not really clear ..."

Nits:
"For example, a system with digital inputs that allows users to connects
detectors" s/connects/connect/ I would also think that a better term is
"sensors"

"A potential drawback of this is that there is a big risk that alarm operators
will receive alarm types as a surprise, ..." "big" reads oddly - I would
suggest "significant" instead.

"Alarm deletion (using the action "purge-alarms"), can use this state as a
criterion." - superfluous comma.