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

[<[e-mail]>]

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 »
<[e-mail] on behalf of [e-mail]> a écrit :

>Hi Laurent, Ana,
>
>On Tue, Jun 11, 2019 at 3:16 PM Laurent Toutain
><[e-mail]> wrote:
>> On Thu, May 30, 2019 at 1:53 PM Thomas Fossati <[e-mail]>
>>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
>> > 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.
>
>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
>
>_______________________________________________
>core mailing list
>[e-mail]
>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.