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

Jim Schaad <ietf@augustcellars.com> Fri, 22 February 2019 21:47 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018F8130E79; Fri, 22 Feb 2019 13:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThqXZYy64hoO; Fri, 22 Feb 2019 13:47:08 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E130A1275F3; Fri, 22 Feb 2019 13:47:07 -0800 (PST)
Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Feb 2019 13:47:01 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: <mohamed.boucadair@orange.com>, 'Carsten Bormann' <cabo@tzi.org>, 'core' <core@ietf.org>
CC: <draft-ietf-core-hop-limit@ietf.org>
References: <7185933E-6816-435E-B668-2DB1367C279E@tzi.org> <787AE7BB302AE849A7480A190F8B93302EA23CEA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA23CEA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Fri, 22 Feb 2019 13:47:00 -0800
Message-ID: <039e01d4caf8$25b9c9e0$712d5da0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHYz3v1ePoYqh77aS9g7esO8Fa65wKEfZudpdAsjoA=
Content-Language: en-us
X-Originating-IP: [50.252.25.182]
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7lZfqBEO4m2n9To0moTB4cAG3IA>
Subject: Re: [core] Chair's review of draft-ietf-core-hop-limit-02.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 21:47:11 -0000


> -----Original Message-----
> From: core <core-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Friday, February 22, 2019 1:26 AM
> To: Carsten Bormann <cabo@tzi.org>rg>; core <core@ietf.org>
> Cc: draft-ietf-core-hop-limit@ietf.org
> Subject: Re: [core] Chair's review of draft-ietf-core-hop-limit-02.txt
> 
> Hi Carsten,
> 
> Thank you for the review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Carsten Bormann [mailto:cabo@tzi.org] Envoyé : vendredi 22
> > février 2019 00:21 À : core Cc : draft-ietf-core-hop-limit@ietf.org
> > 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?

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

> 
> >
> > 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
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core