Subject: [core] Chair's review of draft-ietf-core-hop-limit-02.txt

From: Carsten Bormann <[email-masked]>
Date: Fri, 22 Feb 2019 00:20:32 +0100

In preparation for the impending working-group last call, I have
reviewed draft-ietf-core-hop-limit-02.txt.  Substantive comments are
below; a set of small editorial comments is going to the authors in
parallel.

# Major

1. Is adding a hop-limit option now a recommendation that applies to
   all CoAP proxies?

2. I don't understand the rule about using cached copies.  As a
   general observation, rules like this should not simply be stated
   without a rationale why they are the way they are.

# Minor

1. The text could include a sentence about what happens when a proxy
   does not understand the option (nothing bad, but loops consisting
   entirely of such proxies will not be terminated).

2. The way the diagnostic payloads are formed seems to rely on a space
   separator, but does not exclude its use inside the separated items.

# Editorial

1. The terminology could be aligned some more (e.g., avoid "agent",
   use "request" or "response" instead of "message" where
   possible). Details in the editorial comments.

Grüße, Carsten

---

From: <[email-masked]>
Date: Fri, 22 Feb 2019 09:25:41 +0000

Hi Carsten,

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:[email-masked]]
> Envoyé : vendredi 22 février 2019 00:21
> À : core
> Cc : [email-masked]
> Objet : Chair's review of draft-ietf-core-hop-limit-02.txt
> 

[Med] The intent is to provide infinite loop detection as a default behavior even in contexts where, e.g., clients do not support/insert the option. The behavior can be disabled by configuration. 

Do you prefer the default behavior the other way around? 

>    without a rationale why they are the way they are.

[Med] The rule is to use the cache if the cached value is:
* equal to the one in the request: this one is trivial. 
* less than the one in the request: this is to accommodate cases where some proxies sent requests on behalf of some clients. 

Then, why not using the cache for greater values? This is to accommodate, for example, a topology change so that additional proxies are to be visited when processing a request. That change has triggered (out of band) setting of a greater value. This can be seen as a way to update the cache with a greater value.

>    entirely of such proxies will not be terminated).

[Med] I added this NEW text: 

   Note that
   loops which involve only such proxies won't be detected.
   Nevertheless, the presence of such proxies won't prevent infinite
   loop detection if at least one CoAP proxy which support the Hop-Limit
   option is involved in the loop.

>    separator, but does not exclude its use inside the separated items.

[Med] Added an explicit sentence for this. 

>    possible). Details in the editorial comments.

[Med] Fixed.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 22 Feb 2019 13:47:00 -0800

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Friday, February 22, 2019 1:26 AM
> To: Carsten Bormann <[email-masked]>; core <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [core] Chair's review of draft-ietf-core-hop-limit-02.txt
> 
> Hi Carsten,
> 
> > De : Carsten Bormann [mailto:[email-masked]] Envoyé : vendredi 22
> > février 2019 00:21 À : core Cc : [email-masked]
> [Med] The intent is to provide infinite loop detection as a default behavior
> even in contexts where, e.g., clients do not support/insert the option. The
> behavior can be disabled by configuration.
> 

My gut feeling is that the answer should be yes it should become a recommended option for all CoAP proxies.  I am not sure that this is the time for that to happen.  I think that in the next couple of years there may be a larger need to develop some BCPs for proxies and that would be the time to make the recommendation.

Jim

> * less than the one in the request: this is to accommodate cases where some
> proxies sent requests on behalf of some clients.
> 
> Then, why not using the cache for greater values? This is to accommodate,
> for example, a topology change so that additional proxies are to be visited
> when processing a request. That change has triggered (out of band) setting
> of a greater value. This can be seen as a way to update the cache with a
> greater value.
> 
> > # Minor
> >
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 23 Feb 2019 06:58:03 +0100

> My gut feeling is that the answer should be yes it should become a recommended option for all CoAP proxies.  I am not sure that this is the time for that to happen.  I think that in the next couple…

Right.  So the specific question for the WG is:

Are we ready to strongly recommend (on a “SHOULD deploy” level) hop-limit as our proxy loop mitigation technique now?

