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

From: Laurent Toutain <[email-masked]>
Date: Tue, 11 Jun 2019 16:16:13 +0200

Hi Thomas,

Thank you for your comments and changes in the github.

On Thu, May 30, 2019 at 1:53 PM Thomas Fossati <[email-masked]> wrote:

> Hi Laurent,
>
> On Wed, May 29, 2019 at 6:56 PM Laurent Toutain
> <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
>

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 11 Jun 2019 23:11:58 +0100

Hi Laurent, Ana,

On Tue, Jun 11, 2019 at 3:16 PM Laurent Toutain
<[email-masked]> wrote:
> > - Sec 4.1: "This field is bidirectional and MUST be elided during
> > the SCHC compression". This is a dangerous statement as it leads us
> > 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.

Thanks for taking the time to explain.

However, I'm still a bit unsure about what is story for supporting
protocol upgrade / evolution, so please let me rephrase my concern and
you can clear all my doubts :-)

Does the spec in its current form provide the guarantee that a middlebox
that is deployed today and never updated (or updated on a different time
scale with respect to the endpoints) will not interfere with versions of
the protocol it doesn't understand?  Otherwise said: what is the default
behaviour of a SCHC entity when handling unknown semantics?

cheers, thanks, t

---

From: <[email-masked]>
Date: Mon, 24 Jun 2019 15:47:55 +0000

Hello Thomas,

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?
Best regards

Dominique

Le 12/06/19 00:11, « core on behalf of Thomas Fossati »
<[email-masked] on behalf of [email-masked]> a écrit :

>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 24 Jun 2019 19:15:30 +0100

Hey Dominique,

> Speaking under the control of Laurent, here's my answer.

:-)

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