Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01

stefan vallin <stefan@wallan.se> Sat, 11 August 2018 17:58 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 CA04513104D for <ccamp@ietfa.amsl.com>; Sat, 11 Aug 2018 10:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, 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 Xq8secELtNbd for <ccamp@ietfa.amsl.com>; Sat, 11 Aug 2018 10:58:51 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 EBA69130E5C for <ccamp@ietf.org>; Sat, 11 Aug 2018 10:58:50 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id a4-v6so8666975lff.5 for <ccamp@ietf.org>; Sat, 11 Aug 2018 10:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5mihflsYABx7JYCeSZyuIYJ4a4f9GqwaBZk2P+uGR7U=; b=0ScNdeX9Lwj5P8GQx8v/Y0fmy+dPEU7nh30aHb8y9FRDnt2z9PzpNrLl4IW0Np1ebz PwMpDM9vH6fiA1aoV852YwwXspd7cgh3uhIUMnCawZI8h6KVbjxXYzeKrC5cKITmw+II AeEJ2mU/vr33aZR1sgkJaNHBT7YCPnnPcoFBGWreF1QUVwqwIWwtXU0yrIctGXufnM0a hTWFoF1XPTxziA8pOGra418GzDXdKFe4f9ouxC3j1KACSsUR2Fh9rdJNuXaCQFQbrG3z BnzkvQPHK0jVXDpKlyW/wW5ssoDwZ5yx/Zq0V4u2JbpMIOW1KaIN+aXojx83lqkQqCo1 AsVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5mihflsYABx7JYCeSZyuIYJ4a4f9GqwaBZk2P+uGR7U=; b=WZLUTxnzmDploVxNfDEFlqdk0ujtBNBmaV+1+CaSVhc73pA88lSWfbA8jO2t3AlBdy S58Xz9Ok1u7vN+U9IFn8lw2bmlJvQe9yaAF4z/tyjNAcdUEhE0nt7JEH0qls663HN+Dl 7GeyapWVyvKh/An0KltWU//dkRkUMdnqmHDw0WK3C3i2F9V+yAGgSUi2Iqhr0+eBBmTm drtKESeSGQss3bEc77nz3Ee2HuulmCXIQ5vwpkrbUFBVvGG588JgrM8lLUoqXljaGqOQ 6JXIxakkbq6ArZ8fAsFLqcHoBhanNn3kaRmgF++CZQp7PF88YNnohTAILCZ9pe1U+FG+ wUVg==
X-Gm-Message-State: AOUpUlFBnwOEiV4u6aAhr/a7UMMsWkaX4KZFXPBhgEW8TB16X/aG9Vl+ 7Q5iEsJ1WmMHsiDHwiWRDpNM4c2FuPg=
X-Google-Smtp-Source: AA+uWPyUy9FWGliYIz653DzgIe1dC1wcqckBcOPueqt+fEh3OLNDYF8m9XTsd4OYJK8dHnB55MtJ2g==
X-Received: by 2002:a19:fc3:: with SMTP id 64-v6mr7274709lfp.46.1534010329259; Sat, 11 Aug 2018 10:58:49 -0700 (PDT)
Received: from [192.168.72.11] (h95-155-237-105.cust.se.alltele.net. [95.155.237.105]) by smtp.gmail.com with ESMTPSA id a27-v6sm2407900lfk.85.2018.08.11.10.58.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Aug 2018 10:58:48 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: stefan vallin <stefan@wallan.se>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C8883C6BA0@MISOUT7MSGUSRDE.ITServices.sbc.com>
Date: Sat, 11 Aug 2018 19:58:47 +0200
Cc: tom petch <ietfc@btconnect.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D5AF6A0-84FC-49AD-932C-F05056D20FE1@wallan.se>
References: <B8F9A780D330094D99AF023C5877DABA9AF5BDE8@nkgeml513-mbx.china.huawei.com> <E597E310-27B8-4091-89BB-F510CE1AC3C0@wallan.se> <04c501d430a0$3c5cc3c0$4001a8c0@gateway.2wire.net> <F64C10EAA68C8044B33656FA214632C8883C6BA0@MISOUT7MSGUSRDE.ITServices.sbc.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/tgEcZyY9nf7Z36Q_ORcbEbBA7WY>
Subject: Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.27
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: Sat, 11 Aug 2018 17:58:54 -0000

Hi Deborah!

