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

From: Balázs Lengyel <[email-masked]>
Date: Wed, 7 Nov 2018 03:17:16 +0000

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 <[email-masked]>
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/

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?

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.

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?

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.

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Nov 2018 10:27:50 +0100 (CET)

Hi,

Balázs Lengyel <[email-masked]> 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
>     <[email-masked]> wrote:
> 
> 
>         Hello,
> 
>         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
> 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.

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
>         • It makes setting up access control simpler. As the access
>         • 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.
>     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
>         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.
> 
> 
> 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

---

From: stefan vallin <[email-masked]>
Date: Thu, 22 Nov 2018 15:56:31 +0100

Hi Balazs!
See 06, we have addressed your points
- actions instead of RPCs
- a new time-stamp for raise

br Stefan

> On 7 Nov 2018, at 04:17, Balázs Lengyel <[email-masked]> 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 12 Oct 2018, at 15:52, Balázs Lengyel <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hello,
>>> 
>>> The draft https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-04 <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/ <https://tools.ietf.org/wg/netmod/draft-ietf-netmod-yang-instance-file-format/>
>>> 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.
>> 
>> How RPCs are presented in a CLI is a totally different thing though, that is up to the CLI engine
> 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?
>> 
>>> 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.
> 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. 
> 
>>> 
>>> 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? 
> 
> 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.
> 
> -- 
> Mobile: +36-70-330-7909              email: [email-masked] <mailto:[email-masked]>