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

[Carsten Bormann <[e-mail]>]

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.

Grüße, Carsten