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

[Magnus Westerlund <[e-mail]>]

Hi,

Good to here the that the WG discussed this. It sounds like the proposed
direction should resolve the issue. Looking forward to reviewing the updated
draft. 

Cheers

Magnus Westerlund

On Tue, 2020-04-28 at 21:53 +0200, Ana Minaburo wrote:
> Dear Magnus,
> 
> We have raised your point during the last virtual IETF meeting last week, the
> WG agrees that the context establishment is out of the scope of this document
> but it becomes mandatory for each technology document to define the way the
> context is established. The CoAP document will create an extension to Appendix
> D of RFC8724 and I will add this point.
> 
> We will add in Section 2 a note about these architectural requirements as you
> suggest.
> 
> A new version of the draft will be published soon with these changes.
> 
> Thanks again for your Review, 
> 
> Ana, Laurent & Ricardo.
> 
> On Thu, Mar 19, 2020 at 3:32 PM Magnus Westerlund <
> [e-mail]> wrote:
> > 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]
> > ----------------------------------------------------------------------
> > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------