Ballot for draft-ietf-ccamp-alarm-module
Yes
No Objection
Abstain
Note: This ballot was opened for revision 08 and is now closed.
Thank you for iterating to resolve my DISCUSSes and address my comments
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.
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/ ?
Thanks for addressing my DISCUSS.
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
— 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
Thank you for (finding the actual issue in and) resolving my DISCUSS point!
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?
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.