supportedAlarmList to get DefaultValue and *

[openBackhaul]

The current concept of supportedAlarmList:

• Defining a couple of alarms, which are mandatory to be supported in the comment,
• defining the minimum multiplicity according to the number of mandatory alarms
• (because not possible to have default, when minimum multiplicity > 0) having no default value.

This concept doesn't work, because it is not assured that devices support the mandatory alarms. As a consequence they could not be listed in the Capability attribute. In worst case (happened at least for HybridMwStructure and PureEthernetStructure) the device does not support any alarm at all at this interface.

Because it is a list attribute, but does not have a default value, the attribute doesn't show up in the implementation in this case.

Proposal: All supportedAlarmList attributes shall have multiplicity and default value "Supported Alarms Not Yet Defined." supportedAlarmList : String [] = "Supported Alarms Not Yet Defined."

[openBackhaul]

Decision made on the 5G-xhaul call on 28th of July 2021: The supportedAlarmList attribute shall have multiplicity and default value "Supported alarms not yet defined." (supportedAlarmList : String [] = "Supported alarms not yet defined.") UML and YANG have to be corrected.

Further on, the comment shall be corrected from "Available alarms to be listed. Mandatory: 'rxLos'. Optional: 'txFault', 'tempHigh', 'tempLow', 'rxLevelHigh', 'rxLevelLow', 'vccHigh', 'vccLow', 'txBiasHigh', 'txBiasLow', 'txPowerHigh', 'txPowerLow', 'laserTempHigh', 'laserTempLow', 'tecCurrentHigh', 'tecCurrentLow'. Further alarms might be added by the device." towards "Available alarms to be listed by the vendor.".

[openBackhaul]

Got obsolete due to issue #39.