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: Balázs Lengyel <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, 07 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 12 Oct 2018, at 15:52, Balázs Lengyel <balazs.lengyel@ericsson.com> wrote: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.
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.
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/
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?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 engineHowever, we prefer to keep these as RPCs at this point.
list-alarm)This can be done by inspecting:
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.
+--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.
This is informative
Appendix F.1)
Clarify whether this annex is normative or informative. To me this seems, this should be normative text.
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
- [CCAMP] Balazs Review of alarm-module-04 Balázs Lengyel
- Re: [CCAMP] Balazs Review of alarm-module-04 stefan vallin
- Re: [CCAMP] Balazs Review of alarm-module-04 / 05 Balázs Lengyel
- Re: [CCAMP] Balazs Review of alarm-module-04 / 05 Martin Bjorklund
- Re: [CCAMP] Balazs Review of alarm-module-04 / 05 stefan vallin
- [CCAMP] Review of alarm-module-06 Beauville, Yves (Nokia - BE/Antwerp)
- Re: [CCAMP] Review of alarm-module-06 stefan vallin