openbackhaul / alarms Goto Github PK

The latest UML2YANG tool will include mandatory substatement to attributes that has "Multiplicity 1 + no default values defined".
The following attributes which are formerly optional will be changed to mandatory in the upcoming YANG.

grouping attribute-value-changed-notification
1.referenced-severity-configuration-identifier

grouping alarm-event-notification
2. alarm-event-sequence-number
3. alarm-type-id
4. alarm-type-qualifier
5. resource

grouping alarm-kind-type
6. alarm-type-id
7. alarm-type-qualifier

grouping severity-configuration-type
8. severity-configuration-identifier
9. alarm-type-id
10. alarm-type-qualifier
11. resource-group-description

grouping current-alarm-type
12. current-alarm-identifier
13. alarm-type-id
14. alarm-type-qualifier
15. resource

grouping alarm-event-record-type
16. alarm-event-sequence-number
17. alarm-type-id
18. alarm-type-qualifier
19. resource

The current-alarm-list in the current-alarms container does not have a key.

In revision 2023-10-05 of the alarms-1-0 model, the resource-group-description attribute in the severity-configuration-type grouping has been made mandatory which is in line with issue #10.

My assumption is however that the intention was to make the resource-list attribute mandatory, similar to other groupings (current-alarm-type, alarm-event-record-type, alarm-behavior-type) and as implied by the comment in issue #10 (comment).
(The resource-group-description attribute is only informational and thus plain text.)

It shall be configurable, whether a specific kind of alarm is notified or not.

Potential Proposal:
An additional SeverityConfigurationType::notificationsIsOn : Boolean = false attribute shall be added.
It shall be equipped with the comment: "true : A notification gets sent, if such kind of alarm is raised or cleared."

Following are the issues observed in the pyang output for the yang generated for the UML Alarms_1.0.0-tsp.220224.1810,

1. alarms-1-0.yang:133: error: "core-model-1-4:local-class" in the path for subresource at alarms-1-0.yang:98 (at alarms-1-0.yang:131) is not found
2. alarms-1-0.yang:615: error: "core-model-1-4:local-class" in the path for subresource at alarms-1-0.yang:43 (at alarms-1-0.yang:613) is not found
3. alarms-1-0.yang:670: error: "core-model-1-4:local-class" in the path for subresource at alarms-1-0.yang:43 (at alarms-1-0.yang:668) is not found
4. alarms-1-0.yang:124: error: "core-model-1-4:global-class" in the path for resource at alarms-1-0.yang:98 (at alarms-1-0.yang:122) is not found
5. alarms-1-0.yang:606: error: "core-model-1-4:global-class" in the path for resource at alarms-1-0.yang:43 (at alarms-1-0.yang:604) is not found
6. alarms-1-0.yang:661: error: "core-model-1-4:global-class" in the path for resource at alarms-1-0.yang:43 (at alarms-1-0.yang:659) is not found

For the errors #1,#2,#3 the details are as follow ,

1. In yang , the attribute subresource is represented as below ,

leaf subresource {
      type leafref {
        path "/core-model:local-class/core-model:local-id";
        require-instance false;
      }
      config false;
      description
        "Concrete resource causing this alarm notification.";
    }

2. The path referred by the leaf is a non-existing path.

For the errors #4,#5,#6 the details are as follow ,

1. Yang representation for the attribute resource is,

leaf resource {
      type leafref {
        path "/core-model:global-class/core-model:uuid";
        require-instance false;
      }
      config false;
      description
        "Concrete resource causing this alarm notification.";
    }

2. Here also, the path referred by the leaf is a non-existing path.

In UML , the attributes resource and subresource are modeled as a shared aggregation. And so the tool is converting it to a leafref.

Following is the actual expectation for the path reference , (details provided by Thorsten Heinze)

We need something similar to the following, but with multiple different paths being accepted.

 type leafref {
       require-instance false;
       path "/core-model:control-construct/core-model:logical-termination-point/core-model:uuid";
     }

It would be like

 type leafref {
        require-instance false;
        path "/core-model:control-construct/*/core-model:uuid";
      }

or at least like

type leafref {
        require-instance false;
        path "/core-model:control-construct/core-model:logical-termination-point/core-model:uuid" OR "/core-model:control-construct/core-model:equipment/core-model:uuid";
      }

