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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 12 Mar 2020 03:00:49 -0700

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.

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

---

From: Ana Minaburo <[email-masked]>
Date: Thu, 19 Mar 2020 12:02:45 +0100

Dear Magnus,

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

Ana

> https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/

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.

> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Mar 2020 14:32:34 +0000

On Thu, 2020-03-19 at 12:02 +0100, Ana Minaburo wrote:
> 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.
> 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. 

So the reason I raised a discuss on this is that it change of the architecture
and impacts a different set of nodes compared to what is described in draft-
ietf-lpwan-ipv6-static-context-hc. So although the conext establishment is out
of scope, the requirement for context establishment has additional requirements
that are not discussed due to the change in architecture. 

I would propose to add a discussion of these architectural requirements in
Section 2 and possibly have an additional figure that discusses the fact that
the peer node may actually not be the same between inner and outer set of
context. 

Does the above make my issue clearer? 

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

Yes, the UDP length is an issue with the other document and is not directly
coupled to this document. That was also the reason for me putting this in a
comment. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------