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

From: Olivier Gimenez <[email-masked]>
Date: Wed, 3 Feb 2021 11:59:55 +0000

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 <[email-masked]> On Behalf Of Alexander Pelov
Sent: 19 January 2021 12:36
To: lp-wan <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Jan 19, 2021 at 12:17 PM
Subject: New Version Notification for draft-pelov-lpwan-architecture-00.txt
To: Alexander Pelov <[email-masked]<mailto:[email-masked]>>, Ana Minaburo <[email-masked]<mailto:[email-masked]>>, Pascal Thubert <[email-masked]<mailto:[email-masked]>>

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<http://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.

---

From: Alexander Pelov <[email-masked]>
Date: Mon, 15 Feb 2021 09:52:52 +0100

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 <[email-masked]> wrote:

> *1.  Introduction*
> 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”.
>
> * ***The SCHC instance at application layer is can**** be split in two
> instances **as**** encryption hides the field
>
> structure.
>
>
>
> *2.  Definitions*
> *3.  Global architecture*
> 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”.
>
>
>
> *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*
>
> 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 rule manager *can* use Internet, it is not mandatory
>
>
>
> CORECONF is used *as* [I-D.ietf-lpwan-coap-static-context-hc] can be *
> *employed**.
>
>
>
> Olivier
>
>
>
> *From:* lp-wan <[email-masked]> *On Behalf Of *Alexander Pelov
> *Sent:* 19 January 2021 12:36
> *To:* lp-wan <[email-masked]>
> *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.
>
> On Tue, Jan 19, 2021 at 12:22 PM Alexander Pelov <[email-masked]> 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.
>
>
>
> From: <[email-masked]>
> To: Alexander Pelov <[email-masked]>, Ana Minaburo <[email-masked]>, Pascal
> Thubert <[email-masked]>
>
>
>
>
> 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:
> 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.
>