Draft: draft-ietf-httpapi-ratelimit-headers

Commentary: no normative language in sec- - 
 This does n'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 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 " ? 
  , 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 does n'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
Paragraph (version A):
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.
Paragraph (version B):
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).
Paragraph (version A):
or a high RateLimit-Reset field value could inhibit clients to
contact the server.
Paragraph (version A):
Clients MUST validate the received values to mitigate those risks.
Paragraph (version B):
or a high RateLimit-Reset field value could inhibit clients to
contact the server (e.g. similarly to receiving "Retry-after:
1000000").
Paragraph (version B):
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.
Paragraph (version B):
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).