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

Carsten Bormann <cabo@tzi.org> Sat, 23 February 2019 05:58 UTC

Return-Path: <cabo@tzi.org>
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 C9949130F0D; Fri, 22 Feb 2019 21:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=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 pVuZhmeVtfEU; Fri, 22 Feb 2019 21:58:14 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A27130E30; Fri, 22 Feb 2019 21:58:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [IPv6:2001:638:708:30c8:406a:91ff:fe74:f2b7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id x1N5w1nH017640; Sat, 23 Feb 2019 06:58:06 +0100 (CET)
Received: from [192.168.217.106] (p54A6C2FE.dip0.t-ipconnect.de [84.166.194.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 445yDT2Zmkz1Bp8; Sat, 23 Feb 2019 06:58:01 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <039e01d4caf8$25b9c9e0$712d5da0$@augustcellars.com>
Date: Sat, 23 Feb 2019 06:58:03 +0100
Cc: mohamed.boucadair@orange.com, core <core@ietf.org>, draft-ietf-core-hop-limit@ietf.org
X-Mao-Original-Outgoing-Id: 572594281.46174-b045296a03e0b14448c1d89d403f43a5
Content-Transfer-Encoding: quoted-printable
Message-Id: <A645E161-A46F-4315-B96F-9FEC47122502@tzi.org>
References: <7185933E-6816-435E-B668-2DB1367C279E@tzi.org> <787AE7BB302AE849A7480A190F8B93302EA23CEA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <039e01d4caf8$25b9c9e0$712d5da0$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/2r6GFUXW0SS_eDUIoJBf7UZRgGY>
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: Sat, 23 Feb 2019 05:58:16 -0000

On Feb 22, 2019, at 22:47, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> 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.

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