Skip to main content

A YANG Data Model for Alarm Management
draft-ietf-ccamp-alarm-module-09

Yes

(Deborah Brungard)

No Objection

(Alvaro Retana)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)

Abstain


Note: This ballot was opened for revision 08 and is now closed.

Roman Danyliw
(was Discuss) No Objection
Comment (2019-04-25) Sent for earlier
Thank you for iterating to resolve my DISCUSSes and address my comments
Warren Kumari
No Objection
Comment (2019-04-08 for -08) Sent
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.
Éric Vyncke
No Objection
Comment (2019-04-06 for -08) Sent
Easy to read and well-thought except for "shelving" alarms, it took me a while to understand that it was like "stashing" ;-)

Section 3.4, may I assume that the document fixes the problem "X.733 and especially 3GPP were not really clear on this point." ?

Perhaps did I miss the part where the alarm system could also fails: what alarm? status? does it generate? Or is it out of scope?

*minor NITS*
Section 1 s/north-bound/northbound/ ?
Deborah Brungard Former IESG member
Yes
Yes (for -08) Unknown

                            
Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2019-04-11) Sent
Thanks for addressing my DISCUSS.
Alissa Cooper Former IESG member
No Objection
No Objection (2019-04-08 for -08) Sent
Thank you addressing the Gen-ART review.

This sentence in Section 4 does not parse properly: The rest of the data model are made conditional with YANG the features "operator-actions", "alarm-shelving", "alarm-history", "alarm-summary", "alarm-profile", and "severity-assignment".

In 4.1: s/corresponds to the ITU Alarm Report Control functionality/corresponds to the ITU X.733 Alarm Report Control functionality
Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2019-04-08 for -08) Sent
— Section 3.2 —

A nit:
   For example, a system with digital inputs that allows users to
   connects detectors (e.g., smoke detector) to the inputs.

This is a sentence fragment ans also has a number error in “connects”.

NEW
An example is a system with digital inputs that allows users to connect detectors, such as smoke detectors, to the inputs.
END
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2019-04-11) Sent
Thank you for (finding the actual issue in and) resolving my DISCUSS point!
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -08) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -08) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-04-04 for -08) Sent
Minor editorial comment:
Appendix F.2.4.:
"G.7710 is different than the previous referenced alarm standards.  It
   does define a data-model for alarm reporting. "
Is this correct or is there a "not" missing?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -08) Not sent

                            
Magnus Westerlund Former IESG member
Abstain
Abstain (2019-04-11 for -08) Not sent
To me it appear that this document is a part in a system that lacks mechanisms for handling overload situations in a way that maintains goodput in the system. The system design appears to rest on that principle that there will allways be sufficient resources to process and handle the events and that misconfigurations or operator errors do not result in that the system exceeeds the considered load that it was deployed to handle. This alarm module is only a component that from my perspective do require some thought of how alarms that has interactions are reported and with which priority to minimize delay until they can be acted on. However, the general framework appears to lack the necessary hook for such thoughts to be meaningful. Therefore I abstain on this document.