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

[Magnus Westerlund <[e-mail]>]

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

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? 

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

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  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------