Original text:
be the given resource-target, its parent path or the whole Origin (see Section 7 of RFC6454). <del> The rate-limit fields may be returned in both Successful and non Successful responses.  This specification does not cover whether non Successful responses count on quota usage. </del>  This specification does not mandate a specific throttling policy. The values published in the fields, including the window size, can A server MAY return "RateLimit" response fields independently of the response status code.  This includes throttled responses.  Servers should be careful in returning "RateLimit" fields in redirection responses (eg. 3xx status codes) because a low "RateLimit-Remaining" value could limit the client from issuing Response:  8.1.2. The server uses two custom fields, namely "acme-RateLimit-DayLimit"

Reviewer comments:
clarifies that status code is independent from the values of RL fields the example reflects the above statement.
Would there be scope to define standards for the 429 response or would that be more relevant to RFC6585. Should RFC6585 be extended to mention this RFC ?
This I-D is independent from the status code of the response, so I'd say there are no normative relations between this doc and RFC6585. This is by design: we just want to standardize response fields without explicitly define a "ratelimit protocol". Instead, we want implementers to be free to implement their throttling strategies.
See. URL
I noticed in the example in You return a 200 response with RateLimit-Remaining: 0 . It is not completely clear in the document that a remaining value of 0 should be returned to the caller as a success when the quota has been used exactly. In you present a case where the cost of a more expensive call deducts two from the remaining pool and results in a 429. I am conflicted as to whether it should be a server decision whether the call is respected or whether the spec should strictly define this behaviour. I lean toward the former but some feel guidance is needed.
we should clarify that this is a server choice. The spec does not mandate any correlation between the RL values and the returned status code . The server can always decide to serve requests even when quota is over. We need to clarify this both in the text and in the example.
That is something that was not clear to me when reading the spec. The assumption being that when is exhausted, a user will be rate limited and an error response (429) will be issued. It would seem as per and that there is no specific intention to require a server implementation to deny further responses, but rather in some cases the expectation would be for the client to gracefully comply and back off. My feeling is though that this use case would be the exception rather than the rule, with most implementations opting to deny further requests. Should we not at least provide guidance that a 429 response should be issued in this scenario ?

Revised text:
be the given resource-target, its parent path or the whole Origin (see Section 7 of RFC6454).  <ins> The rate-limit fields may be returned in both successful (see Section 15.3 of SEMANTICS) and non-successful responses.  This specification does not cover whether non Successful responses count on quota usage, nor it mandates any correlation between the RateLimit values and the returned status code. </ins> This specification does not mandate a specific throttling policy. The values published in the fields, including the window size, can A server MAY return "RateLimit" response fields independently of the response status code.  This includes throttled responses. <ins> This document does not mandate any correlation between the "RateLimit" values and the returned status code. </ins> Servers should be careful in returning "RateLimit" fields in redirection responses (eg. 3xx status codes) because a low "RateLimit-Remaining" value could limit the client from issuing Response: <ins> Since the field values are not necessarily correlated with the response status code, a subsequent request is not required to fail. The example below shows that the server decided to serve the request even if "RateLimit-Remaining" is 0.  Another server, or the same server under other load conditions, could have decided to throttle the request instead. Request: Response: </ins> 8.1.2. The server uses two custom fields, namely "acme-RateLimit-DayLimit"