, but it seems YANG doesn’t know such things.

While configuring the level of severity of a combination of alarm type and resource, peripheral conditions might be of relevance.
E.g. the protection configuration (e.g. 1+0 or 1+1) might influence, whether a LoS alarm would be assigned to be critical or just e.g. major.
Based on this consideration we added two attributes (“severityLevelForServiceAffecting” and “severityLevelForNotServiceAffecting”) two every combination of alarm type and resource.

While searching for a generally adopted definition of what’s “service affecting”, we found indication that the definition of severity level “critical” is that the service is affected.
If the severity level would always be “critical” in all cases the service is affected, configuration of the severity level would be obsolete in these cases.

Potential proposal to the 5G-xhaul call
Creating a single SeverityConfigurationType::severityLevel attribute with comment: “Allows configuring the severity level of alarms of the specified combination of alarm type and resource, in case they are not service affecting. If such alarm would be service affecting, severity level ‘critical’ would be assigned in general.”
Deleting SeverityConfigurationType::severityLevelForServiceAffecting and SeverityConfigurationType::severityLevelForNotServiceAffecting attributes from the modeling.

Shall it be possible to change the severity level of an already existing alarm?

If yes:

• CurrentAlarms::CurrentAlarmType::problemSeverity would need to be variant and read/write.
• Also higher layer reference attributes would need to be read/write then.

Currently AlarmConfiguration::SeverityConfigurationType::severityLevelList allows to configure the severity of an alarm, but it is not possible to configure that the alarm shall neither be listed in the CurrentAlarmList nor be indicated by notification.

Potential Proposal:
The SeverityType enumeration shall be complemented by an additional DISABLED value.

Or is this not to be mixed with the severity configuration?

Usual technology specific models are offering four types of notifications:

• ObjectCreationNotification
• ObjectDeletionNotification
• AttributeValueChangedNotification
• ProblemNotification

Because not object gets instantiated or deleted in the Alarms modelling there would be just two types of notifications, right?

• AttributeValueChangedNotification
• AlarmEventNotification

Comment of the AlarmCapability::AlarmKindType::alarmTypeQualifier : "The optionally dynamically defined alarm type identifier for this possible alarm." somehow indicates that the values could be changed.

If value to be changed:

• Capability wrong place (read-only also at higher layer objects would have to be removed)?
• Cannot be partOfObjectKey, because requires to be invariant

Contradictory modeling/commenting to be resolved.

Which object shall be referenced by the _objectIdRef attribute in the AttributeValueChangedNotification?
Usually, it is LTP, but alarms are attached to ControlConstruct, which is not really meaningful, or?

The CurrentAlarmType datatype contains the key attribute currentAlarmIdentifier.

The currentAlarmIdentifier is not communicated within the AlarmEventNotification.

Without the currentAlarmIdentifier key attribute value the CurrentAlarms list inside the cache cannot be updated based on the received AlarmEventNotification.
This includes, for example:

• New entries cannot be created without the key attribute.
• Entries to be cleared (based on problemSeverity==alarm-1-0:SEVERITY_AND_CLEARED_TYPE_CLEARED) cannot be identified as the value of the key attribute is unknown.

Potential Proposal:
The currentAlarmIdentifier is added to the attributes comprised in the AlarmEventNotification.

The probable-cause attribute in the alarm-inventory-list is of type int16. It is not clear which values should or may be reported in this attribute.

The comment refers to X.733 but I could not find numerical values there. Furthermore, devices may report additional probable causes, e.g. from X.736 or M.3100.

Some implementations notify the status of some resources using an alarm with the severity STATUS value.
The model does not provide a suitable value (including SEVERITY_TYPE_INDETERMINATE) to map this STATUS value to.

The proposal is to add the SEVERITY_TYPE_STATUS identity based on SEVERITY_TYPE to extend values provided in ITU-T M.3160.

The AlarmTypeIdType datatype is an empty enumeration in the UML.
It is for the vendors to add their individual alarm names into an extendable identity.

Because there is no set of predefined values, which would allow concluding on the planned content of the enumeration, implementers are wondering about its purpose.

Potential solution:
A comment should be added to the enumeration in UML