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

Request Review of draft-ietf-core-too-many-reqs
Requested rev. 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
Draft 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 rev. 04 (document currently at 06)
Review result Ready with Nits
Review 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  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.