Code change:
2.1. <del> A quota policy is described in terms of service-limit and a time- window.  It is an Item whose bare item is a service-limit, along with associated Parameters. </del> <ins> A quota policy is maintained by a server to limit the activity (counted in quota units) of a given client over a period of time (known as the time-window) to a specified amount (known as the service-limit). </ins> <del> The following parameters are defined in this specification: </del> <ins> Quota policies can be advertised by servers (see ratelimit-policy- field), but they are not required to be, and more than one quota policy can affect a given request from a client to a server. </ins> <del> The REQUIRED "w" parameter value conveys a time window value as defined in time-window. Other parameters are allowed and can be regarded as comments.  They ought to be registered within the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters Registry", as described in iana-ratelimit- </del> <ins> A quota policy is expressed in Structured Fields STRUCTURED-FIELDS as an Integer that indicates the service limit with associated </ins> parameters. <del> For example, a quota policy of 100 quota units per minute: The definition of a quota policy does not imply any specific distribution of quota units within the time window.  If applicable, these details can be conveyed as extension parameters. </del> <ins> The following Parameters are defined in this specification: </ins> <del> For example, two quota policies containing further details via extension parameters: </del> <ins> The REQUIRED "w" parameter value conveys a time window (time- window). </ins> <del> To avoid clashes, implementers SHOULD prefix unregistered parameters with a vendor identifier, e.g. "acme-policy", "acme-burst".  While it is useful to define a clear syntax and semantics even for custom parameters, it is important to note that user agents are not required to process quota policy information. </del> <ins> For example, a quota policy of 100 quota units per minute is expressed as: </ins> <del> 2.2. </del> <ins> Other parameters are allowed and can be regarded as comments. Parameters for use by more than one implementation or service ought to be registered within the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters Registry", as described in iana-ratelimit- parameters. </ins> <del> Rate limit policies limit the number of acceptable requests within a given time interval, known as a time window. </del> <ins> Implementation- or service-specific parameters SHOULD be prefixed parameters with a vendor identifier, e.g. "acme-policy", "acme- burst". </ins> <del> The time window is a non-negative Integer value expressing that interval in seconds, similar to the "delay-seconds" rule defined in Section 10.2.3 of HTTP.  Subsecond precision is not supported. </del> <ins> 2.2. </ins> <del> 2.3. </del> <ins> The service limit is a non-negative Integer indicating the maximum amount of activity that the server is willing to accept from what it identifies as the client (e.g., based upon originating IP or user authentication) during a time-window. </ins> <del> The service limit is associated with the maximum number of requests that the server is willing to accept from one or more clients on a given basis (originating IP, authenticated user, geographical, ..) during a time-window. </del> <ins> The activity being limited is usually the HTTP requests made by the client; for example "you can make 100 requests per minute".  However, a server might only rate limit some requests (based upon URI, method, user identity, etc.), and it might weigh requests differently. Therefore, quota policies are defined in terms of "quota units". Servers SHOULD document how they count quota units. </ins> <del> The service limit is a non-negative Integer expressed in quota units. </del> <ins> For example, a server could count requests like "/books/{id}" once, but count search requests like "/books?author=WuMing" twice.  This might result in the following counters: </ins> <del> The service limit SHOULD match the maximum number of acceptable requests.  However, the service limit MAY differ from the total number of acceptable requests when weight mechanisms, bursts, or other server policies are implemented. </del> <ins> Often, the service limit advertised will match the server's actual limit.  However, it MAY differ when weight mechanisms, bursts, or other server policies are implemented.  In that case the difference SHOULD be communicated using an extension or documented separately. </ins> <del> If the service limit does not match the maximum number of acceptable requests the relation with that SHOULD be communicated out-of-band. </del> <ins> 2.3. </ins> <del> Example: A server could </del> <ins> Quota policies limit the number of acceptable requests within a given time interval, known as a time window. </ins> <del> count once requests like "/books/{id}" </del> <ins> The time window is a non-negative Integer value expressing that interval in seconds, similar to the "delay-seconds" rule defined in Section 10.2.3 of HTTP.  Subsecond precision is not supported. </ins> <del> count twice search requests like "/books?author=WuMing" </del> <ins> By default, a quota policy does not constrain the distribution of quota units within the time window.  If necessary, these details can be conveyed as extension parameters. </ins> <del> so that we have the following counters </del> <ins> For example, two quota policies containing further details via extension parameters: </ins> 3.

Related discussion:
text: Section 2.2: Section 2.3: This appears to be a circular definition -- what's actually being defined here?
(noting that 2.2 doesn't actually define quota-units)
Quota unit is now defined as the measurement unit for service limits.
PTAL - I tried to rearrange to address this a bit more holistically.
Looks good!LGTM