[CCAMP] Balazs Review of alarm-module-04

[Balázs Lengyel <[e-mail]>]

Hello,

I have reviewed draft-ietf-ccamp-alarm-module-04

General:

IMHO the draft is in a fairly good shape.

The draft https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-04" rel="nofollow">https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-04 describes how to document YANG instance data. One of the main use case for documenting YANG instance data in a file is to provide information about the YANG server's capabilities. The alarm-inventory is exactly such a set of server capabilities that could, that SHOULD be documented in a YANG Instance Data file already in design-time to help users integrate management systems. The draft is in the process of being adopted by the Netmod WG.

It should be mentioned somewhere that a cleared alarm can be raised again thus become is-cleared=false; potentially many times during its life.

IMHO the counters defined are not the best. For me the two most important statistics would be:

1. How many active (is-cleared=false) alarms do I have in my system?   total-not-cleared This could be added both to the list alarm and the list alarm-summary. I know this can be derived from the total minus total-cleared but I feel that this is the primary information, so this should be available just by a read operation without any maths.
   
2. How many alarms did my system generate in the last hour/day/week ?   total-raised, this should be a yang:counter32 that increments whenever a new alarm is added or set to is-cleared=false. (types, severity, shelving could be considered)
   

We have neither counter in the module.

I would generally prefer using YANG actions instead of rpcs. I would place all RPCs as actions under the /alarms container.

• These are not general system-wide operations, they are specific to alarm-handling. They belong under /alarms
• It makes setting up access control simpler. As the access control for the /alarms container already controls access to the RPCs too. Otherwise you need separate rules for each RPC.
• On a CLI if you ask for help, all top level RPCs are listed as options. If there are many RPCs the list gets really long. With actions you do not have this problem.
  

4.4) I don't understand the first sentence.

5)

type resource)

• required-instance false; Is not needed as that is the default meaning for instance-identifiers. Specifying default statements is not recommended by RFC6087bis
• IMHO Distinguished names are more common then UUIDs. I would list them as more preferred then UUIDs.
  

typedef resource-match) The following two lines are redundant and contradictory (choose one :-)   )

• The function library is the core function library and the functions defined in https://tools.ietf.org/html/rfc7950#section-10" rel="nofollow">Section 10 of RFC 7950.
  
• The function library is the core function library

• The context node is the root node in the data tree. 
  AFAIK YANG has many root nodes. Please clarify.

list-alarm)

I am missing a leaf: time-alarm-raised.  As an alarm can be raised then cleared, then raised again I have no way of knowing when the current alarm condition started. If an interface is down I can't check how long has it been down. We have the leaf time-created, however if the alarm is repeatedly raised/cleared/raised but never purged this leaf will tell me when this alarm was first raised in the history of the system, which is not very interesting.

container shelved-alarms)

alarm-shelf-last-changed) The name of the leaf seems to indicate that this refers to the time when one specific alarm-shelf changed. However as I understand this is the time when any of the shelves changed. Please clarify / rename

list alarm-profile)

Why is this user-ordered ? I see no meaning of the order.

rpc compress-alarms)  leaf resource) IMHO this could be of type resource-match

6)  module-description)

Mention that shelved-alarms are also augmented

Appendix F.1)

Clarify whether this annex is normative or informative. To me this seems, this should be normative text.

regards Balazs

P.S. Please send any replies to me personally too as I am not always reading the cccamp list.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]