Load balancer listener update uses default SSL parameters instead of existing

Using oci lb listener update has undocumented side effects if any of the optional parameters which modify the SSL config don't specify the SSL config in its entirety. For example, one would expect that you could simply update and existing LB listener to use a different certificate by specifying the --ssl-certificate-name parameter. However, doing so causes the --protocols option to default to TLS1.2 instead of using the listener's existing value - the same applies with the other options such as hostnames. None of this is documented so you are left guessing which optional parameters might have unintended side-effects / cause failures.

In my case, all my configured HTTPS listeners on port 443 accept TLS1.2 and TLS1.3, so if I try to update the certificate using just the associated parameter it fails with:
"Not all SSL virtual listeners on port 443 have the same set of SSL protocols defined."
This is because it has now decided to also try and update the protocols to it's default value of just TLS1.2.

Could the command not just apply the new specified values and persist values already defined by the listener. If not, the documenation needs updating so that an end-user has some chance of knowing which optional params affect others.

On that note, why is --protocols not --ssl-protocols

Start by reproducing oci lb listener update with only --ssl-certificate-name on a listener that has custom TLS protocols, then trace the listener-update command's SSL option handling. Done means unspecified SSL settings remain unchanged, or the documentation clearly identifies the dependent defaults and explains the --protocols name.