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

Martin Bjorklund <> Tue, 13 November 2018 09:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E71A812F1A2 for <>; Tue, 13 Nov 2018 01:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id II_3X8oB3Iyj for <>; Tue, 13 Nov 2018 01:27:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CEF5F128D0C for <>; Tue, 13 Nov 2018 01:27:52 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 4C7A51AE018C; Tue, 13 Nov 2018 10:27:51 +0100 (CET)
Date: Tue, 13 Nov 2018 10:27:50 +0100 (CET)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <>
Subject: Re: [CCAMP] Balazs Review of alarm-module-04 / 05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Nov 2018 09:27:55 -0000


Balázs Lengyel <> 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
>     <> wrote:
>         Hello,
>         I have reviewed draft-ietf-ccamp-alarm-module-04 and 05
>         General:
>         The draft
>        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

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

>         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:



>         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.