Re: [CCAMP] Éric Vyncke's No Objection on draft-ietf-ccamp-alarm-module-08: (with COMMENT)

Martin Bjorklund <mbj@tail-f.com> Mon, 08 April 2019 12:30 UTC

Return-Path: <mbj@tail-f.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 16422120304; Mon, 8 Apr 2019 05:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 7O4tHrrsA4Mv; Mon, 8 Apr 2019 05:30:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1991203E2; Mon, 8 Apr 2019 05:30:48 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 596A91AE02BD; Mon, 8 Apr 2019 14:30:46 +0200 (CEST)
Date: Mon, 08 Apr 2019 14:30:48 +0200 (CEST)
Message-Id: <20190408.143048.828902860084182982.mbj@tail-f.com>
To: evyncke@cisco.com
Cc: noreply@ietf.org, iesg@ietf.org, draft-ietf-ccamp-alarm-module@ietf.org, daniele.ceccarelli@ericsson.com, ccamp-chairs@ietf.org, ccamp@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <12AEB78F-C3D9-4052-BD32-1F6962A63FFE@cisco.com>
References: <155458648675.21847.15882795962444550355.idtracker@ietfa.amsl.com> <20190408.135441.1084919238498793699.mbj@tail-f.com> <12AEB78F-C3D9-4052-BD32-1F6962A63FFE@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/q7EPN4YHftUakhJcRsBrhr7NNG0>
Subject: Re: [CCAMP] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-i?= =?iso-8859-1?q?etf-ccamp-alarm-module-08=3A_=28with_COMMENT=29?=
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: Mon, 08 Apr 2019 12:30:55 -0000

"Eric Vyncke (evyncke)" <evyncke@cisco.com>; wrote:
> Martin and Stefan,
> 
> Thank you for your answer.
> 
> If a new rev is required, then may I suggest to clarify the text
> around the first 2 points that I raised?

See inline.



> 
> -éric
> 
> On 08/04/2019, 13:54, "Martin Bjorklund" <mbj@tail-f.com>; wrote:
> 
>     Hi,
>     
>     Éric Vyncke via Datatracker <noreply@ietf.org>; wrote:
>     > Éric Vyncke has entered the following ballot position for
>     > draft-ietf-ccamp-alarm-module-08: No Objection
>     > 
>     > When responding, please keep the subject line intact and reply to all
>     > email addresses included in the To and CC lines. (Feel free to cut this
>     > introductory paragraph, however.)
>     > 
>     > 
>     > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>     > for more information about IESG DISCUSS and COMMENT positions.
>     > 
>     > 
>     > The document, along with other ballot positions, can be found here:
>     > https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/
>     > 
>     > 
>     > 
>     > ----------------------------------------------------------------------
>     > COMMENT:
>     > ----------------------------------------------------------------------
>     > 
>     > Easy to read and well-thought except for "shelving" alarms, it took me a while
>     > to understand that it was like "stashing" ;-)
>     
>     This term was discussed by the WG, but since it is commonly used in
>     the alarm industry, we kept it.

How can we clarify the text around this?  I'm not convinced that
introducing the term "stashing" as well helps, but perhaps that was
not what you proposed?



>     
>     > Section 3.4, may I assume that the document fixes the problem "X.733 and
>     > especially 3GPP were not really clear on this point." ?
>     
>     Yes.

The full text in 3.4 (after some small fixes after Roman's review):

   A primary goal of this alarm module is to remove any ambiguity in how
   alarm notifications are mapped to an update of an alarm instance.
   X.733 and especially 3GPP were not clear on this point.  This YANG
   alarm module states that the tuple (resource, alarm type identifier,
   alarm type qualifier) corresponds to a single alarm instance.  This
   means that alarm notifications for the same resource and same alarm
   type are matched to update the same alarm instance.

Do you think this needs further clarifications?



/martin