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

[Thomas Fossati <[e-mail]>]

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