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

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

> On 16 Aug 2018, at 18.39, Carsten Bormann <[e-mail]> wrote:
> 
> On Aug 16, 2018, at 16:52, Alexey Melnikov <[e-mail]> 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).
> 
> I think this is modeled after 5.03 in 7252:
> 
> 5.9.3.4.  5.03 Service Unavailable
> 
>   This Response Code is like HTTP 503 "Service Unavailable" but uses
>   the Max-Age Option in place of the "Retry-After" header field to
>   indicate the number of seconds after which to retry.
> 
> In both cases, the max-age limits the validity of the hold-off expressed by the response code.
> 
> Michael: Data lifetime doesn’t really enter here, as there is no data with either 4.29 or 5.03.

Indeed, IIRC that's where we got the inspiration from back in 2015 [1]. It was also discussed (/mentioned) in the IETF 93 CoRE WG session [2]. Minutes didn't have much details so probably there was no long debate on this though.


Cheers,
Ari


[1] https://tools.ietf.org/html/draft-koster-core-coap-pubsub-02#section-7
[2] https://www.ietf.org/proceedings/93/slides/slides-93-core-0.pdf (slide 68)