Re: [lp-wan] Magnus Westerlund's Discuss on draft-ietf-lpwan-coap-static-context-hc-13: (with DISCUSS and COMMENT)

[Ana Minaburo <[e-mail]>]

Dear Magnus,

Thank you for your review, please see my comments below.

Ana

On Thu, Mar 12, 2020 at 11:00 AM Magnus Westerlund via Datatracker <
[e-mail]> wrote:

> Magnus Westerlund has entered the following ballot position for
> draft-ietf-lpwan-coap-static-context-hc-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Reviewing this document and its application to compress case two and three
> stacks in Figure 1, i.e. with some end-to-end encryption appears to
> significantly change an assumption from the SCHC for IPv6/UDP. Namely, the
> assumption about context establishment. In normal SCHC the contexts are
> established between the Device and the NGW. In these end-to-end encrypted
> case
> the context establishing party for the COAP compression is the APP and the
> APP
> layer in the device. This difference appear completely ignored in this
> document. I think this is a significant difference as having the device
> and NGW
> run a protocol for establishing context over the L2 or L3 with the local
> context knowledge is fairly straightforward. However, in this case when the
> COAP peer on the internet side of the NGW this determination and
> configuration
> is a different matter.
>
> >From my perspective some more discussion of the fact that this is a
> different
> context and that it have different challenges in establishing the context
> should be made clear in the document.
>

Ana: Your question is very important for the deployment of SCHC over
different networks, but the context establishment is out of the scope of
this document.
This proposal concerns the way the CoAP header fields may be compressed
using SCHC and how a developer can use the SCHC features to reduce the CoAP
header.
I've added a sentence in the introduction part, here is the new text:

SCHC compresses and decompresses headers based on shared contexts between
devices. *The way the Contexts are provisioned is out of the scope of this
document. *Each context consists of multiple Rules. Each rule can match
header fields and specific values or ranges of values. If a rule matches,
the matched header fields are substituted by the rule ID and optionally
some residual bits. Thus, different Rules may correspond to different types
of packets that a device expects to send or receive.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I would also note that the TSV-ART review did find an issue with the an
> underlying assumption in draft-ietf-lpwan-ipv6-static-context-hc which is
> not
> yet published. The issue is that the assumption that the UDP length field
> is
> redundant will not be true when
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ gets
> approved.
> Thus the question arises if this assumption should be amended or not in the
> underlying technology. I note this here primarily so that it is discussed
> by
> the WG and the responsible AD.
>
>
> Ana: As explained in Dominique's mail, the use of SCHC for this new option
in UDP does not affect or modify the SCHC protocol.

Ana