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

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

Thank you for the review Adam! I started a new PR to address the IESG review comments:
https://github.com/core-wg/too-many-reqs/pull/5/files

See answers to your comments inline.

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

While the Max-Age use is a bit different in 2.xx series answers, how this draft uses it is actually very similar to how it’s used by the 5.03 code: “to indicate the number of seconds after which to retry”. I clarified this in the intro now (see the PR for details).

IANA registry update might be a good idea though.

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

Good point. I added a note saying that the default is assumed if the option is missing, and reference to section 5.10.5 of RFC7252.

> ---------------------------------------------------------------------------
> 
> Title:
> 
> This would benefit from having the COAP protocol named in the title.

Unfortunately adding the CoAP abbreviation in the long title would make the title too long for a single line and the abbreviation alone would be on second line. The short title contains the acronym already though. 

But if the current long title causes confusion, I guess we could ask the RFC editor to split the title in the final version in a more typographically aesthetic way.

> ---------------------------------------------------------------------------
> 
> §1:
> 
>> the too frequent requests from the requesting client are the reason
> 
> Nit: "...too-frequent..."

Fixed.


Thanks,
Ari