[core] Tsvart last call review of draft-ietf-core-too-many-reqs-04

[Jana Iyengar <[e-mail]>]

Reviewer: Jana Iyengar
Review result: Ready with Nits

I've reviewed this document as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the benefit of the transport area directors. Document editors and WG chairs
should treat these comments just like any other last call comments.

This is a simple document that defines a new response code for CoAP servers to
use when under overload. The response code ("4.29 Too Many Requests") is used
as a flow control signal to indicate to a client that it needs to stop sending
more "similar" requests. The amount of time that the client needs to back off
is encoded in the response.

This is a straightforward document and I see no major issues, but I have a
couple of suggestions that might help implementers.

1. There should be text suggesting what a server MAY do if the client doesn't
respect the backoff period indicated in the response. For instance, a server
MAY drop all incoming requests from a client for an extended period of time if
the client sends a request without waiting for the duration of the backoff
period (or some such).

2. There should be some text suggesting that the server does not have to (and
probably should not) respond to every incoming request during overload with
this response. Even when the server wants to ask clients to back off, it does
not need to do that on every incoming request from a client. For instance, a
server can choose to respond to each client once in every estimated round-trip 
time.

3. Is the expectation that the client waits for the back off time starting from
when the response is received? That seems like the most obvious way to do it,
but it might be useful to clarify precisely when the client's backoff period
starts.