tidy

hips/hip-00XX.md

@@ -25,27 +25,28 @@ The primary motivation for Helm to switch to Server-Side Apply is to gain the be
 
 https://kubernetes.io/blog/2022/10/20/advanced-server-side-apply/
 
-Helm supporting SSA will allow users to realize the benefits of SSA. And longer term goals (out of scope for this HIP) might be for Helm to utilize SSA by default ([similar to kubectl](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3805-ssa-default>)), and later as a code mantainence benefit, eventually drop support for the strategic-merge patch client-side apply process/code.
+Helm supporting SSA will allow users to realize the benefits of SSA. And longer term goals (out of scope for this HIP) might be for Helm to utilize SSA by default ([similar to kubectl](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/3805-ssa-default)). Finally later as a code mantainence benefit, eventually drop support for the strategic-merge patch client-side apply process/code.
 
 ## Rationale
 
 <!-- Describe why particular design decisions were made. -->
 
-Due to the backwards compatibility concerns documented below, the decision was made to provide opt-in support only. And even when a chart is deployed with SSA enabled, Helm should mantain full compatibility with reverting back to CSA. Additionally it was desirable to mimic kubectl's cli interface/flags. As a way for Helm to be consistent with an existing kubectl functionality.
+Due to the backwards compatibility concerns documented below, the decision was made to provide opt-in support only. And even when a chart is deployed with SSA enabled, Helm should mantain full compatibility with reverting back to using CSA for upgrades/rollbacks. Additionally it was desirable to mimic kubectl's cli interface/flags. As a way for Helm to be consistent with an existing kubectl functionality.
 
 ## Specification
 
 <!-- Describe the syntax and semantics of any new feature. -->
 
 ### General
 
-Helm will add a new flag to the install, upgrade and rollback sub-commands: `--server-side=false|true|auto`, modelled after the like `kubectl` flag. And add a corresponding field to the respective install/upgrade/rollback SDK API objects. Helm will default to `false` for installs, retaining its existing behaviour. When `true`, Helm will submit resources to the Kubernetes API server with SSA enabled. When `auto`, Helm will default to CSA on installs (`false`), and for upgrades and rollbacks enable SSA based on the whether SSA was utilized for the prior operation (`auto`). The usage of SSA for a given release will be stored in the release's manifest.
+Helm will add a new flag to the install, upgrade and rollback sub-commands, modelled after the like `kubectl` flag. And add a corresponding field to the respective install/upgrade/rollback SDK API objects:
+`--server-side=false|true|auto`
 
-If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes v1.22), Helm should error.
+Helm will default to `false` for installs, retaining its existing behaviour. When `true`, Helm will submit resources to the Kubernetes API server with SSA enabled. When `auto`, Helm will default to CSA on installs (`false`), and for upgrades and rollbacks enable SSA based on the whether SSA was utilized for the prior operation (`auto`). The usage of SSA for a given release will be stored in the release's manifest.
 
-If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new manifest object will omit the indication of SSA usage from the releases manifest (and so upgrades with a SSA supporting version of Helm will not continue to use SSA by default).
+If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new manifest object will omit the indication of SSA usage from the releases manifest (and so futher upgrades/rollbacks will continue to use CSA by default).
 
-In a future version of Helm 3 cli, it might be desirable to omit a warning if a user is not using SSA (In order to prompt the user to enabling SSA).
+In a future version of Helm 3 cli, it might be desirable to omit a warning if a user is not using SSA (in order to prompt the user to enabling SSA).
 
 #### Custom resources
 
@@ -70,6 +71,7 @@ https://github.com/kubernetes/kubectl/blob/197123726db24c61aa0f78d1f0ba6e91a2ec2
 #### Special
 
 - `--dry-run=client` doesn't work with SSA enabled
+- If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes v1.22), Helm should error.
 
 
 ## Backwards compatibility
@@ -83,14 +85,14 @@ There are thought to be three main compatibility concerns for Helm switching to
 
 For 1., this HIP limits Helm to opt-in to server side apply, allowing users to verify SSA's behaviour matches their expectations. For 2., the user can mitigate by ensuring SSA is consistantly used within their environment. But the expectation is that SSA should generally produce equivalient Kubernetes objects as CSA.
 
-Additionally as noted, SSA isn't compatible with very old Kubernetes versions (SSA beta Kubernetes 1.18)
+Additionally as noted, SSA isn't compatible with very old Kubernetes versions (Kubernetes v1.17 and prior)
 
 
 ## Security implications
 
 <!-- How could a malicious user take advantage of this new feature? -->
 
-There should not be any additional security concerns.
+There should not be any additional security concerns. Server-side apply and client=side apply should be eqivalient security-wise.
 
 ## How to teach this