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

["Xiajinwei (Jinwei Xia, Network)" <[e-mail]>]

Hi Stefan,

Thanks for the feedbacks firstly! I am fine with the most of them.

Regarding to the 2nd comment, I agree with you the 3GPP IRP is somewhat confusing on the different ai for the alarm instance, and thus we don't totally use it in our implementation, instead, we use the alarm-serial-no to uniquely identify the alarm instance. Again, the alarm-serial-no does not work against the triple-keys, we just add it as COMPLEMENTED and OPTIONAL leaf in order to facilitate the OSS to locate an alarm ASAP :-)

Thanks!

Jinwei

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