add a bit about making discovery consistent

keps/sig-api-machinery/3903-unknown-version-interoperability-proxy/README.md

@@ -192,9 +192,24 @@ incorrectly or objects being garbage collected mistakenly.
 
 We will use the existing `StorageVersion` API to figure out which resources an apiserver can serve.
 
+We will also need to make discover reports the same set of resources everywhere. We propose
+routing discovery requests from old-apiservers to the new api-server, so that all discovery
+requests reflect the newest one. We specifically rule out merging discovery docs, because
+merging discovery is:
+
+* complicated 
+* represents an intermediate state which may not even make sense
+* the problems that merging discovery solves (i.e. preventing orphaned objects) can actually
+  be solved by the dynamic feature flag KEP, so solving it here would be redundant and 
+  unnecessarily complex. 
+
+By routing all discovery requests to the newest apiserver, we can ensure that namespace and gc
+controllers do what they would be doing if the upgrade happened instantaneously. 
+
 API changes:
 * To the apiservices API, add an "serviceableBy" clause, a list of
   apiservers which believe they can serve the group-version.
+* To the ??? API, we will add the public key for communication with an apiserver.
 
 API server change:
 * A controller adds the apiserver to the list of `serviceableBy`s for its built-in
@@ -203,7 +218,11 @@ API server change:
   apiserver identity work.)
 * A new handler is added to the stack:
   - If the request is for a group/version the apiserver doesn't have locally, it
-    will proxy the request to ag `serviceableBy`s if one is available, if one is not available, then we will return a 503 (there is a small possibility of a race between the controller registering the apiserver with the resources it can serve and receiving a request for a resource that is not yet available on that apiserver).
+    will proxy the request to ag `serviceableBy`s if one is available, if one is not 
+    available, then we will return a 503 (there is a possibility of a race 
+    between the controller registering the apiserver with the resources it can 
+    serve and receiving a request for a resource that is not yet available on 
+    that apiserver).
 
 ### User Stories (Optional)
 
@@ -259,7 +278,10 @@ TODO: security / cert stuff.
 
 ## Design Details
 
-TODO: specific API change (x2)
+We need a single API changes:
+
+1. We need to store apiserver public keys to allow apiservers to communicate with
+   each other. Where we store this data is yet to be determined.
 
 TODO: explanation of how the handler will determine a request is for a resource
 that should be proxied.