A YANG Data Model for Alarm Management
RFC 8632

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

(Deborah Brungard) Yes

(Ignas Bagdonas) No Objection

(Alissa Cooper) No Objection

Comment (2019-04-08 for -08)
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

Roman Danyliw (was Discuss) No Objection

Comment (2019-04-25)
No email
send info
Thank you for iterating to resolve my DISCUSSes and address my comments

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-04-11)
Thank you for (finding the actual issue in and) resolving my DISCUSS point!

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-04-08 for -08)
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 ..."

"For example, a system with digital inputs that allows users to connects detectors"
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.

(Mirja Kühlewind) No Objection

Comment (2019-04-04 for -08)
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?

(Barry Leiba) No Objection

Comment (2019-04-08 for -08)
— 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”.

An example is a system with digital inputs that allows users to connect detectors, such as smoke detectors, to the inputs.

Alvaro Retana No Objection

(Adam Roach) (was Discuss) No Objection

Comment (2019-04-11)
Thanks for addressing my DISCUSS.

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-04-06 for -08)
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/ ?

(Magnus Westerlund) Abstain

Comment (2019-04-11 for -08)
No email
send info
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.