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

<> Fri, 22 February 2019 09:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4E1F128CE4; Fri, 22 Feb 2019 01:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y1XhnSBiIbJP; Fri, 22 Feb 2019 01:25:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F0DAB128CB7; Fri, 22 Feb 2019 01:25:43 -0800 (PST)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 445QtZ2vCdzFqkv; Fri, 22 Feb 2019 10:25:42 +0100 (CET)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by (ESMTP service) with ESMTP id 445QtZ27S5zBrLG; Fri, 22 Feb 2019 10:25:42 +0100 (CET)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0435.000; Fri, 22 Feb 2019 10:25:42 +0100
From: <>
To: Carsten Bormann <>, core <>
CC: "" <>
Thread-Topic: Chair's review of draft-ietf-core-hop-limit-02.txt
Thread-Index: AQHUyjwU2aXJonTlXUmkQdG+hNvQqaXrXsKg
Date: Fri, 22 Feb 2019 09:25:41 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA23CEA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [core] Chair's review of draft-ietf-core-hop-limit-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Feb 2019 09:25:46 -0000

Hi Carsten,

Thank you for the review. 

Please see inline. 


> -----Message d'origine-----
> De : Carsten Bormann []
> Envoyé : vendredi 22 février 2019 00:21
> À : core
> Cc :
> Objet : Chair's review of draft-ietf-core-hop-limit-02.txt
> 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?

[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? 

> 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.

[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.

> # 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).

[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.

> 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.

[Med] Added an explicit sentence for this. 

> # 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.

[Med] Fixed.

> Grüße, Carsten