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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sat, 06 Apr 2019 14:34:46 -0700

É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" ;-)

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

Perhaps did I miss the part where the alarm system could also fails: what
alarm? status? does it generate? Or is it out of scope?

*minor NITS*
Section 1 s/north-bound/northbound/ ?

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Apr 2019 13:54:41 +0200 (CEST)

Hi,

> https://datatracker.ietf.org/doc/draft-ietf-ccamp-alarm-module/

This term was discussed by the WG, but since it is commonly used in
the alarm industry, we kept it.

> especially 3GPP were not really clear on this point." ?

Yes.

> alarm? status? does it generate? Or is it out of scope?

This document doesn't define any specific alarm types, so in that
sense this is out of scope.

> Section 1 s/north-bound/northbound/ ?

Fixed!

/martin & stefan

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 8 Apr 2019 12:07:15 +0000

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?

-éric

On 08/04/2019, 13:54, "Martin Bjorklund" <[email-masked]> wrote:

    Hi,

    
    
    Yes.

    
    
    Fixed!

    /martin & stefan

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Apr 2019 14:30:48 +0200 (CEST)

> around the first 2 points that I raised?

See inline.

>     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?

>     > especially 3GPP were not really clear on this point." ?

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