Re: [CCAMP] Balazs Review of alarm-module-04 / 05

[Martin Bjorklund <[e-mail]>]

Hi,

Balázs Lengyel <[e-mail]> wrote:
> Hello,
> 
> Thanks for the updates. Generally the draft is in a good condition,
> still I would like you to reconsider the point commented below.
> 
> regards Balazs
> 
> On 2018. 10. 22. 19:14, stefan vallin wrote:
> 
>     On 12 Oct 2018, at 15:52, Balázs Lengyel
>     <[e-mail]> wrote:
> 
> 
>         Hello,
> 
>         I have reviewed draft-ietf-ccamp-alarm-module-04 and 05
> 
>         General:
>         The draft
>         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.
> 
> 
> BALAZS: You did not add this informative reference. Why? E.g. for my
> company this is one of the main use cases for using instance data.
> The draft was lately adopted by the Netmod workgroup as
> https://tools.ietf.org/wg/netmod/draft-ietf-netmod-yang-instance-file-format/

Ok.  I suggest we add a paragraph to section 4.2:

   A server implementer may want to document the alarm inventory for
   off-line processing by clients.  The file format defined in
   [I-D.ietf-netmod-yang-instance-file-format] can be used for this
   purpose.

>         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.
> 
> 
>     We see your point, actions vs rpc can always be discussed.
>     How RPCs are presented in a CLI is a totally different thing
>     though, that is up to the CLI engine
>     However, we prefer to keep these as RPCs at this point.
> 
> BALAZS: IMHO all 3 above points are valid. You only addressed the last
> one, and even there some of the main CLI implementations list RPCs in
> just one common flat list beside yang data nodes. IMHO while CLI is
> not standardized, still why make it more difficult for implementers?

Ok, I agree that actions are a better fit for the operations defined
in this document.  Unless someone objects, we will make these changes.

The purge and compress rpcs will be actions:

 /alarms/alarm-list/compress-alarms
                    purge-alarms

 /alarms/shelved-alarm-list/compress-shelved-alarms
                            purge-shelved-alarms


>         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.
> 
> 
>     This can be done by inspecting:
>     +--ro status-change* [time]
>     +--ro time yang:date-and-time
>     +--ro perceived-severity severity-with-clear
>     +--ro alarm-text alarm-text
> 
> BALAZS: You are right, but again the primary information should be in
> the alarm-list. When the alarm entry was created is not very
> interesting while the time when the alarm was last "raised" (changed
> to isCleared=false) is the primary date/time information. In case the
> alarm was raised/cleared/raised/cleared multiple times the
> time-created is really unimportant. time-raised should be used
> instead.
> 
> Generally for all type of information the important event is when the
> alarm was raised (the last time) not when it was created (the first
> time).
> 
> Also IMHO the terminology "raise alarm" is IMHO rather useful and
> widely used.

Ok, see your point, this is useful information.  We will add this.

> 
> 
> 
> 
>         Appendix F.1)
> 
>         Clarify whether this annex is normative or informative. To me
>         this seems, this should be normative text.
> 
> 
>     This is informative
> 
> BALAZS: Why should it be only informative? It seems as rather natural,
> and rather logical idea. Why would we allow an implementation to
> violate this?

You're right.  I have moved F.1 to its own section (a new section 5).


> Anyway IMHO normative/informative should be indicated somewhere. Some
> standards (maybe not IETF) do use normative appendices. Should this be
> trivial for the reader? For some appendices where you have "example"
> in the title this is trivial, but for others, at least for me it is
> not.



/martin