Or should we wait with such a recommendation until we have had a broader view at proxy requirements?  (E.g., then, MAYBE we might want to go for Via-like loop prevention instead — very big MAYBE, as Via is expensive with IPv6.)

I don’t have a strong opinion either way and therefore would like some more feedback from the WG.

In any case, the place in DOTS where it says how CoAP is used for DOTS should also say “please do deploy hop-limit where proxies are used” in the strength that the DOTS people are comfortable with.

While the hop-limit draft is not heavily associated with DOTS, maybe it would be useful to add some “not just for DOTS” language as well (after all, that was the point of splitting it out).

Grüße, Carsten

---

From: <[email-masked]>
Date: Mon, 25 Feb 2019 07:22:23 +0000

Hi Carsten, Jim, all,

I do agree with Jim that it is early to have a “SHOULD deploy” level. At least that is not the intent of the text which triggered the comment. 

The intent is to allow for a configurable behavior of proxies which support the option. That wording can be updated to avoid misinterpretation, e.g.,:

OLD:
   If a CoAP proxy receives a request which does not include a Hop-Limit
   option, it SHOULD insert a Hop-Limit option when relaying the request
   to a next hop (absent explicit policy/configuration otherwise). 

NEW:
   A CoAP proxy MAY be instructed, using a configuration parameter, to
   insert a Hop-Limit option when relaying a request which do not
   include the Hop-Limit option.

Cheers,
Med

> Envoyé : samedi 23 février 2019 06:58
> À : Jim Schaad
> Cc : BOUCADAIR Mohamed TGI/OLN; core; [email-masked]
> Objet : Re: [core] Chair's review of draft-ietf-core-hop-limit-02.txt
> 
> > My gut feeling is that the answer should be yes it should become a
> recommended option for all CoAP proxies.  I am not sure that this is the time
> for that to happen.  I think that in the next couple of years there may be a
> larger need to develop some BCPs for proxies and that would be the time to
> make the recommendation.
> 
> Or should we wait with such a recommendation until we have had a broader view
> at proxy requirements?  (E.g., then, MAYBE we might want to go for Via-like
> loop prevention instead — very big MAYBE, as Via is expensive with IPv6.)
> 
> In any case, the place in DOTS where it says how CoAP is used for DOTS should
> also say “please do deploy hop-limit where proxies are used” in the strength
> that the DOTS people are comfortable with.
> 
> While the hop-limit draft is not heavily associated with DOTS, maybe it would
> be useful to add some “not just for DOTS” language as well (after all, that
> was the point of splitting it out).
> 
> Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 26 Feb 2019 12:19:18 +0100

Mohamed Boucadair wrote:
> Carsten Bormann wrote:

I assume you're referring to this rule:

   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.

(This matches the language in [1].)

Let's say proxy receives a request and has a matching Hop Limit
Reached error response in its cache. If the hop limit in the request
is equal to the hop limit in the request for the stored response, then
the stored error response can be returned. If the hop limit is less,
then the stored error response can also be returned. (If 6 hops are
not enough to reach the server, then 3 hops are also not enough.) If
the hop limit is greater, then the stored error response cannot be
returned. (The server might not be reachable in 6 hops, but it might
be reachable in 7 hops.) (This assumes that the number of hops to
reach a server doesn't change. If it changes, then a stored error
response might be served incorrectly until its max-age expires.)

I have to admit that I never checked if this also makes sense for
stored responses that are not a Hop Limit Reached error response...

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.6

---

From: <[email-masked]>
Date: Tue, 26 Feb 2019 13:28:18 +0000

Hi Klaus, 

Agree. The reasoning is straightforward for error codes. 

For the few cacheable success codes, we maintained the same wording because a change of the hop-limit is seen as a hint of a topology change and thus as a trigger to check the forwarding path. The conditions are as follows: 
* The forwarding path is changed between the proxy and the server (e.g., adding new proxies to the path). Such path may not be loop-free. 
* The client is informed out of band to increase the initial hop limit to accommodate the increase of hops.

Cheers,
Med

> De : Klaus Hartke [mailto:[email-masked]]
> Envoyé : mardi 26 février 2019 12:19
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Carsten Bormann; core; [email-masked]