> On 10 Aug 2018, at 21:17, BRUNGARD, DEBORAH A <db3546@att.com> wrote:
> 
> Stefan, Authors,
> 
> I've been reviewing the SG15 liaison and your draft, as we'll need to respond in about a month to SG15. Similar to Tom, SG15 is confused on terms of reference/prior standards relationship. While the abstract says "carefully maps to relevant alarm standards", there's no direct references. In the document, it also has a sentence "based on experience from using and implementing available alarm standards". So it is not clear if this work is based on standards or "experience implementing‚ÄĚ.
Both :)
Have you read Appendix F?
> 
> During the microwave yang review, a similar concern was raised, and it was decided to clearly identify which standard is being referenced. Recommend the same should be done here. It's ok you have included "vendor implementations of alarm standards". But you need to clearly identify.
Appendix F and references
> 
> There's a sentence in the abstract of draft-ietf-netmod-intf-ext-yang which may help here:
> "These properties are common to many types of interfaces on network routers and switches and are implemented by multiple network equipment vendors with similar semantics, even though some of the features are not formally defined in any published standard."
> And:
> " Several of the augmentations defined here are not backed by any formal standard specification.  Instead, they are for features that are commonly implemented in equivalent ways by multiple independent network equipment vendors.  The aim of this draft is to define common paths and leaves for the configuration of these equivalent features in a uniform way, making it easier for users of the YANG model to access these features in a vendor independent way.  Where necessary, a description of the expected behavior is also provided with the aim of ensuring vendors implementations are consistent with the specified behaviour."
> 
> Similar to the intf-ext, it will be important to allow implementors the flexibility to choose which specific parts of the model they support, and to allow in the future supporting other standards (G.7710). It would help to include a few sentences in the draft on how this can be done.
Please read previous emails in this group with regards to G.7710, I have commented this earlier
> 
> Once we have a cleaner document,
?
> I'm recommending to liaison with the SDOs which you reference, ITU-T, 3GPP (and BBF in response to their earlier liaison). Hopefully with these clarifications, it will be an easier read by these other groups.
Can you be more specific?
If you are expecting this draft to be a syntactical mapping ot X.733 GDMO/ASN.1 or the 3GPP Alarm IRP?
We need to improve, need to make progress and learn from experience.

> 
> Thanks Tom and Qin for reviewing -
> 
> Thanks Authors for continuing the dialogue- as with any solution document, the solution stabilizes, then need to clean up the description textūüėä  
Clean up? Can you be more specific?

Br Stefan

> 
> Deborah
> (AD hat on)
> 
> -----Original Message-----
> From: CCAMP <ccamp-bounces@ietf.org> On Behalf Of tom petch
> Sent: Friday, August 10, 2018 7:53 AM
> To: stefan vallin <stefan@wallan.se>
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] review of draft-ietf-ccamp-alarm-module-01
> 
> Stefan
> 
> I find this I-D (too) hard to understand.  The problem I have is with terminology which seems elastic.
> 
> Thus 'alarm state' is not defined as a term; it is in other alarm work where the definition would fit with usage such as
> 
>   The operator state for an alarm can be: "none", "ack", "shelved", and
>   "closed".
> or
> actual state of the alarms
> or
> The alarm list (/alarms/alarm-list) is a function from (resource,
>   alarm type, alarm type qualifier) to the current alarm state.
> 
> But this meaning makes no sense to me when the term appears in o  Alarm Instance: The alarm state for a specific resource and alarm type.
> or
> o  Alarm Type: An alarm type identifies a possible unique alarm state for a resource.
> 
> and since I cannot understand what you mean by these two terms, I think I cannot understand the document.
> 
> Another example would be the use of 'event' which appears as
> 
> 1.  the definition focuses on leaving out events and logging information in general.
> 
> This I-D does not define event; previous IETF work, e.g. RFC3877 does, and makes it clear that an alarm (class) is a subset of an event which would make no sense here.
> 
> There is a lot of prior art in this field but this I-D seems to go against it rather than build on it.
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "stefan vallin" <stefan@wallan.se>
> To: "Qin Wu" <bill.wu@huawei.com>
> Cc: <ccamp@ietf.org>
> Sent: Sunday, July 22, 2018 7:17 PM
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ccamp&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=Y7lL8No91BQpMMGov6O09yRy9kNBr_oUgXbkmXjLjqk&s=CtnVif0mRNx46GxoPzbqh7OUVBXlusn7itCGGygX-q4&e=