IETF Logo Mail Archive

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

Thomas Fossati <tho.ietf@gmail.com> Mon, 24 June 2019 18:15 UTC

Return-Path: <tho.ietf@gmail.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 0DFC11201EA; Mon, 24 Jun 2019 11:15:47 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 o50KZKpSCIsM; Mon, 24 Jun 2019 11:15:43 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A906120119; Mon, 24 Jun 2019 11:15:42 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id j6so3046978ioa.5; Mon, 24 Jun 2019 11:15:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wwVZvEt3A3NxeeMpCd0VTH5at870efadmnhhs9npHYE=; b=VuwvBD8nr5a2byXgwEvOi4VxWlzSxz7ABQE6UvmPrTUQiJPcIC7BL59SYfmfycP+SK /gAcIYEgtcyR02IAjPsnQJZTj0kzs52fmSgajC9UqDvptiz8FLcaT2tjIFk0TXEfAVb7 /V4VD1nTY0rpWU5ky29f/H9ysngFDXlG9HFaJV4OrKsEkSGHpu3zXuP3DE0Rj3DM5ZOd REXBhFTpFYecwr4/97y1RXJGJCOw5nRLKDcYj+NB0Mdl1+4Fl11AIvxT1+k7tCidy20Y fVOSE9Hx1VnWPOXj+I1chk14PaI+E3azoFhz9lynq83YWKl3J2NKpuozbmjSmxTD4mTT WVIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wwVZvEt3A3NxeeMpCd0VTH5at870efadmnhhs9npHYE=; b=O0bLkvvgWUyyrKVfP7OZfRW99Kdm6wnWVUMGnkpOgL1XuRlWYZSKuwXdPc6b8Rsb7a mXTE0gT8I89R6juOdQLjVDEy9vXwACfXR8qQXnMVrqSgU2dQNG2DhD2Zgp1n7H4ybdIi cRFuDG+3G+gxFWGnbyOe/WJSgKcZXFOR5cTvqaj6oFgJ+9ZE9Sb3XgJd07LuqxKoGnV2 9YbqqZoBxYZHSg93pF05D4WFpeUWymUBFromXyTbvWr7mS5Io0Wjsm42wgIk6LCHj5Ef ZAneluy76sn7G3W+XUqAYyCHwMn+Uvq7hKGPt8rpbveKI13eLsj9s7nkqSGdWdgmAXgk l5HQ==
X-Gm-Message-State: APjAAAWqjr6AJDfI07i7twfX98t8UqTG6KN/k9khU+wcOPpVcTxEcs/X NsVyeGFuyio3HX82VG+pZwanhLrurbZPM3Q2/4o=
X-Google-Smtp-Source: APXvYqywUV/1poxiFrQcu8E1AhMpy6Ggd2z+UKLn10HxKMGyDtGHz62qWj9eE1WxGWtnj8xGafqigDjP0ygQco53rMc=
X-Received: by 2002:a6b:6012:: with SMTP id r18mr1203751iog.241.1561400141644; Mon, 24 Jun 2019 11:15:41 -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> <CABONVQb+Kgtb7AaJzJTzH0sYFUHxfRj9VWuWksn39GkKBEKbRg@mail.gmail.com> <CAObGJnPYof2=HthyQFQxT90+we0XVrJNJPa2Z_0fbsXuTo_sKA@mail.gmail.com> <22977_1561391276_5D10F0AB_22977_316_1_D936BC6F.62710%dominique.barthel@orange.com>
In-Reply-To: <22977_1561391276_5D10F0AB_22977_316_1_D936BC6F.62710%dominique.barthel@orange.com>
From: Thomas Fossati <tho.ietf@gmail.com>
Date: Mon, 24 Jun 2019 19:15:30 +0100
Message-ID: <CAObGJnNWCFnfqdfiRxk86Qo7jg1ApKFppoU2bMsxghZJUJrpAQ@mail.gmail.com>
To: dominique.barthel@orange.com
Cc: Laurent Toutain <laurent.toutain@imt-atlantique.fr>, lp-wan <lp-wan@ietf.org>, "core@ietf.org WG" <core@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/B0nKWoNoKIyS6UbVsNM2kdX_QDo>
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: Mon, 24 Jun 2019 18:15:47 -0000

Hey Dominique,

On Mon, Jun 24, 2019 at 4:47 PM <dominique.barthel@orange.com> wrote:
> Speaking under the control of Laurent, here's my answer.

:-)

> By default, SCHC transmits in uncompressed form those messages it doesn't
> file compression rules for.
> The set of compression rules proposed by Laurent matches the current
> version of CoAP.
> Therefore, a message bearing a different (i.e. future) version of CoAP
> will not be matched by the current set of rules, therefore it will be sent
> uncompressed.
> Does that clear out your doubts?

So, IIUC, given the current vocabulary a network operator deploying /
configuring the box has absolutely zero chance (even by accident) of
becoming an ossifier?

If so, excellent, I’m very happy!

If instead there is a residual chance of composing a ruleset such that
that wouldn't be the case, the document should contain advice on how
to avoid the situation to arise.

In fact, to avoid all doubts & to ease future stages of review on this
point, I'd suggest you add an explicit "ossification / operations
considerations" section where you capture this conversation and
explain exactly what are SCHC key design features that avoid creating
surface for blocking protocol evolution.

(Sorry to insist so much on this aspect, but I think making it an
explicit discussion point in the document is really important.)

v2.23.0 | Report a Bug | By Email