Skip to main content

Last Call Review of draft-ietf-core-too-many-reqs-04

Request Review of draft-ietf-core-too-many-reqs
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2018-10-12
Requested 2018-09-28
Authors Ari Keränen
I-D last updated 2018-10-18
Completed reviews Tsvart Last Call review of -04 by Jana Iyengar (diff)
Genart Last Call review of -04 by Dan Romascanu (diff)
Secdir Last Call review of -04 by Daniel Migault (diff)
Assignment Reviewer Jana Iyengar
State Completed
Review review-ietf-core-too-many-reqs-04-tsvart-lc-iyengar-2018-10-18
Reviewed revision 04 (document currently at 06)
Result Ready w/nits
Completed 2018-10-18
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 

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