Re: [core] Benjamin Kaduk's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT)

[Ari Keränen <[e-mail]>]

Thank you for the review Ben!

I have addressed most of your comments in the IESG review PR:
https://github.com/core-wg/too-many-reqs/pull/5/files

See answers and one more discussion point inline.

> On 23 Oct 2018, at 22.57, Benjamin Kaduk <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-core-too-many-reqs-05: No Objection
[...]
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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."

Good point. Added this text to the server behavior section.

>   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.)

Yes. I clarified this now in the end of server behavior section.

> 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.

Are you referring to “many requests in flight” issue? For a client sending too many requests before receiving an answer a 4.29 seems like appropriate answer. Or which well-behaving client do you mean here?

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

OK, I added a note in the beginning referring to RFC7252.


Thanks,
Ari