When performing firmware update, it can be useful for a user to specify if the UpdateService can "force update" a SoftwareInventory instance or not. In this context, "force update" can be defined as follows: Allow UpdateService to perform firmware update on a device even if the version of the firmware/software currently running on that device is equal to/greater than the version of the firmware/software in the firmware update package for that device.
To draw an analogy, PLDM (DSP0267) has something similar: Request Force Update of component – Can be used to inform the FD/FDP to perform a
transfer even if the component has a lower or equal component comparison stamp, or version
string, than what is currently installed. The UA will set this bit for any component which has the force
update bit set in the ComponentOptions field of the package header. Additionally, the UA could set
the bit as instructed by commands used to provide the update package to the UA (these commands
are out of scope for this spec).
This could be defined as the following property in the SoftwareInventory schema: ForceUpdateable boolean read-write An indication of whether the UpdateService can update this software with a version that is lower than or equal to the current version.
Does the forum think such a property is acceptable?
What use cases do you have in mind for this for when a Redfish client would want to make use of this control? While devices support this from a protocol perspective, services have their own policies for when they would use this flag internally depending on an update being given by a user.
The main use-case I had in mind was to enable a user (with the default policy being to not allow this) to allow re-install of the same version of Software.
That is the kind of case that I think we should consider. Where there is a "default policy" within the Service to reject things like down-rev version or attempts to re-install same version, but the user has a reason to override that policy, if it is possible.
What that would NOT allow is to violate internal policies that protect against incompatible versions, downgrades to versions with known security flaws, etc.