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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Mon, 08 Apr 2019 14:35:35 -0700

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.

---

From: stefan vallin <[email-masked]>
Date: Tue, 9 Apr 2019 14:27:19 +0200

Hi Warren!
Thanks for your review
See inline

br Stefan and Martin

> I support Roman's DISCUSS, especially #2.
See our response to Roman
> sure that you also catch the nits.
Yes, these are cateched
> courtesy to other readers.
This has been a topic in the CCAMP group as well, but we stick to it.
It is an established term in alarm standards and alarm systems in the process industry.

See for example the ISA 18.2 standard. Agree that it is not that well-known within IP and Telco
but there is a point in bringing in this concept since it is not just filtering.
As a reviewer said, aha it is "stashing"

> documents are not really clear …"

Good comment. Changed
> “sensors"
Corrected s/connects/connect/
I can see your point on sensors, but will keep detector….

> suggest "significant" instead.

Good point, changed
> criterion." - superfluous comma.
Fixed