Apply suggestions from code review

Co-authored-by: Kevin Klues <klueska@gmail.com>

content/en/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md

@@ -9,14 +9,15 @@ weight: 65
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.26" state="alpha" >}}
-{{< feature-state for_k8s_version="v1.30" state="alpha" >}}
+{{< feature-state feature_gate_name="DynamicResourceAllocation" >}}
 
 Dynamic resource allocation is an API for requesting and sharing resources
 between pods and containers inside a pod. It is a generalization of the
 persistent volumes API for generic resources. Third-party resource drivers are
 responsible for tracking and allocating resources, with additional support
 provided by Kubernetes via "structured parameters" (introduced in Kubernetes 1.30).
+When a driver uses structured parameters, Kubernetes handles scheduling
+and resource allocation without having to communicate with the driver.
 Different kinds of resources support arbitrary parameters for defining requirements and
 initialization.
 
@@ -65,7 +66,7 @@ ResourceSlice
 ResourceClaimParameters
 : Contain the parameters for a ResourceClaim which influence scheduling,
   in a format that is understood by Kubernetes (the "structured parameter
-  model"). Initialization parameters may be embedded in an opaque
+  model"). Additional parameters may be embedded in an opaque
   extension, for use by the vendor driver when setting up the underlying
   resource.
 
@@ -78,14 +79,16 @@ typically using the type defined by a {{< glossary_tooltip
 term_id="CustomResourceDefinition" text="CRD" >}} that was created when
 installing a resource driver.
 
-The developer of a resource driver decides whether they want to handle those
-parameters in their own controller or want to use structured parameters. A
+The developer of a resource driver decides whether they want to handle these
+parameters in their own external controller or instead rely on Kubernetes to
+handle them through the use of structured parameters. A
 custom controller provides more flexibility, but cluster autoscaling is not
 going to work reliably for node-local resources. Structured parameters enable
 cluster autoscaling, but might not satisfy all use-cases.
 
 When a driver uses structured parameters, it is still possible to let the
-end-user specify parameters with CRDs. The driver then needs to translate those
+end-user specify parameters with vendor-specific CRDs. When doing so, the
+driver needs to translate those
 custom parameters into the in-tree types. Alternatively, a driver may also
 document how to use the in-tree types directly.
 
@@ -206,23 +209,24 @@ ResourceClaims, and thus scheduling the next pod gets delayed.
 ### With structured parameters
 
 When a driver uses structured parameters, the scheduler takes over the
-responsibility of allocating a ResourceClaim once a pod needs the
-ResourceClaim. It does that by retrieving the information about available
-resources from ResourceSlice objects, tracking which of those are in use based
-on already allocated ResourceClaims, and then selecting resources which match
-the requirements defined by ResourceClaimParameters and (if specified)
-ResourceClassParameters and which are available on a potential node.
-
-The chosen resource is recorded in the ResourceClaim status together with the
-initialization parameters, so when a pod is about to start on a node, the
-resource driver on the node has all information that it needs to prepare the
+responsibility of allocating resources to a ResourceClaim whenever a pod needs
+them. It does so by retrieving the full list of available resources from
+ResourceSlice objects, tracking which of those resources have already been
+allocated to existing ResourceClaims, and then selecting from those resources
+that remain.  The exact resources selected are subject to the constraints
+provided in any ResourceClaimParameters or ResourceClassParameters associated
+with the ResourceClaim.
+
+The chosen resource is recorded in the ResourceClaim status together with any
+vendor-specific parameters, so when a pod is about to start on a node, the
+resource driver on the node has all the information it needs to prepare the
 resource.
 
-The scheduler is able to reach a decision without communicating with the
-resource driver. It can also schedule multiple pods quickly by keeping
-information about ResourceClaim allocations in memory while writing that
-information to the ResourceClaim objects is going on in the background together
-with binding the pod to a node.
+By using structured parameters, the scheduler is able to reach a decision
+without communicating with any DRA resource drivers. It is also able to
+schedule multiple pods quickly by keeping information about ResourceClaim
+allocations in memory and writing this information to the ResourceClaim objects
+in the background while concurrently binding the pod to a node.
 
 ## Monitoring resources