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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Aug 2018 15:52:46 +0100

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

---

From: Michael Koster <[email-masked]>
Date: Thu, 16 Aug 2018 07:57:39 -0700

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 <[email-masked]> 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)
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Aug 2018 17:39:01 +0200

On Aug 16, 2018, at 16:52, Alexey Melnikov <[email-masked]> wrote:
> 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

---

From: Ari Keränen <[email-masked]>
Date: Fri, 17 Aug 2018 18:58:38 +0000

> On 16 Aug 2018, at 18.39, Carsten Bormann <[email-masked]> wrote:
> 

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)