Original text:
Servers' behavior may be subject to other conditions like the one shown in the example from service-limit. <del> A client MUST validate the RateLimit fields before using them and check if there are significant discrepancies with the expected ones. This includes a RateLimit-Reset field moment too far in the future (e.g. similarly to receiving "Retry-after: 1000000") or a service- limit too high. </del>  A client receiving RateLimit fields MUST NOT assume that future responses will contain the same RateLimit fields, or any RateLimit passed by a misconfigured server; or a high RateLimit-Reset field value could inhibit clients to <del> contact the server. Clients MUST validate the received values to mitigate those risks. </del>  7.

Reviewer comments:
no normative language in sec- -
This doesn't seem practical; how would validation help? What are they looking for?
For example, implementations are expected to validate received values like Or The same goes for other fields, e.g. A similar practice, in a different context though, is mentioned in URL Hints are welcome!
Considering the objective of the RateLimit headers is to allow a client to avoid being throttled, the consequence of a client ignoring the RateLimit-* headers is just a client getting throttled. If we believe that a client may need to protect itself against malicious values injected into these headers, then I it should be sufficient to give clients the permission to ignore the headers if they believe the values are not reasonable. Suggest wording like: However, considering that processing these headers is optional for a client anyway, I'm not sure this comment is absolutely necessary.
Part of the problem here is that "valid" is being used in different senses: to indicate that it's a valid Structured Field to indicate that it's semantically valid (e.g., "too big") For the latter, since it's so fuzzy (at least to date), I'd suggest using something like "reasonable" instead.
This seems quite arbitrary for a MUST; what is "too far in the future" and "too high"?
Agree, this is an tricky point. I think an implementation: MUST define internal threeshold of allowed values; MUST validate ratelimit fields according to those thresholds. I think we could borrow some text from Signature. See
OK, but RFC2119 language is for interoperability, and this doesn't provide any; different implementations (or deployments) are going to have different values, and that may cause issues. It'd be better to defines precise limits if you think this is important enough to merit a MUST. Personally, I'd remove the 2119 language and just give guidelines about what implementations should consider when they're looking for abuse.
Ok, great!
Addressed in

Revised text:
Servers' behavior may be subject to other conditions like the one shown in the example from service-limit.  <ins> A client is responsible for ensuring that RateLimit field values returned cause reasonable client behavior with respect to throughput and latency (see sec-resource-exhaustion and sec-dos). </ins> A client receiving RateLimit fields MUST NOT assume that future responses will contain the same RateLimit fields, or any RateLimit passed by a misconfigured server; or a high RateLimit-Reset field value could inhibit clients to  <ins> contact the server (e.g. similarly to receiving "Retry-after: 1000000"). To mitigate this risk, clients can set thresholds that they consider reasonable in terms of quota units, time window, concurrent requests or throughput, and define a consistent behavior when the RateLimit exceed those thresholds.  For example this means capping the maximum number of request per second, or implementing retries when the RateLimit-Reset exceeds ten minutes. The considerations above are not limited to RateLimit fields, but apply to all fields affecting how clients behave in subsequent requests (e.g.  Retry-After). </ins> 7.