Incorporate the review feedback

Author: yhyakuna

website/content/docs/configuration/create-rate-limit-quota.mdx

@@ -164,10 +164,15 @@ Create a rate limit quota using the following parameters:
 - `block_interval` `(string: "")` - If set, when a client reaches a rate limit
   threshold, Vault prohibits the client from any further requests until after
   the `block_interval` has elapsed. 
-- `inheritable` `(boolean: false)` - **Vault Enterprise:** Determine whether to
+- `inheritable` `(boolean: false)` - <EnterpriseAlert product="vault" inline /> Determine whether to
   apply the quota rule to child namespaces.   
-- `group_by` `(string: "")` - **Vault Enterprise:** Define how to group incoming
+- `group_by` `(string: "")` - <EnterpriseAlert product="vault" inline /> Define how to group incoming
   requests. Refer to the [identity-based rate limit quotas](/vault/docs/configuration/identity-based-rate-limit) for more details.
+- `secondary_rate` `(float: 0.0)` – <EnterpriseAlert product="vault" inline /> Can only be set
+  for the `group_by` modes `entity_then_ip` or `entity_then_none`. This is the rate limit applied
+  to the requests that fall under the "ip" or "none" groupings, while the authenticated requests
+  that contain an entity ID are subject to the `rate` field instead. Defaults to the same value
+  as `rate`.
 
 
 <Tabs>

website/content/docs/configuration/identity-based-rate-limit.mdx

@@ -1,84 +1,53 @@
 ---
 layout: docs
-page_title: Identity-based and collective rate limits
+page_title: Rate limit quotas - collective, by IP, by entity
 description: >-
   Implement protections to prevent misbehaving applications and clients from impacting Vault performance.
 ---
 
-# Identity-based and collective rate limits
+# Rate limit quotas - collective, by IP, by entity
 
 As the number of Vault client applications increases, the incoming requests to
