Re: [lp-wan] New Version Notification for draft-pelov-lpwan-architecture-00.txt

[Alexander Pelov <[e-mail]>]

Dear Olivier,

Thanks for the feedback !

I'll try to push the changes for tomorrow.

Cheers,
Alex


On Wed, Feb 3, 2021 at 1:00 PM Olivier Gimenez <[e-mail]> wrote:

> Hi Alex,
>
>
>
> Thank you for the document. Here are my comments:
>
>
>
> *1.  Introduction*
>
> For instance, as represented figure Figure 1
>
> The first word “figure” should be removed
>
>
>
> For instance, as represented figure Figure 1, IP compression and
>
> fragmentation may be managed by the network SCHC instance and end-to-
>
> end compression between the device and the application. The former
>
> can itself be split in two instances since encryption hides the field
>
> structure.
>
>
>
> I think that “can itself be split in two instances “ applies to the SCHC
> instance in the App, not in network layer so “former” should be “latter”.
>
> Nevertheless it might be better to be explicit there:
>
> * ***The SCHC instance at application layer is can**** be split in two
> instances **as**** encryption hides the field
>
> structure.
>
>
>
> Figure1: There is a type in “Network SCHC”, it is written “CSHC”
>
>
>
> the LPWAN woeking group
>
> Typo: in “working”
>
>
>
>
>
> *2.  Definitions*
>
> If the chapter is empty, should we remove it?
>
> Otherwise I think that we should reference the RFC8376
>
>
>
> *3.  Global architecture*
>
> If SCHC compressed packet is too large to be send in a single L2
>
>    frame, fragmentation will apply
>
>
>
> Compression might not always apply, it has to be defined in the
> LPWAN-over-foo profile. So I would change the “will apply” in “can apply”.
>
>
>
> On the other direction, when a packet SCHC arrives, the ruleID is
>
> used to find the rule.
>
> “packet SCHC” => “SCHC packet”
>
>
>
> Its nature allows to select if it is a
>
> compression or fragmentation rule.
>
> I am not sure that it works as described, but rather:
>
> *The SCHC Reassembly checks if the SCHC packet rule match its own table:*
>
> *- If it does: it reassembles the fragments before providing the
> reassemble SCHC message to the SCHC Decompressor*
>
> *- Otherwise: the SCHC packet is directly provided to the SCHC
> Decompressor*
>
> Cf RFC8724 figure 3. It might worth to copy all figure 3 and its
> associated comment.
>
>
>
> Figure 2:
>
> I think that F/R and C/D should be split and not at the same level
>
> Please use “rules” instead of “r”, easier to understand
>
>
>
> To enable rule synchronization between both ends, a common rule
>
>    representation must be defined.
>
> Should we explicitly mention that this synchronisation is not (yet)
> defined ? I had this question several times while writing SCHC-over-LoRaWAN
>
>
>
>
>
> Figure 3: The figure is not clear to me: again the C/D and F/R are mixed,
> and we should draw the Device and the App
>
>
>
> The RM is a application using the Internet to exchange information,
>
>    therefore:
>
> The rule manager *can* use Internet, it is not mandatory
>
>
>
> The RM traffic may be itself compressed by SCHC, especially if
>
>    CORECONF is used, [I-D.ietf-lpwan-coap-static-context-hc] can be
>
>    used.
>
> If feel it confusing, maybe:
>
> The RM traffic may be compressed by SCHC, especially if
>
> CORECONF is used *as* [I-D.ietf-lpwan-coap-static-context-hc] can be *
> *employed**.
>
>
>
> Olivier
>
>
>
> *From:* lp-wan <[e-mail]> *On Behalf Of *Alexander Pelov
> *Sent:* 19 January 2021 12:36
> *To:* lp-wan <[e-mail]>
> *Subject:* Re: [lp-wan] New Version Notification for
> draft-pelov-lpwan-architecture-00.txt
>
>
>
> Dear all,
>
>
>
> For a full disclosure, Acklio might potentially have an IPR related to
> section 4 of the SCHC Architecture draft. Please keep in mind that I am not
> a lawyer.
>
> We'll be following standard IETF practices for the licensing terms.
>
>
>
> Best regards,
>
> Alexander
>
>
>
>
>
>
>
> On Tue, Jan 19, 2021 at 12:22 PM Alexander Pelov <[e-mail]> wrote:
>
> Dear all,
>
>
>
> With our second meeting in this new year, we wanted to start the
> discussion on one of the topics we've been having for some time now - the
> SCHC Architecture.
>
>
>
> An initial draft was submitted and we can discuss it and the evolution
> during the interim today.
>
>
>
> Cheers,
>
> Pascal, Ana and Alex
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Tue, Jan 19, 2021 at 12:17 PM
> Subject: New Version Notification for draft-pelov-lpwan-architecture-00.txt
> To: Alexander Pelov <[e-mail]>, Ana Minaburo <[e-mail]>, Pascal
> Thubert <[e-mail]>
>
>
>
>
> A new version of I-D, draft-pelov-lpwan-architecture-00.txt
> has been successfully submitted by Alexander Pelov and posted to the
> IETF repository.
>
> Name:           draft-pelov-lpwan-architecture
> Revision:       00
> Title:          Static Context Header Compression (SCHC) Architecture
> Document date:  2021-01-19
> Group:          Individual Submission
> Pages:          6
> URL:
> https://www.ietf.org/archive/id/draft-pelov-lpwan-architecture-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pelov-lpwan-architecture/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pelov-lpwan-architecture
> Htmlized:
> https://tools.ietf.org/html/draft-pelov-lpwan-architecture-00
>
>
> Abstract:
>    This document defines the SCHC architecture.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> To view our privacy policy, including the types of personal information we
> collect, process and share, and the rights and options you have in this
> respect, see www.semtech.com/legal.
>