[CCAMP] Roman Danyliw's Discuss on draft-ietf-ccamp-alarm-module-08: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-ccamp-alarm-module-08: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 3.5, Alarm Life-Cycle.  The text states that “A server SHOULD
describe how long it retains cleared/closed alarms: until manually purged or if
it has an automatic removal policy.” How is this retention policy described? 
Is that in scope for this document?

(2) Section 4.2, Alarm Inventory.  The text states that “A server MUST
implement the alarm inventory in order to enable controlled alarm procedures in
the client.” What is the expected server behavior if a client sends an alarm
type not in the inventory (and it isn’t part of the dynamic addition process)?

(2) Section 10, Security Considerations.  It seems like
“/alarms/alarm-list/alarm/set-operator-state” should be listed as an operation
in the YANG model that presents a security issues (just like “purge-alarms”). 
Consider if one altered the operator alert state causing the alarm management
procedures to miss an alert (e.g., setting an alert to “closed” before any
action is taken).

(3) Section 10, Security Considerations.  I don’t know must about the
implementations, but wouldn’t compressing alerts (per compress-alarms and
compress-shelved-alarms operations) remove them from consideration by alarm
management procedures?  If so, these would be a sensitive operation that would
need to be listed as the concern equivalent to the current text for
purge-alarms.


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

(1) Section 1.1, Terminology, “Fault”.  Consider expanding the acronym “MOS”
(Mean Option Score?)

(2) Section 2, Objectives, Consider s/X.733/[X.733]/

(3) Section 3.2, Alarm Type, Consider s/identity based/identity-based/

(4) Section 3.2, Alarm Type, Typo, s/standard organization/standards
organization/

(5) Section 3.4, Identifying Alarm Instances, Consider s/were not really
clear/were not clear/

(6) Section 3.5.2, Operator Alarm Life-cycle, Consider s/can also act upon/act
upon/

(7) Section 3.5.2, Operator Alarm Life-cycle, Consider s/A closed alarm is an
alarm/For example, a closed alarm is an alarm/

(8) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider
s/Different systems have various various/Different systems have varying/

(9) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider
s/In some occasions/On some occasions/

(10) Section 3.6, Root Cause, Impacted Resources and Related Alarms, Consider
s/needs to represent an alarm that indicates a situation that needs acting
upon/raises an alarm to indicate a situation requiring attention/

(11) Section 4.1.1, Alarm Shelving, The text states “The instrumentation MUST
move shelved alarms from the alarm list (/alarms/alarm-list) to the shelved
alarm list (/alarms/shelved-alarms/).”  It wasn’t clear when these shelved
alarms must be moved given the text.

(12) Section 4.4, The Alarm List, The sentence, “The alarm list
(/alarms/alarm-list) is a function from (resource, alarm type, alarm type
qualifier) to the current composite alarm state” is missing a word/phrase. 
Removing the parenthetical remarks it reads a “The alarm list is a function
from to the current composite alarm state” is does not parse.

(13) Consider s/Life-cycle/Lifecycle/g