address comments

Author: richabanker

keps/sig-instrumentation/4827-component-statusz/README.md

@@ -83,7 +83,7 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 - [x] (R) Graduation criteria is in place
   - [ ] (R) [all GA Endpoints](https://github.com/kubernetes/community/pull/1806) must be hit by [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) 
 - [x] (R) Production readiness review completed
-- [ ] (R) Production readiness review approved
+- [x] (R) Production readiness review approved
 - [x] "Implementation History" section is up-to-date for milestone
 - [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]
 - [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
@@ -160,13 +160,13 @@ We are proposing to add a new endpoint, /statusz on all core Kubernetes componen
 
 3. **Premature Dependency on Unstable Format**
 
-  The alpha release will explicitly support plain text format only, making it clear that the output is not intended for parsing or automated monitoring. The feature will be secured behind a feature gate that is disabled by default, ensuring users opt-in consciously. Also, the endpoint will be implemented with versioned URLs to facilitate future transitions to structured formats without breaking existing integrations, once the usage patterns and requirements are better understood
+  The alpha release will explicitly support plain text format only, making it clear that the output is not intended for parsing or automated monitoring. The feature will be secured behind a feature gate that is disabled by default, ensuring users opt-in consciously. Also, the endpoint will support specifying a version as a query parameter to facilitate future transitions to structured schema changes without breaking existing integrations, once the usage patterns and requirements are better understood
 
 ## Design Details
 
 ### Data Format and versioning
 
-Initially, the statusz page will exclusively support a plain text format for responses. We will implement these endpoints using versioned URLs, like /statusz/v1, to ensure future compatibility. By using versioned URLs, like /statusz/v2, we can evolve the endpoint and introduce changes to the response schema without impacting clients relying on previous versions, ensuring backward compatibility.
+Initially, the statusz page will exclusively support a plain text format for responses. This endpoint will support specifying a version param, like /statusz?version=2, to ensure future compatibility. Through this, we can evolve the endpoint and introduce changes to the response schema without impacting clients relying on previous versions, ensuring backward compatibility.
 
 ### Authz and authn
 
@@ -178,8 +178,10 @@ Access to the endpoint will be limited to members of the `system:monitoring grou
 
 #### Request
 * Method: **GET** 
-* Endpoint: **/statusz/v1**
+* Endpoint: **/statusz**
 * Header: `Content-Type: text/plain`
+* URL params:
+  * version: (Optional) An integer representing the desired response schema version. Defaults to 1.
 * Body: empty
 
 #### Response fields
@@ -203,6 +205,7 @@ Minimum Compatibility version: 1.30.0
 
 List of useful endpoints
 --------------
+configz:/configz
 healthz:/healthz
 livez:/livez
 metrics:/metrics
@@ -260,12 +263,12 @@ The primary purpose of the statusz page is to provide information about the indi
 
 ### Feature Enablement and Rollback
 
-We will target this feature behind a flag `ComponentStatuszFeatureGate`
+We will target this feature behind a flag `ComponentStatusz`
 
 ###### How can this feature be enabled / disabled in a live cluster?
 
 - [x] Feature gate (also fill in values in `kep.yaml`)
-  - Feature gate name: ComponentStatuszFeatureGate
+  - Feature gate name: ComponentStatusz
   - Components depending on the feature gate:
     - apiserver
     - kubelet