Subject: Re: [CCAMP] Question on alarm-notification draft-ietf-ccamp-alarm-module-07.txt

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Mar 2019 09:15:37 +0100 (CET)

Hi,

"Beauville, Yves (Nokia - BE/Antwerp)" <[email-masked]> wrote:
> Hello,
> 
> In the proposed YANG module, an alarm-notification conveys a single
> alarm state change.
> 
> There are scenarios where server may want to send a possibly large set
> of alarm state changes at the same time.

This is correct, but it is not limited to alarms; it applies to all
kinds of notifications.  The NETCONF WG is working on a more generic
solution to this problem, where a single notification message can
contain multiple notifications
(draft-ietf-netconf-notification-messages).   I think this is a more
flexible solution than coding this into every YANG-defined notification
(not just alarms).

> For example:
> 
>   *   re-configuration of severities
>   *   a transient network issue

I think Stefan will send some comments re these examples.

> Would we do this more efficiently by allowing the alarm-notification
> to convey a list of state changes rather than a single one?

/martin

---

From: "Beauville, Yves (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 4 Mar 2019 08:23:49 +0000

Hi Martin,

Thank you very much for your reply.

I totally agree with the fact that it is a generic concern, that would 
better be addressed by allowing to send multiple notifications in a 
single NETCONF message.

Do not mind my examples. I understand they may not be appropriate. 
Apologies for this.

Yves

---

From: stefan vallin <[email-masked]>
Date: Mon, 4 Mar 2019 09:31:10 +0100

Hi!
>>  *   re-configuration of severities
I do not think that changing the alarm severity profile should change the severity levels of *existing* alarms. 
At the time those alarm state changes appeared it was according to the configuration at *that* time. 
Strange if a configuration change affected previous alarm states. 
Therefore, no alarm state changes should be sent for a reconfiguration of severity levels.

>>  *   a transient network issue
See Appendix G (especially Table 4), the system should not send unnecessary alarm state changes for transient changes.
Hysteresis functions, alarm throttling etc are mechanisms outside the scope of this alarm model that should be managed by 
the system in order not to send too high alarm rates.

br Stefan

> On 4 Mar 2019, at 09:15, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Beauville, Yves (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 4 Mar 2019 09:05:01 +0000

Hello Stefan,

Thank you for your reply.

I acknowledge that the examples I picked were not appropriate.

The first example about severity changes was indeed clearly incorrect. 
The draft-ietf-ccamp-alarm-module-07 is clear about the consequences of 
a severity reconfiguration.

My second example was also arguable. Though, even if implementations 
shall strive to avoid sending too high alarm rates, it makes sense to 
optimize the sending multiple notifications, as described by Martin.

Best Regards

Yves