[CCAMP] comments for draft-ietf-ccamp-alarm-module-06

"Xiajinwei (Jinwei Xia, Network)" <xiajinwei@huawei.com> Fri, 28 December 2018 02:31 UTC

Return-Path: <xiajinwei@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E9134130F1D for <ccamp@ietfa.amsl.com>; Thu, 27 Dec 2018 18:31:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PO_cC9hvfutW for <ccamp@ietfa.amsl.com>; Thu, 27 Dec 2018 18:30:59 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com []) (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 9658B130F1B for <ccamp@ietf.org>; Thu, 27 Dec 2018 18:30:59 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id EF1664985B6D1 for <ccamp@ietf.org>; Fri, 28 Dec 2018 02:30:54 +0000 (GMT)
Received: from lhreml709-chm.china.huawei.com ( by LHREML711-CAH.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Dec 2018 02:30:56 +0000
Received: from lhreml709-chm.china.huawei.com ( by lhreml709-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 28 Dec 2018 02:30:56 +0000
Received: from NKGEML414-HUB.china.huawei.com ( by lhreml709-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Fri, 28 Dec 2018 02:30:56 +0000
Received: from NKGEML513-MBX.china.huawei.com ([]) by nkgeml414-hub.china.huawei.com ([]) with mapi id 14.03.0415.000; Fri, 28 Dec 2018 10:30:47 +0800
From: "Xiajinwei (Jinwei Xia, Network)" <xiajinwei@huawei.com>
To: "ccamp@ietf.org" <ccamp@ietf.org>
CC: Wangyonglong <wangyonglong@huawei.com>
Thread-Topic: comments for draft-ietf-ccamp-alarm-module-06
Thread-Index: AdSeVVWrxh+ixLCiQXSkPaWDjejFlw==
Date: Fri, 28 Dec 2018 02:30:47 +0000
Message-ID: <A8219E7785257C47B75B6DCE682F8D2FA645AFA9@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A8219E7785257C47B75B6DCE682F8D2FA645AFA9nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/yggkMCZqzE4At-_TJXjkHRQBAgk>
Subject: [CCAMP] comments for draft-ietf-ccamp-alarm-module-06
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: Fri, 28 Dec 2018 02:31:02 -0000

Dear editors,

As a new comer of CCAMP, I am happy with the good progress of the YANG alarm module and definitely support it.

Since I am working on the alarm design, I have a few comments on this draft:

1, the draft identifies the alarm-type via the combination of alarm-type-id and alarm-type-qualifier. We fully like that, by the way, would we add one complemented and optional leaf, e.g., alarm-name (R-LOS), to briefly indicate the alarm type? While the corresponding alarm-text shows the comprehensive information about this alarm, e.g., the signal is lost on the receiver side.

2, for the alarm instance, the draft uses the triple-keys (resource, alarm-type-id and alarm-type-qualifier) to identify it. From my point of view, the design is great. Besides of the triple-keys identification in our design, we also add a complemented and optional alarm-serial-no leaf to do the same work. An alarm-serial-no is unique to identity one alarm instance, and thus the OSS can locate an alarm via the alarm-serial-no directly and save the time to map the triple-keys one by one. Does it make any sense?

3, for the alarm-type-id, could it be possible to support a union of identity and string? Currently, we have more or less 40000 alarm types in our implementation and the number is still rising right now. The YANG alarm module is still a huge volume when we build our own alarm-type augment.

4, in alarm notification message, the severity information is great to let operator know the alarm state (i.e., cleared, raised and changed). We like that, but it'd be better if there was a definite alarm-category leaf to indicate the brief alarm state regardless of the severity, any thoughts?

Sorry for bringing any inconvenience of the late comments on the WGLC stage. Your feedbacks are very helpful for us :)

Merry Christmas and Happy New Year!