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

stefan vallin <stefan@wallan.se> Thu, 22 November 2018 14:56 UTC

Return-Path: <stefan@wallan.se>
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 828AE130E34 for <ccamp@ietfa.amsl.com>; Thu, 22 Nov 2018 06:56:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.357
X-Spam-Level:
X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wallan-se.20150623.gappssmtp.com
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 CiLzCdfyucjX for <ccamp@ietfa.amsl.com>; Thu, 22 Nov 2018 06:56:36 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7EA130DC0 for <ccamp@ietf.org>; Thu, 22 Nov 2018 06:56:35 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id l15-v6so8219265lja.9 for <ccamp@ietf.org>; Thu, 22 Nov 2018 06:56:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=gUW/RJQ4afYQvnt6f8hww3pyf51qunCfHfiN9lLYS4o=; b=k+BlJc4lBm0TItVEZ+IWguWU89vi8YuV8WVdoZ1dOAXI9FzHcBP13lWnUMiWttng9j q9fFAA8SI/IjRsvlg6AK4VoDBqtsqGCpHoZWXUFVkF+QPSdUV2iCO3Mu9Zk8qyhJApjo nF3tb8GsmMKPbbcYr3rcWf0R4TLX6E96FtIOtxhZtpUhjIDn3+uUUYT+mqK9VZknanI6 wF3U2pxZm09IzcXjbYRqlsCl5Y2VSLyL/VLBLZtVyfL9hi7xLQ6DkWdQZ8dhLKqcbfb9 6wSCrFTY6JvlPn+uFUvbtaUDsYTLlosLGbCzfVcxrqBxlAqJ8R9JSwkRYcaAM6u2bsgq 8Agw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=gUW/RJQ4afYQvnt6f8hww3pyf51qunCfHfiN9lLYS4o=; b=ey7pqcwO8dY2kxt4VRxMkwmFIgJa2BCNx8pnBUX6lZEkrjZ7xMIzUdQGI9/wOhD/1G F9XQwBHVxxa0CVwrOyDcjMOR5Lgu7tnfBSGaT+ORASeV+OHjAZCdP2gaPfTeI2F9ynRe abIRohKeVnjfaf5QT5i9SX+F9AYAbMNBBxWK4KpVcZiCbivOLacjwnJkxbIl2j5zlWFs PSwRLl2JQS6AEhXbjB51MbfnDRfwcUYaoXGVLHR599sDE0BXrlYJuYvO56kCsZctnzBd TWTiT6Ac11eyXhU97Xclw3oUoN7F/rvSTBj0wssoEApEWN2YRsFDVXcyzA64dkqpwkDK MA2A==
X-Gm-Message-State: AA+aEWYzzouxffBLwAev8wkkH+prTwKGmGvJbCPqVrcVnBe9MxAdt2j+ W9ju5uGzs7UPN1a6ym9rlegGbw==
X-Google-Smtp-Source: AFSGD/XKZ6FsRsj+atVDxjJjVAHb1Bj1jmMFVBIvjSm8EckWgolBYd693TiWvZ0wT0K+iXWc2B8gpw==
X-Received: by 2002:a2e:7011:: with SMTP id l17-v6mr2083956ljc.147.1542898593675; Thu, 22 Nov 2018 06:56:33 -0800 (PST)
Received: from [10.0.155.202] ([195.22.87.57]) by smtp.gmail.com with ESMTPSA id d19-v6sm7283704ljc.37.2018.11.22.06.56.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 06:56:33 -0800 (PST)
From: stefan vallin <stefan@wallan.se>
Message-Id: <CD8F1007-4B76-4ED4-B47F-958EDC645005@wallan.se>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D500B4D6-656D-4D34-BFCC-05959CFE674E"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 22 Nov 2018 15:56:31 +0100
In-Reply-To: <a7f2d666-8a9e-fc9d-cfca-722d258b48f5@ericsson.com>
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
To: Balázs Lengyel <balazs.lengyel@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: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/VzISmoTNKOIEUK2rKokfj58_G0E>
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: Thu, 22 Nov 2018 14:56:39 -0000

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 <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 <mailto: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 <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.
>> 
>> 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: Balazs.Lengyel@ericsson.com <mailto:Balazs.Lengyel@ericsson.com>