"Too Many Requests" Response Code for the Constrained Application Protocol
draft-ietf-core-too-many-reqs-06

Thanks for the work that everyone did on this document. I have one major
comment, and a couple of small editorial nits.

This document defines the use of the Max-Age option that is very different from
its originally defined use. It seems to me that the IANA registry entry for
Max-Age needs to be updated to reference this document in addition to RFC 7252.

Additionally, the original definition of Max–Age included a default value of 60
seconds. It is unclear, and somewhat ambiguous, whether that default is intended
to apply to this mechanism as well. Please add text explicitly indicating
whether a default applies. In any case, this document should have an indication
of what the client does if the response contains no max-age option.

---------------------------------------------------------------------------

Title:

This would benefit from having the COAP protocol named in the title.

---------------------------------------------------------------------------

§1:

>  the too frequent requests from the requesting client are the reason

Nit: "...too-frequent..."

Hi, thanks for the work on this. I have a few comments, below:

I share Adam's concern about overloading Max-Age for this purpose. If anything, the use in this document is specifying a minimum time interval, not a maximum one. That is, this use not only overloads Max-Age, but does it in a counter-intuitive way. Is there a reason not to define a new option?

§4: "A client MUST NOT rely on a server being able to send the 4.29
Response Code in an overload situation because an overloaded server
may not be able to reply at all to some requests."

Can you elaborate on the practical effect of that MUST NOT?

Section 3

It may be appropriate to explicitly reiterate that "The 4.29 response code is
only returned to the client(s) sending requests too frequently; if other
clients are sending requests that cannot be served due to server overload,
the 5.03 response code is more appropriate."

   If a client repeats a request that was answered with 4.29 before Max-
   Age time has passed, it is possible the client did not recognize the
   error code and the server MAY respond with a more generic error code
   (e.g., 5.03).

Isn't it also possible that the additional requests were already in flight
when the 4.29 was generated?  (It's unclear whether that needs to be
specifcially mentioned in the document.)

Section 5

As per the previous comment, a server that erroneously returns 4.29 to too
many (i.e., including well-behaving) clients would unnecessarily DoS the
well-behaved clients. 

It may be appropriate to reference the RFC 7252 security considerations as
continuing to apply.

Thanks for addressing the comments from the TSV-ART (and thanks Jana for the review)! I definitely support those comments and respective clarifications/additions in the document!

I echo Mirja's thanks for the both the efforts that went into performing the TSV-ART review and into its resolution.

* Section 3

If the server is maintaining state per clients for the Max-Age, does the timer get reset if a repeat request comes in before the timer expires?

* Section 4

I think it could be useful to recommend some behavior for the proxies as well, in order to avoid a specific client being starved by other clients on a proxy.