There are some enhancement that could be improved for Edge limiting policy, see below:

•  In 4.1.11.2. Limit definition, about the "key name", we can emphasize more:

The name represents  the key itself, and the value is the counter which is incremented.  It is a best practice to have this name as business meaningful. The name must be unique among all the keys. Otherwise, it will cause the requests increment the wrong counters which will incorrectly increment the rate limit counters.

• Customer might also confuse that the relationship between current policy and the application plan rate limit. We can add below:

The current policy could be considered as a more fine grained rate limit comparing with rate limit defined in application plan by providing per-second rate limit control. It could  work together with the rate limit defined in the application plan. When the edge limit policy is triggered, it throws error 429 too many requests by default. When application plan user limit triggered, it throws user limit exceeded. 

• About  redis_url under 4.1.11.5, we could highlight more that:

If you have more than one APICast instances (pods),  it is mandatory to configure the redis_url parapeter to specify a standalone Redis instance. The reason is that, the policy will by default use a cache in the gateway (not centralizied Redis) to increment the counters unless configured otherwise. In order to have a global counter that applies to multiple replicas it is necessary to have a centralized cache (redis instance). The Redis should be deployed in a persistent way and maintained separately to the 3scale environment. It has nothing to do with the3scale default provided system-redis and system-backend Redis instance. Note that, the maintenance of this Redis instance is not as part of Red hat support scope. You can deploy the Redis outside the OCP, or in the OCP, as you wish.