Subject: [core] draft-ietf-core-hop-limit-01

From: Klaus Hartke <[email-masked]>
Date: Tue, 11 Dec 2018 14:43:03 +0100

Hi draft-ietf-core-hop-limit authors,

I have taken a brief look at -01. It seems the draft still doesn't
reflect the latest discussions relating to caching.

Here is some proposed text:

OLD:

   The Hop-Limit option is safe to forward. That is, a CoAP proxy which
   does not understand the Hop-Limit option should forward it on.

NEW:

   The Hop-Limit option is safe to forward. That is, a CoAP proxy which
   does not understand the Hop-Limit option should forward it on. The
   option is also part of the cache in this case. That is, a CoAP proxy
   which does not understand the Hop-Limit option must not use a stored
   response unless the value of the Hop-Limit option in the presented
   request is equal to the value of the Hop-Limit option in the request
   used to obtain the stored response.

OLD:

   Otherwise, each intermediate proxy, which understands the Hop-Limit
   option, involved in the handling of a CoAP message MUST decrement
   the Hop-Limit option value by 1 prior to forwarding upstream if this
   parameter exists.

NEW:

   Otherwise, a CoAP proxy which understands the Hop-Limit option MUST
   decrement the value of the option by 1 prior to forwarding it. A
   CoAP proxy which understands the Hop-Limit option MUST NOT use a
   stored response unless the value of the Hop-Limit option in the
   presented request is less than or equal to the value of the
   Hop-Limit option in the request used to obtain the stored response.

OLD:

   +--------+---+---+---+---+------------------+-----------+
   | Number | C | U | N | R | Name             | Reference |
   +--------+---+---+---+---+------------------+-----------+
   |  TBA2  |   |   | x |   | Hop-Limit        | [RFCXXXX] |
   +--------+---+---+---+---+------------------+-----------+

NEW:

   +--------+---+---+---+---+------------------+-----------+
   | Number | C | U | N | R | Name             | Reference |
   +--------+---+---+---+---+------------------+-----------+
   |  TBA2  |   |   |   |   | Hop-Limit        | [RFCXXXX] |
   +--------+---+---+---+---+------------------+-----------+

Best regards,
Klaus

---

From: <[email-masked]>
Date: Tue, 11 Dec 2018 15:18:24 +0000

Hi Klaus, 

Actually, given that we didn't receive a follow up from your side, we thought you are OK with our replies at: 

https://mailarchive.ietf.org/arch/msg/core/8UKmm9VyQ9pGvndvfYZjQofHn8g 

in which we reminded the following:

==
* Is {elective, safe to forward, not part of the cache key} the right choice?

Response> Yes, will update hop-limit option.
==

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : core [mailto:[email-masked]] De la part de Klaus Hartke
> Envoyé : mardi 11 décembre 2018 14:43
> À : [email-masked]
> Cc : [email-masked] WG
> Objet : [core] draft-ietf-core-hop-limit-01
> 

[Med] Isn't weird to have a requirement for a proxy which does not understand the option?  

>    Hop-Limit option in the request used to obtain the stored response.

[Med] Idem as above. Wouldn't be simple to maintain the design we have in -01?

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 11 Dec 2018 16:29:49 +0100

> https://mailarchive.ietf.org/arch/msg/core/8UKmm9VyQ9pGvndvfYZjQofHn8g

Apologies for not getting back to you earlier.

> Response> Yes, will update hop-limit option.

As noted in https://mailarchive.ietf.org/arch/msg/core/jE9AQZTDdx6nV0nRxxFDc2Ek8RA
, the outcome of the CoRE virtual interims was that the option should
be elective, safe-to-forward, and part of the cache.

> [Med] Isn't weird to have a requirement for a proxy which does not understand the option?

Yes. But it's not a new requirement, just what RFC 7252 specifies for
options classified as safe-to-forward and part-of-the-cache-key. Feel
free to clarify the proposed text to better reflect that.

> [Med] Idem as above. Wouldn't be simple to maintain the design we have in -01?

The option properties of safe-to-forward and part-of-the-cache-key
only apply to the case where an intermediary does not understand the
option, so the draft needs to be specific about the case when it is
understood.

Best regards,
Klaus

---

From: <[email-masked]>
Date: Wed, 12 Dec 2018 06:41:34 +0000

Hi Klaus, 

Please see inline. 

Cheers,
Med

> De : Klaus Hartke [mailto:[email-masked]]
> Envoyé : mardi 11 décembre 2018 16:30
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked] WG; [email-masked]
> Objet : Re: [core] draft-ietf-core-hop-limit-01
> 
> Mohamed Boucadair wrote:
> As noted in
> https://mailarchive.ietf.org/arch/msg/core/jE9AQZTDdx6nV0nRxxFDc2Ek8RA

[Med] What about the following NEW wording:

   The Hop-Limit option is safe to forward.  That is, a CoAP proxy which
   does not understand the Hop-Limit option should forward it on.  The
   option is also part of the cache.  As such, a CoAP proxy must follow
   the recommendations in Section 5.7.1 of [RFC7252] for caching.

> option, so the draft needs to be specific about the case when it is

[Med] Deal.

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 12 Dec 2018 13:58:06 +0100

Mohamed Boucadair wrote:
> What about the following NEW wording:
>
>    option is also part of the cache

... key.

> As such, a CoAP proxy

... which does not understand the Hop-Limit option ...

> must follow

> Deal.

👍

Klaus

---

From: <[email-masked]>
Date: Wed, 12 Dec 2018 13:17:05 +0000

Hi Klaus, 

Works for me. 

-02 implements your comments. Thank you. 

Chairs: please consider a WGLC for the draft. 

Cheers,
Med

> Envoyé : mercredi 12 décembre 2018 13:58