resolving KEP comments round kubernetes#4

Author: aaron-prindle

keps/sig-api-machinery/5073-declarative-validation-with-validation-gen/README.md

@@ -374,11 +374,11 @@ Today, the apiserver's request handler decodes incoming versioned API requests t
 
 Assuming we use the recommended plan of declarative validation operating on versioned types, the internal type will no longer be responsible for validation.
 
-If we were to convert from the internal back to the version of the API request for validation, we would introduce one additional conversion. If we make this an "unsafe" conversion, then it will be low cost for the vast majority of requests.
+We will convert from the internal back to the version of the API request for validation introducing one additional conversion. If we make this an "unsafe" conversion, then it will be low cost for the vast majority of requests.
 
 We will benchmark this approach and plan to use it for beta.
 
-Long term, we could do better:
+**NOTE**: Long term, it is possible that we could make one of versioned types be the hub type:
 
 Since the internal type will no longer be used for validation, it becomes a lot less important. It is still important to have a hub type. But why not pick one of the versioned types to be the hub type? The vast majority of APIs only have one version anyway. The obvious candidate version to choose for the hub version would be the preferred storage version.
 
@@ -388,11 +388,17 @@ Switching to a versioned type for the hub type would have a few implications:
 *   We would introduce more conversion when API request version differs from the hub version. But beta APIs are off-by-default and we expect a lot less mixed version API usage than in the past.
 *   Would require rewriting in tree admission plugins.
 
-This "hub version" change feels like something that could be made somewhat independent of this KEP.
+This "hub version" change is something that could be made independent of this KEP, just noting the idea here.
+
+##### Mitigation: Resolve Known "Low Hanging Fruit" of Performance Improvements In Current Validation Code
+
+From analyzing the validation code there is "SO MUCH low-hanging fruit" - @thockin with respect to performance improvements.  As such it is likely Declarative Validation can cover any perf deficit by improving validation performance generally. One example of this that already came up is related to the algorithm used for `listmap` (see prototype for more information)
 
 ##### Mitigation: Avoid Conversion to Internal Type
 
-Requests are received as the versioned type, so it should be feasible to avoid extra conversions for resources that have no need of handwritten validations.
+**NOTE** This would be a SIGNIFICANT undertaking to prove defaulting and admission is equivalent. 
+
+Requests are received as the versioned type, so it should be feasible to avoid extra conversions for resources that have no need of handwritten validations.  This is likely not necessary given the known "low hanging fruit" of performance improvements but mentioned for completeness.
 
 ## Design Details