For the attribute force-download in download-firmware-component , as per the modelling ,
if force-download is true , then files will be downloaded even if it is already present in the device.
And if force-download is false , then the opposite to “force-download=true” will happen.

leaf force-download {
        type boolean;
        mandatory true;
        description
          "Files to be downloaded, even if already present on the device.";
      }

Request : In the description , it is saying to download the FW to the device even it already present. Can we also specify the bank(act/stby) details?

Request raised on behalf of Zia(testing team)

The current formulation of the comment of the downloadFirmwareComponent operation is lacking the definition of the error messages.

Decision on the 5G-xhaul call on 21st of April:
Changing the comment of the downloadFirmwareComponent operation from:
"Operation for downloading some firmware component (e.g. package) from a server onto the device."

towards
"Idempotent operation for downloading some firmware component (e.g. package) from a server onto the device. The following error-messages are to be send, if the operation would fail: #[onf:URI syntax is incorrect.]#, if the URI is not correct. #[onf:Input parameter missing.]#, if the input parameters are insufficient for identifying the download resource and to authenticate at the server."

Current modelling adds two attributes to the ControlConstruct: download and firmware-component-list.
It would be better, if the entire Firmware modelling would be contained in a container.

Proposal:
Augmenting a firmware-cc-spec grouping (to the control-construct) that contains a firmware-collection container, which comprises download and firmware-component-list attributes.
(presumably modeled in UML like this: Adding a FirmwareCcSpec class between FirmwareCollection class and ControlConstruct and augmenting the FirmwareCcSpec to the ControlConstruct and adding a composite association from the FirmwareCcSpec to the FirmwareCollection).

The comment of the abortFirmwareDownload operation should indicate that the operation is idempotent.
So, no error message is to be send, even if no download would be on-going and could be aborted.

Decision on the 5G-xhaul call on 21st of April:
Changing the comment of the abortFirmwareDownload operation from:
"Currently on-going download of a firmware component shall immediately be terminated."

towards:
"Idempotent operation for immediately terminating currently on-going downloads of firmware components."

The firmware-component-status/firmware-component-activation-date attribute has a wrong type. It is of type string but should be yang:date-and-time.

The current formulation of the comment of the activateFirmwareComponent operation is lacking the definition of error messages.

Decision on the 5G-xhaul call on 21st of April:
Changing the comment of the activateFirmwareComponent operation from:
"Operation for activating some firmware component on the device. (Attention! Invoking this operation might cause the device to reboot.)"

towards:
"Idempotent operation for activating some firmware component on the device. (Attention! Invoking this operation might cause the device to reboot.) The following error-message is to be send, if the operation would fail: #[onf:Referenced object is invalid.]#, if the referenced FirmwareComponent does not exist."

Decision during the 5G xhaul call on 8th of November 2023:
Since there is a technology independent definition of notifications, the definitions of notifications in the technology specific modelings are obsolete.
Consequently, the definitions of notifications shall be deleted from all technology specific modelings.
(The technology independent definition of alarms keeps being untouched.)