Re: [CCAMP] Roman Danyliw's Discuss on draft-ietf-ccamp-alarm-module-08: (with DISCUSS and COMMENT)

[stefan vallin <[e-mail]>]

Hi Roman!

> On 9 Apr 2019, at 18:18, Roman Danyliw <[e-mail]> wrote:
> 
>> This is the reason for the
>> MUST in the text; a device MUST list all alarm types in the inventory so that a
>> management application knows about it.
> 
> What if the device is misconfigured/rogue and doesn't implement the MUST (i.e., doesn't put all of the alarm types in the inventory; returns a different alarm type than requested by the server)?  I was expecting text roughly on the order of "if the management application gets an alarm of an unknown type it MUST discard it."

So your question is how a client shall deal with a bug/non compliant implementation. (Violating the MUST).

I do not think discarding the alarm is the proper behaviour.
Assume an admin adds a new detector/sensor and configures it as an alarm detector.
But there is a bug so that it is not added to the alarm inventory.

When there is a fire, we would get an alarm  like:

dev:detectors/dev:detector[id=17], ]xyz-al:environmental-alarm, “smoke”

According to the alarm definition, “undesired state that requires action”, it should be handled by the client application
We certainly want the operators to do some fire fighting. Discarding the alarm would not be a good decision.
Alarm applications normally has a link to a wiki page or something with a written instruction how to handle the alarm, or
a link to an automatic action. In this case this would be void. The application should high-light that it is missing in the inventory.
But this is an application design issue. And ignoring it is not recommended.

Also consider the “simplest” alarm client, that just shows the alarm list, it would show the alarm although it is missing in the inventory

br Stefan