-Vault can degrade Vault's performance. The issue is often caused by
-applications that are:
-
-- Generating an unbounded number of leases and/or loading too much data into
-  Vault leading to exhausting storage backend's available memory
-- Consuming an erroneously large amount of bandwidth leading to internal
-  throttling of the Vault cluster as a whole
-
-Use [rate limit quotas](/vault/docs/configuration/create-lease-count-quota) and
-[lease count quotas](/vault/docs/configuration/create-rate-limit-quota) to
-protect your Vault environment's stability and network, as well as storage
-resource consumption from runaway application behavior and distributed denial of
-service (DDoS) attack.
-
-
-Vault Enterprise permits organizations to define more fine-grained rate limits
-to how traffic enters their Vault cluster. Identity-based rate limit quotas use
-`group_by` options to create buckets for requests.
-
-<table>
-  <thead>
-    <tr>
-      <th style={{verticalAlign: 'middle'}}>Group_by option</th>
-      <th style={{verticalAlign: 'middle'}}>Description</th>
-    </tr>
-  </thead>
-
-  <tbody>
-
-  <tr>
-    <td><code>ip</code></td>
-    <td>
-      Creates buckets based on the IP addresses. (Default)
-    </td>
-  </tr>
-
-  <tr>
-    <td><code>entity_then_none</code></td>
-    <td>
-     Groups requests on namespace, mount, or path by entity ID. The rate applies to the each bucket created. Requests
-     without associated entity ID are handled by a collective secondary quota.
-    </td>
-  </tr>
-
-  <tr>
-    <td><code>entity_then_ip</code></td>
-    <td>
-      Groups requests on namespace, mount, or path by entity ID. The rate applies to the each bucket created. Requests without associated entity ID are bucketed by IP, and the rate applies to each bucket. This option is recommended if your organization has reliably mappable IPs.
-    </td>
-  </tr>
-
-  <tr>
-    <td><code>secondary_rate</code></td>
-    <td>
-      Allows organizations to set a separate rate for entity ID.<br/><br/>
-    </td>
-  </tr>
-
-  <tr>
-    <td><code>none</code></td>
-    <td>
-      Creates one bucket for the namespace, path, or mount and collectively limits all traffic to that target.
-    </td>
-  </tr>
-
-  </tbody>
-</table>
-
-The default behavior is to group requests by IP addresses. Group requests by
- entity (`entity_than_none` or `entity_then_ip`) option creates buckets based on
-the attached entity. This helps when your organization have:
+Vault can degrade Vault's performance. To protect your Vault environment's
+stability and network, as well as storage resource consumption from runaway
+application behavior and distributed denial of service (DDoS) attack, use [rate
+limit quotas](/vault/docs/configuration/create-lease-count-quota) and [lease
+count quotas](/vault/docs/configuration/create-rate-limit-quota).
+
+For Vault Enterprise clusters, the rate limit quota supports **`group_by`**
+option to define more fine-grained rate limits to control how traffic enters
+their cluster.
+
+The available `group_by` modes are:
+
+- `ip` - groups requests by their source IP address (`group_by` defaults to `ip`
+  if unset)
+
+  <Note title="Vault Community Edition">
+
+  The `ip` mode is the only supported mode in the community edition of Vault.
+
+  </Note>
+
+- `none` - groups together all requests that match the rate limit quota rule
+
+- `entity_then_ip` - groups requests by their entity ID for authenticated
+  requests that carry one, or by their IP for unauthenticated requests (or
+  requests whose authentication is not connected to an entity)
+
+- `entity_then_none` - groups requests by their entity ID when available, but
+  the rest is all grouped together (for example, unauthenticated requests, and
+  requests with authentication that is not connected to an entity)
+
+The `group_by` option with `entity_then_ip` or `entity_then_none` mode allows
+you to set a secondary rate limit (**`secondary_rate`**). This rate limit applies to
+the requests that fall under the `ip` or `none` groupings, while the
+authenticated requests that contain an entity ID are subject to the primary rate
+limit set by the `rate` parameter.
+
+The default behavior is to group requests by their source IP addresses. The
+`entity_then_none` or `entity_then_ip` mode groups requests based on their
+attached entity. This helps when your organization have:
 
 - many workloads using the same IP
 - single workloads using many IPs which may scale up or down
@@ -107,9 +76,9 @@ limit quota takes effect on the requests.
 
 ### Example
 
-The command below creates a rate limit quota with rate of 1000 requests per
+The command below creates a rate limit quota with rate of 1,000 requests per
 second with `group_by` is set to `entity_then_none`, and the secondary rate is
-2000 requests per second.
+2,000 requests per second.
 
 ```shell-session
 $ vault write sys/quotas/rate-limit/my-rate \

website/data/docs-nav-data.json

@@ -279,11 +279,9 @@
     ]
   },
 
-  
   { "divider": true },
   { "heading": "OPERATIONS" },
 
-
   {
     "title": "Get Vault",
     "routes": [
@@ -358,7 +356,7 @@
       }
     ]
   },
-  
+
   {
     "title": "Configure Vault",
     "routes": [
@@ -396,7 +394,7 @@
         "path": "configuration/create-rate-limit-quota"
       },
       {
-        "title": "Identity-based and collective rate limits",
+        "title": "Rate limit quotas by IP or entity",
         "badge": {
           "text": "ENT",
           "type": "filled",
@@ -416,10 +414,10 @@
           "color": "neutral"
         },
         "path": "configuration/entropy-augmentation"
-      },  
-      
+      },
+
       { "heading": "Configuration stanzas" },
-    
+
       {
         "title": "<code>adaptive_overload_protection</code>",
         "badge": {
@@ -2603,7 +2601,7 @@
       },
       {
         "title": "Rollback upgrades",
-        "path" : "plugins/rollback"
+        "path": "plugins/rollback"
       },
       {
         "title": "Plugin development",