Re: [CCAMP] comments for draft-ietf-ccamp-alarm-module-06

[stefan vallin <[e-mail]>]

Hi Jinwei!
Thanks for your comments and support of the alarm module.
Note that it has passed last call. Your comments have been addressed previously on the mailing list
We provide a summary of the answers inline below.

br Stefan and Martin


> On 28 Dec 2018, at 03:30, Xiajinwei (Jinwei Xia, Network) <[e-mail]> wrote:
> 
> Dear editors,
> 
>  
> 
> As a new comer of CCAMP, I am happy with the good progress of the YANG alarm module and definitely support it.
> 
>  
> 
> Since I am working on the alarm design, I have a few comments on this draft:
> 
>  
> 
> 1, the draft identifies the alarm-type via the combination of alarm-type-id and alarm-type-qualifier. We fully like that, by the way, would we add one complemented and optional leaf, e.g., alarm-name (R-LOS), to briefly indicate the alarm type? While the corresponding alarm-text shows the comprehensive information about this alarm, e.g., the signal is lost on the receiver side.
> 
That would be the name of of the alarm identity (or the string qualifier)
such as:
import ietf-alarms {
     prefix al;
   }
   identity vendor-alarms {
     base al:alarm-type;
   }
   identity communications-alarm {
     base vendor-alarms;
   }
   identity R-LOS {
     base communications-alarm;
   }
>  
> 
> 2, for the alarm instance, the draft uses the triple-keys (resource, alarm-type-id and alarm-type-qualifier) to identify it. From my point of view, the design is great. Besides of the triple-keys identification in our design, we also add a complemented and optional alarm-serial-no leaf to do the same work. An alarm-serial-no is unique to identity one alarm instance, and thus the OSS can locate an alarm via the alarm-serial-no directly and save the time to map the triple-keys one by one. Does it make any sense
No, having redundant/overlapping keys is not optimal, this can create non-consistency.
See the following example from 3GPP Alarm IRP Appendix C:
* the Alarm IRP has an alarm identity, ai, corresponding to your proposal for alarm-serial-no
* moc = managed object class, moi = managed object instance; corresponds to resource in the alarm YANG module
* et = event-type, pc= probable-cause; corresponds to alarm-type in the alarm YANG module
* sp = specific-problem; corresponds to alarm-qualifier in the alarm YANG module

3GPP Alarm IRP snippet:
----
EXAMPLE 3: Invalid sequence of a hypothetical case:

(1) NotifyNewAlarm
(ni=1, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical)

(2) NotifyChangedAlarm
(ni=2, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

...
Interaction (2) is illegal since it uses a different ai for the same alarm. It should use ai=X as in interaction (1).
END snippet
----

We do not want to enable these kind of inconsistencies.
We prefer a semantic key triplet whereby the manager can get the composite alarm state for a given resource and alarm-type




> 
> 
> 3, for the alarm-type-id, could it be possible to support a union of identity and string? Currently, we have more or less 40000 alarm types in our implementation and the number is still rising right now. The YANG alarm module is still a huge volume when we build our own alarm-type augment.
40 000 alarm types, have you validated them against Appendix G, Alarm Usability Requirements?
No, a union would not be a good idea. To the extent possible all alarm-types should be defined at design time by YANG identifiers.
This gives the users/managers a way to prepare consequent actions and not discover these at run-time.
If your system really has 40 000 alarm types than that is what you should publish AND how to resolve the alarms.

Alarm qualifiers should be avoided as much as possible, they should only be used for alarm types that are configurable, like a digital input.
> 
>  
> 
> 4, in alarm notification message, the severity information is great to let operator know the alarm state (i.e., cleared, raised and changed). We like that, but it’d be better if there was a definite alarm-category leaf to indicate the brief alarm state regardless of the severity, any thoughts?
if the notification severity is cleared, the alarm is cleared
if the [resource, alarm-type, alarm-qualifier] tuple matches an existing alarm it is an update
if the [resource, alarm-type, alarm-qualifier] tuple does not match an existing alarm it is a raise

There are corner cases on the above relating to that a client/server might have performed house-keeping/purging actions.
> 
>  
> 
> Sorry for bringing any inconvenience of the late comments on the WGLC stage. Your feedbacks are very helpful for us J

All feedback is welcome :)
> 
>  
> 
> Merry Christmas and Happy New Year!
> 
>  
> 
> Jinwei
> 
>  
> 
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp