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

[Martin Bjorklund <[e-mail]>]

"Eric Vyncke (evyncke)" <[e-mail]> 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" <[e-mail]> wrote:
> 
>     Hi,
>     
>     Éric Vyncke via Datatracker <[e-mail]> 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