Re: [core] AD review of draft-ietf-core-too-many-reqs-04

Good point. I apologize if there was discussion I missed on this. 

For CoRE Pub/Sub, we are already using max-age for data lifetime. 

Thus it may be preferable to have a new option for retry-after. 

It also may make implementation of a common transfer layer easier.

Best regards,

Michael

> On Aug 16, 2018, at 7:52 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
> 
> Hi,
> 
> This is a straightforward document, as it tracks HTTP functionality defined in RFC 6585.
> 
> I have one main question about the document: when comparing this document with its HTTP counterpart, the HTTP version is using the Retry-After header field, while this document is reusing the Max-Age option. (HTTP has both Retry-After and Age header fields)
> 
> RFC 7252 defines Max-Age as follows:
> 
> 5.10.5.  Max-Age
> 
>    The Max-Age Option indicates the maximum time a response may be
>    cached before it is considered not fresh (see Section 5.6.1).
> 
>    The option value is an integer number of seconds between 0 and
>    2**32-1 inclusive (about 136.1 years).  A default value of 60 seconds
>    is assumed in the absence of the option in a response.
> 
>    The value is intended to be current at the time of transmission.
>    Servers that provide resources with strict tolerances on the value of
>    Max-Age SHOULD update the value before each retransmission. (See
>    also Section 5.7.1.)
> 
> So my question is: why is it Ok to reuse Max-Age option and not define a new one, which is closer to the desired semantics? If this was already discussed on the mailing list, please kindly point me to the relevant thread(s).
> 
> Thank you,
> 
> Alexey
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core