Clarity required upon detected-condition and its attributes

[kgkishore]

o Reason for is-transient attribute support missing in detected-condition
o Reason for enums for WARNING, INFO, INDETERMINATE unavailable in perceived-severity
o Description needed for ALR identities that would be used to populate detected-condition-name based on probable cause
o Need clarity about the supported TAPI_Alarm_TCA_List.

[nigel-r-davis]

is-transient

In TAPI 2.1.3, this was defined as an alarm that is stateless with no clear. This was slightly ambiguous as it is really an alarm with imediate clear. This case is now covered in TAPI 2.5 by FLEETING in the simple detector state Enum. A fleeting alarm is one that clears immediately after becoming active (i.e., it is active for an extremely short period).

There is also an ACTIVE_WITH_NO_SPECIFIC_CLEAR literal for the case where a detection is ongoing for a while then clears silently. This is actually inadequate equipment behavior, but as it does exist this literal is made available to cover it.

perciever-severity-type

This does have a WARNING value in 2.5 and 2.1.3. It did not have INFO and INDETERMINATE in 2.1.3 and does not in 2.5.

INFO

INFO is not really an alarm, it is an event. Could you provide a view of application of INFO.

INDETERMINATE

It is not clear what this actually means as a severity.

Moving forward without severity :)

As we have discussed on many occasions in the recent past (20+ years :) ), a device deciding on severity made sense in 1950. It does not seem relevant in a modern automated network. We should have this discussion again probably. I could recover the rationale (from TAPI published material) if that would help.

Alarm Identities and TAPI_Alarm_TCA_List

See https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI-Documentation/tree/v2.5.0/AlarmsAndNotifications