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

Martin Bjorklund <mbj@tail-f.com> Tue, 13 November 2018 09:27 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71A812F1A2 for <ccamp@ietfa.amsl.com>; Tue, 13 Nov 2018 01:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id II_3X8oB3Iyj for <ccamp@ietfa.amsl.com>; Tue, 13 Nov 2018 01:27:53 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CEF5F128D0C for <ccamp@ietf.org>; Tue, 13 Nov 2018 01:27:52 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (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: <20181113.102750.2043470800846273461.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: stefan@wallan.se, ccamp@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <a7f2d666-8a9e-fc9d-cfca-722d258b48f5@ericsson.com>
References: <41cfebeb-0e81-838a-e3e1-9aaac3fea947@ericsson.com> <E8A526FA-19A6-4AC9-B612-CEB2B044EB24@wallan.se> <a7f2d666-8a9e-fc9d-cfca-722d258b48f5@ericsson.com>
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: <https://mailarchive.ietf.org/arch/msg/ccamp/K5S1At5DL-XBCabtTD-BfDLfV7g>
Subject: Re: [CCAMP] Balazs Review of alarm-module-04 / 05
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2018 09:27:55 -0000

Hi,

Balázs Lengyel <balazs.lengyel@ericsson.com>; 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
>     <balazs.lengyel@ericsson.com>; 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