IETF Logo Mail Archive

Re: [core] [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.txt

Laurent Toutain <laurent.toutain@imt-atlantique.fr> Tue, 11 June 2019 14:17 UTC

Return-Path: <laurent.toutain@imt-atlantique.fr>
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 54CE4120147; Tue, 11 Jun 2019 07:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr
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 4ern6IcnakG7; Tue, 11 Jun 2019 07:17:20 -0700 (PDT)
Received: from zproxy120.enst.fr (zproxy120.enst.fr [IPv6:2001:660:330f:2::c1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382BA1201A3; Tue, 11 Jun 2019 07:16:56 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 2BD4F805A0; Tue, 11 Jun 2019 16:16:54 +0200 (CEST)
Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id B0uFa5nm3X8k; Tue, 11 Jun 2019 16:16:52 +0200 (CEST)
Received: from localhost (localhost [IPv6:::1]) by zproxy120.enst.fr (Postfix) with ESMTP id 9FF3C807D0; Tue, 11 Jun 2019 16:16:52 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy120.enst.fr 9FF3C807D0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1560262612; bh=v/2diIhPP4XtEcD5akVN7Gb6tjCW27jDNn9Bc4QThKA=; h=MIME-Version:From:Date:Message-ID:To; b=LZOxHUsa26d0PU0QZyQTFc/soIRXw+RP1U7ThcP818pVZVba/90sJAjPYteSiMDqe iU0q1jt+IUAW+m2ICiorPVJ5bcHTy3qrXrbIimSq03OXBcZF1q8jGYD3yYtjcj+9wR fFYvqFG4eDYN5BHMpANIYJEPco+a/rezSNppofYk=
X-Virus-Scanned: amavisd-new at zproxy120.enst.fr
Received: from zproxy120.enst.fr ([IPv6:::1]) by localhost (zproxy120.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id 5L_bK78ocnwI; Tue, 11 Jun 2019 16:16:52 +0200 (CEST)
Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) by zproxy120.enst.fr (Postfix) with ESMTPSA id 4A5BF805A0; Tue, 11 Jun 2019 16:16:52 +0200 (CEST)
Received: by mail-it1-f171.google.com with SMTP id m3so5193471itl.1; Tue, 11 Jun 2019 07:16:52 -0700 (PDT)
X-Gm-Message-State: APjAAAXkp/twgMYzCfWaKCt7o+vL9IbU4weFF1iqOi/HTp4USqM0JpYI dUraP0t62l1W0/dbWMHtEojR5j0cIamH8cVWnlM=
X-Google-Smtp-Source: APXvYqw4o4nS0nv00cqENoybgXihQfcj3fGy8T55tzGxcD0iJnXHj3onRSc2xaglOxVpzmVBSqhs4sanaEj+3K+wQVU=
X-Received: by 2002:a02:b10b:: with SMTP id r11mr46788584jah.140.1560262610880; Tue, 11 Jun 2019 07:16:50 -0700 (PDT)
MIME-Version: 1.0
References: <155915229337.5461.11045326859886255040.idtracker@ietfa.amsl.com> <CABONVQZoDpTXQeTkszptBGybg6yXYLquLkb5L8sn6aq4wJq_tw@mail.gmail.com> <CAObGJnPGK82RHt1rhUkAsrHe4StHkJbRTM0CJ5=tmPM=-_XUyw@mail.gmail.com>
In-Reply-To: <CAObGJnPGK82RHt1rhUkAsrHe4StHkJbRTM0CJ5=tmPM=-_XUyw@mail.gmail.com>
From: Laurent Toutain <laurent.toutain@imt-atlantique.fr>
Date: Tue, 11 Jun 2019 16:16:13 +0200
X-Gmail-Original-Message-ID: <CABONVQb+Kgtb7AaJzJTzH0sYFUHxfRj9VWuWksn39GkKBEKbRg@mail.gmail.com>
Message-ID: <CABONVQb+Kgtb7AaJzJTzH0sYFUHxfRj9VWuWksn39GkKBEKbRg@mail.gmail.com>
To: Thomas Fossati <tho.ietf@gmail.com>
Cc: lp-wan <lp-wan@ietf.org>, "core@ietf.org WG" <core@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ad8e45058b0cf255"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/zcgm_urYPFd078BTB1_xrHLNna8>
Subject: Re: [core] [lp-wan] Fwd: New Version Notification for draft-ietf-lpwan-coap-static-context-hc-08.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: Tue, 11 Jun 2019 14:17:26 -0000

Hi Thomas,


Thank you for your comments and changes in the github.

On Thu, May 30, 2019 at 1:53 PM Thomas Fossati <tho.ietf@gmail.com> wrote:

> Hi Laurent,
>
> On Wed, May 29, 2019 at 6:56 PM Laurent Toutain
> <laurent.toutain@imt-atlantique.fr> wrote:
> > We have issued a new version of the SCHC coap compression
> > to remove an artifact due to a bad github manipulation.
>

> I have taken a look at the draft but since I cannot claim compression
> expertise I will only provide a couple of high level comments:
> - Sec 3: "a proxy placed before the compressor may change some field
> value".  You should qualify the "proxy" as a "CoAP proxy, explicitly
> selected by the client" to avoid any ambiguity -- we certainly don't
> want to recommend middle-box interference :-)
>

Yes CoAP proxy.


> - Sec 4.1: "This field is bidirectional and MUST be elided during the
> SCHC compression". This is a dangerous statement as it leads us
> straight into CoAP ossification territory.  If you want SCHC to work
> with CoAP v1 only what you really want to say here is "SHCH
> compression MUST NOT be applied to CoAP packets with version different
> from v1".  Granted that, a SCHC box deployed today could sit in the
> field happily ever after.  If not, when a new CoAP version is rolled
> out, endpoints wouldn’t be able to use this new version on any path
> crossing an SCHC box.
>

We don't think this will create ossification. The rule is very flexible and
do not force to elide this field at any time. For instance, if you have a
device that is CoAP v1 only, then you can elide the field.

During a transition period if the device accepts CoAP v1 and v2, then the
rule can be
set to MO=ignore and CDA=value-sent. Or a rule for v1 and a rule for v2 can
be used.
In anycase the device will receive the appropriate CoAP version after
decompression.

Laurent and Ana


>
> Cheers!
>
> _______________________________________________
> lp-wan mailing list
> lp-wan@ietf.org
> https://www.ietf.org/mailman/listinfo/lp-wan
>

v2.23.0 | Report a Bug | By Email