diff --git a/keps/prod-readiness/sig-api-machinery/2896.yaml b/keps/prod-readiness/sig-api-machinery/2896.yaml
new file mode 100644
index 000000000000..e6501d6cae6a
--- /dev/null
+++ b/keps/prod-readiness/sig-api-machinery/2896.yaml
@@ -0,0 +1,3 @@
+kep-number: 2896
+stable:
+  approver: "@deads2k"
diff --git a/keps/sig-api-machinery/2896-openapi-v3/README.md b/keps/sig-api-machinery/2896-openapi-v3/README.md
index ec61387936ab..724d550e5804 100644
--- a/keps/sig-api-machinery/2896-openapi-v3/README.md
+++ b/keps/sig-api-machinery/2896-openapi-v3/README.md
@@ -306,6 +306,8 @@ enhancement:
 -->
 
 - Enabling/disabling the feature gate
+- For upgrading, aggregated apiserver images must also be updated to serve OpenAPI v3 in order for the aggregator to pick up the spec and publish OpenAPI v3. OpenAPI v2 will continue to work regardless of version skew.
+- For downgrading, aggregated apiservers do not need to be downgraded as everything will revert to using OpenAPI v2 and the OpenAPI v3 endpoint will be untouched.
 
 ### Version Skew Strategy
 
@@ -403,7 +405,7 @@ with and without the feature, are necessary. At the very least, think about
 conversion tests if API types are being modified.
 -->
 
-n/a
+n/a.
 
 ### Scalability
 
@@ -432,7 +434,7 @@ Focusing mostly on:
     heartbeats, leader election, etc.)
 -->
 
-Yes. Get on the `/openapi/v3` endpoint as well as `/openapi/v3/{group}` for each API group provided by Kubernetes
+Yes. Get on the `/openapi/v3` endpoint as well as `/openapi/v3/{group}/{version}` for each API group provided by Kubernetes
 
 ###### Will enabling / using this feature result in introducing new API types?
 
@@ -443,7 +445,7 @@ Describe them, providing:
   - Supported number of objects per namespace (for namespace-scoped objects)
 -->
 
-No
+No.
 
 ###### Will enabling / using this feature result in any new calls to the cloud provider?
 
@@ -453,7 +455,7 @@ Describe them, providing:
   - Estimated increase:
 -->
 
-No
+No.
 
 ###### Will enabling / using this feature result in increasing size or count of the existing API objects?
 
@@ -464,7 +466,7 @@ Describe them, providing:
   - Estimated amount of new objects: (e.g., new Object X for every existing Pod)
 -->
 
-No
+No.
 
 ###### Will enabling / using this feature result in increasing time taken by any operations covered by existing SLIs/SLOs?
 
@@ -491,6 +493,8 @@ This through this both in small and large cases, again with respect to the
 [supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md
 -->
 
+No. One thing to note is that aggregation for OpenAPI v2 consumes quite a bit of memory. OpenAPI v3 will avoid aggregating the entire spec and only aggregate (if necessary) per group/version, decreasing the runtime and memory usage to a negligible amount.
+
 ## Implementation History
 
 <!--