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

Balázs Lengyel <balazs.lengyel@ericsson.com> Wed, 07 November 2018 03:17 UTC

Return-Path: <balazs.lengyel@ericsson.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 458AC126CB6 for <ccamp@ietfa.amsl.com>; Tue, 6 Nov 2018 19:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.068
X-Spam-Level:
X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=WBxwchJz; dkim=pass (1024-bit key) header.d=ericsson.com header.b=AMRhYepA
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 3JRvX2vrxMG4 for <ccamp@ietfa.amsl.com>; Tue, 6 Nov 2018 19:17:21 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2049A127332 for <ccamp@ietf.org>; Tue, 6 Nov 2018 19:17:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541560639; x=1544152639; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lUi5/H7ceobJgnOczGoNjjfGtgItrMH1vJAUEozWHjc=; b=WBxwchJzUQLY4nA6Gshx7TVMR4zU5ZFMcHoR1EoRCpkS3539stWisqwJ++IQlJ+n qC3xRLhPgBHJ9BMOhJgZ9pKIdVaoOu98P8irPKLuCtqNnlsJzH9H/1zyXUABF6qQ lhUbnItpj0GLyvBuXAUtpCueK5jxSq7s+bVsYQ8UVjA=;
X-AuditID: c1b4fb3a-45fff70000002747-29-5be2593ec45f
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.38.10055.E3952EB5; Wed, 7 Nov 2018 04:17:19 +0100 (CET)
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 7 Nov 2018 04:17:18 +0100
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 7 Nov 2018 04:17:18 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XHB2wkWnIhVcYYUVgwHd6cF3uvOykWv8AIPxbYFE/uU=; b=AMRhYepAGxEaOf4xUpiU4aoMBlpidRkVvZdiPuk1cmRKAlFmx0u+Fd+8V5Jsrwyc0fNkVvd+iZjvUH246gaU5yqi4BeV2tKZao4fzvHWyqbyI7Y0sN5RiiuUM2COmf5Wn7sikwg/yHUhIzmdCWfvAa8JoSroLj/6gDeoZyY9P5Y=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2254.eurprd07.prod.outlook.com (10.169.137.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Wed, 7 Nov 2018 03:17:16 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1294.032; Wed, 7 Nov 2018 03:17:16 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
To: stefan vallin <stefan@wallan.se>, "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: [CCAMP] Balazs Review of alarm-module-04 / 05
Thread-Index: AQHUdkhiWcrIu5wDmEK6dJ0KEZfMTA==
Date: Wed, 7 Nov 2018 03:17:16 +0000
Message-ID: <a7f2d666-8a9e-fc9d-cfca-722d258b48f5@ericsson.com>
References: <41cfebeb-0e81-838a-e3e1-9aaac3fea947@ericsson.com> <E8A526FA-19A6-4AC9-B612-CEB2B044EB24@wallan.se>
In-Reply-To: <E8A526FA-19A6-4AC9-B612-CEB2B044EB24@wallan.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [129.192.75.5]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
x-clientproxiedby: SG2PR02CA0049.apcprd02.prod.outlook.com (2603:1096:4:54::13) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2254; 6:36hoiynPuko2s40k6kIyf7ZqDCjcpkx1PkDmE2XOjXOVsno648FaE3lta8Rtw0CjgYuYCrBi9mRtWwFIvKvzsSi/g3Ba+cRQUhhBFi+ix/G6PPonpp+B3PzgxXaAxghIIqFIayGSEWxq6xh0QHALhRgeU16kjjbxYOhWHXPjDZZ0kr4TAXe+qENCF+kSUBsvf9k5I2TKUAtMVHmwLyaX6nUeSOhVl1gW+7y4HsdgGqpPNovmniZp3xRtARLc+g/MBFo5j2VO69JFjqhcoHzOvFtmx7a5qRu43k/KJI4ptofrd8Wt6jYoFOJRf1kN/xBJhRNVRvyAkhJsp1HraOHfUFEYDfmR32OHNOj2TvWkLgtb/O7teZceFlqctWOjbnTXYfx1u7vY+yDK1ppu7vXk9Ae9KwwuxlzTzIbYn0jEPEp8nL8R8nb6pAjb21mbOW2+F/XLDBYsrUNBtW+QZlKcmA==; 5:1JBcDEPMKDify63gjlmhShfG1s7DpaY8ovnVqtxzl7lNFLoEdBNuBnfvhmBaUmh9d2+kk8UPewPdu0Wu8XqZnDPTu+9ntH2eZGwbs1gSbMq/GiUWNhKTMq9DTYPGkZU3wvUyXfvPk8zMVpQqcvyjfU0R6dtA3RhGLANgowPYLfA=; 7:HDrgSVahud6Xrq/tv+r6mdDEHJKjemO88/nlDvFYHqP47Tw6L7opoXwgS87HU8iYYgBKxMr32StNP9Aw3d3DOWbITdnDcQ5d3+QX56Erx4mOXYeOJ8VsFFMgxSwE1cJEW0z+Drm0czr0l95PdLKt0w==
x-ms-office365-filtering-correlation-id: f77e0a4a-5716-4d5f-7d9e-08d6445f83c3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2254;
x-ms-traffictypediagnostic: VI1PR0701MB2254:
x-microsoft-antispam-prvs: <VI1PR0701MB2254668E67680A55A6DE30DAF0C40@VI1PR0701MB2254.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(248295561703944)(37575265505322)(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(4983020)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2254; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2254;
x-forefront-prvs: 08497C3D99
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(396003)(136003)(39860400002)(51914003)(252514010)(199004)(189003)(66574009)(36756003)(2616005)(446003)(476003)(486006)(2501003)(11346002)(66066001)(65806001)(65956001)(26005)(236005)(6436002)(3260700006)(229853002)(25786009)(8936002)(6486002)(81156014)(81166006)(53936002)(58126008)(110136005)(102836004)(6512007)(5660300001)(6246003)(316002)(54896002)(6306002)(8676002)(186003)(65826007)(31686004)(76176011)(64126003)(52116002)(68736007)(2906002)(966005)(99936001)(6506007)(386003)(105586002)(53546011)(97736004)(99286004)(86362001)(478600001)(85202003)(106356001)(71200400001)(85182001)(14454004)(7736002)(71190400001)(256004)(606006)(6116002)(14444005)(31696002)(3846002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2254; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: FHvXnQ2Ot2AXPo0z/3WuYeX73q99qz847Y3qRTPv5VxzjtTPC1rPILzjNWgnwN0giMEH1m2jnrJZnNY0O4D3XvizSZrssiIbHnBA9wmQE6DCLwXNFSf27S82+axuL0Rcz/cz8p1XWgdrVD48bGsUgRTwTVnYEm41FJqcVsP7OelpVDZ6v1yUwe+72iM62I6E2ZbjvMtUEubqz0eH5EOw12DiBII4lpJVmCJctTgng6ad8O0WEZJ5BW5LxcyPI0ZiEFRgiJVEJZNylE6SapahLJoqkDe4NdtokIoza9Bvbi/d3FMj08ypuZA/vOq5LGK0dO2GllNl1M+kec6vGB3KPnd6qq2dcklEYcQYEVMqt+I=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070806070603080901090108"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f77e0a4a-5716-4d5f-7d9e-08d6445f83c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2018 03:17:16.6632 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2254
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTYRjG+845m8fl4GtpvtmFGlbgNe2CpKlJFwuKiihTK2cdL6lTdpZl BXnBNM1YEtamps1aF8MboglabSalMzQtHJY55yVMzPwjxMxq25lQ//2e532fh/c7HJoUfeS5 0PFSOSOTShLFfAGlDGuUewYdN0VsnCxFfiMlBsqvs/g9CiZC79+fJUKnJtPRQSJcEHCGSYxP ZWTegVGCuKanNWSKSn5BX1DLS0cfovKQPQ14M0w/b0B5SECL8CsERcNZfE78QGD8c4fkRAUB GqPaKiisIOGX/qUdN7lNwN3sPooTJgRdrWU8SzMf74Scby8ICzviPZD/vd7KS/E2uNVv5HG+ Pzzpf4g49oKs7nLSwhR2BdMng3VHiINgNENj9UVYBq+NjXwL2+PtMPSt2NqJ8DKY6XhqZRI7 Q/9IGcG9zhGG3un5HDvB+PBvHsdroEWhNPs07YRPgDYzyHI/4CIEU4oSxHWehObPubasB7zt G0Ecr4KesnzEBQx8KBmvtpXuh/6uAdugF0G6dpBcSOvUd21LyWAcU9v8SKhoH0UK5KP653CV OU/iawiuD1STKusXWALtyhFKZb6WxOtBky3+f9/C7qC5N0Fy7A93fmr5HK+FW/lDdhxvgYm2 acTxJtBUzfPLkeAJcmIZlk2K9fX1YmTxp1k2WeolZeR1yPybaevntj1D2i87dAjTSOwgNASb IkQ8SSqblqRDruYeU01lN3KhpMlSRuwo1FcORYiEZyRpFxlZ8inZuUSG1aEVNCV2FobE+IWL cKxEziQwTAojW5gStL1LOlqZvTin5cD+rJCA4N6E4dnetjm/ys6ZuZttgW7eofMdkgetaccO uRX71k2UNh/tGayNDFMQpd4ei/qUBVvHjsTAoysbjIVxUcvdcqNfr4t/03R1l7joxr69XwvV 86sbtAVK1/O7q2qdCx7rMz11nWHhDhmG74dbz14+UjU37h4SLbwkptg4iY8bKWMlfwFzNPiW bgMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/Z0uerp6T9BY8A37YnLjzw1FgI-s>
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: Wed, 07 Nov 2018 03:17:24 -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 <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" class="" rel="nofollow">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/" rel="nofollow">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