Subject: Re: [lp-wan] FW: I-D Action: draft-ietf-lpwan-schc-over-lorawan-07.txt

From: <[email-masked]>
Date: Thu, 7 May 2020 10:25:49 +0000

Hello Olivier,

I quickly reviewed the changes from -06 to -07.
I have the following minor comments:

Section 5.6.2 "For non-battery powered devices, SCHC receiver MAY also
choose to"
The above line is not crystal clear. It could mean "Non-battery powered
devices acting as SCHC receivers MAY ...".
I know you mean "When a non-battery powered device acts as a SCHC sender,
the SCHC receiver …", because this is Section 5.6.2 Uplink fragmentation.
I suggest that in Section 5.6.2, we have

"For battery powered devices acting as SCHC sender, it is RECOMMENDED … "
"Non-battery powered devices acting as SCHC receivers MAY …"

Section 5.6.2.2
We now have the option of sending the last tile with the All-1 Fragment.
There should be an optional tile shown in Fig 8, or a Fig 9 added with a
tile present and text explaining that both cases are possible.

Section 5.6.2.3
Fig 9 says 0 to 63 bits of bitmap. Actually, only a few discrete values
for the number of bits are possible. Is it worth spelling them out? So
that readers dont think padding will be needed?

Section 5.6.3.2
Figure 13 does not show a payload.
RFC8724, Section 8.4.2 ACK-Always mode, says "The SCHC Fragment that
carries the last tile MUST be an All-1 SCHC Fragment".
What is your intention? That the All-1 Fragment never carries a payload?
Or is it just a copy-paste from 5.6.2.2?
By the way, Fig 31 in A.3 does show a payload.
By the way, Fig 31 and Fig 32 incorrectly say "Uplink example".

The terms "device", "end-device", "Dev" are used in various places. Same
for "server", etc. I think we should align terminology to that used in
RFC8376.

I submitted two Pull Requests with a few additional minor nit fixes.

Best regards,

Dominique

Le 17/04/20 16:43, « lp-wan on behalf of Olivier Gimenez »
<[email-masked] on behalf of [email-masked]> a écrit :

>Dear,
>
>We just published a new draft. Main changes are:
>
>  *  ACK behaviour has been reworded
>  *  Changed reference from I-D.ietf-lpwan-ipv6-static-context-hc to
>RFC8724
>  *  Fix some typos
>
>As usual, full commit list is available
>https://github.com/Acklio/schc-over-lorawan/commits/draft-ietf-lpwan-schc-
>over-lorawan-07
>
>
>
>Best regards
>Olivier
>
>> -----Original Message-----
>> From: lp-wan <[email-masked]> On Behalf Of internet-
>> [email-masked]
>> Sent: 17 April 2020 16:33
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [lp-wan] I-D Action: draft-ietf-lpwan-schc-over-lorawan-07.txt
>> 
>> Warning - External Email
>> ________________________________
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>> This draft is a work item of the IPv6 over Low Power Wide-Area Networks
>> WG of the IETF.
>> 
>>         Title           : Static Context Header Compression (SCHC) over
>>LoRaWAN
>>         Authors         : Olivier Gimenez
>>                           Ivaylo Petrov
>>         Filename        : draft-ietf-lpwan-schc-over-lorawan-07.txt
>>         Pages           : 25
>>         Date            : 2020-04-17
>> 
>> Abstract:
>>    The Static Context Header Compression (SCHC) specification describes
>>    generic header compression and fragmentation techniques for LPWAN
>>    (Low Power Wide Area Networks) technologies.  SCHC is a generic
>>    mechanism designed for great flexibility so that it can be adapted
>>    for any of the LPWAN technologies.
>> 
>>    This document provides the adaptation of SCHC for use in LoRaWAN
>>    networks, and provides elements such as efficient parameterization
>>    and modes of operation.  This is called a profile.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-lorawan/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-lpwan-schc-over-lorawan-07
>> 
>>https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-schc-over-lorawan-
>>07
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lpwan-schc-over-lorawan-07
>> 
>> 
>> 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.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> _______________________________________________
>> lp-wan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lp-wan
>
>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.
>
>_______________________________________________
>lp-wan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lp-wan

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Olivier Gimenez <[email-masked]>
Date: Fri, 15 May 2020 14:13:21 +0000

Hi Dominique,

Thank you for your comments and pull requests. I answered in your email and updated the draft:

https://github.com/Acklio/schc-over-lorawan/blob/draft-ietf-lpwan-schc-over-lorawan-08/draft-ietf-lpwan-schc-over-lorawan.md

Best regards

Olivier

> From: [email-masked] <[email-masked]>

> I know you mean "When a non-battery powered device acts as a SCHC

> sender, the SCHC receiver …", because this is Section 5.6.2 Uplink

> fragmentation.

> "For battery powered devices acting as SCHC sender, it is RECOMMENDED …

> "

> "Non-battery powered devices acting as SCHC receivers MAY …"

[OG] Updated as discussed, see ccb3aea<https://github.com/Acklio/schc-over-lorawan/commit/ccb3aea8b36148be3c1ebf156dbdedb92888741f>

> There should be an optional tile shown in Fig 8, or a Fig 9 added with a tile

> present and text explaining that both cases are possible.

[OG] Fixed, see 885d4c9<https://github.com/Acklio/schc-over-lorawan/commit/885d4c9d43f8dd791f617ceb2585ba175cbab77d>

> Fig 9 says 0 to 63 bits of bitmap. Actually, only a few discrete values for the

> number of bits are possible. Is it worth spelling them out? So that readers

> dont think padding will be needed?

[OG] Fixed, see 04e976c<https://github.com/Acklio/schc-over-lorawan/commit/04e976c580cdb07d22262b4941c513c8c8c9171a>

> Figure 13 does not show a payload.

[OG] Fixed, see 04cb13d<https://github.com/Acklio/schc-over-lorawan/commit/04cb13d4da81f811a0f48cfe564f5e661243fa33>

> The terms "device", "end-device", "Dev" are used in various places. Same for

> "server", etc. I think we should align terminology to that used in RFC8376.

[OG] Fixed, see 9e300f7<https://github.com/Acklio/schc-over-lorawan/commit/9e300f780c92bc1b27a89922c721513a1cd278d6> and 0bb8dbd<https://github.com/Acklio/schc-over-lorawan/commit/0bb8dbd133b7717a4066b952c1026c9a49415ea7>

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: Julien CATALANO <[email-masked]>
Date: Fri, 15 May 2020 22:32:49 +0200

Dear Olivier, dear LPWAN'ers,

Thank you Olivier for bringing this document forward!

In this latest git update, you changed the nomenclature used in the
draft, moving away from LoRaWAN namings. [1] [2]

IMHO, in the context of LoRaWAN, we should keep the LoRaWAN
nomenclature. This document addresses LoRaWAN implementers, we should
talk their language.

I would like draft-ietf-lpwan-schc-over-lorawan to use the terms
"end-device" and "Network Server", especially when used in the context
of LoRaWAN, but also as much as possible, instead of the SCHC terms
"Device (Dev)" and "Network Gateway".

We obviously need to keep the links between those terms in the text, as
done in -07 section 4 "LoRaWAN Architecture".

Any advice from the group?

Thank you
Julien

[1]
https://github.com/Acklio/schc-over-lorawan/commit/0bb8dbd133b7717a4066b952c1026c9a49415ea7
[2]
https://github.com/Acklio/schc-over-lorawan/commit/9e300f780c92bc1b27a89922c721513a1cd278d6

Le 15/05/2020 à 16:13, Olivier Gimenez a écrit :
> [OG] Updated as discussed, see ccb3aea
> <https://github.com/Acklio/schc-over-lorawan/commit/ccb3aea8b36148be3c1ebf156dbdedb92888741f>
>
>  
>
> > Section 5.6.2.2
>
> [OG] Fixed, see 885d4c9
> <https://github.com/Acklio/schc-over-lorawan/commit/885d4c9d43f8dd791f617ceb2585ba175cbab77d>
>
>  
>
> > Section 5.6.2.3
>
> [OG] Fixed, see 04e976c
> <https://github.com/Acklio/schc-over-lorawan/commit/04e976c580cdb07d22262b4941c513c8c8c9171a>
>
>  
>
> > Section 5.6.3.2
>
> [OG] Fixed, see 04cb13d
> <https://github.com/Acklio/schc-over-lorawan/commit/04cb13d4da81f811a0f48cfe564f5e661243fa33>
>
>  
>
> [OG] Fixed, see 9e300f7
> <https://github.com/Acklio/schc-over-lorawan/commit/9e300f780c92bc1b27a89922c721513a1cd278d6>
> and 0bb8dbd
> <https://github.com/Acklio/schc-over-lorawan/commit/0bb8dbd133b7717a4066b952c1026c9a49415ea7>
>
>  
>
>  
>
>
> 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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 16 May 2020 05:09:29 +0000

Hello Julien:

The mapping of terms must be very clearly indicated early in the document. But from then on this is an LPWAN document being worked on and published by LPWAN so it must speak the LPWAN language.

Considering that we have a simple one to one mapping that should not be an issue for an implementer. I expect that the functional specs would already be ‘translated’.

Keep safe,

Pascal

Le 15 mai 2020 à 22:33, Julien CATALANO <[email-masked]> a écrit :

In this latest git update, you changed the nomenclature used in the draft, moving away from LoRaWAN namings. [1] [2]

IMHO, in the context of LoRaWAN, we should keep the LoRaWAN nomenclature. This document addresses LoRaWAN implementers, we should talk their language.

I would like draft-ietf-lpwan-schc-over-lorawan to use the terms "end-device" and "Network Server", especially when used in the context of LoRaWAN, but also as much as possible, instead of the SCHC terms "Device (Dev)" and "Network Gateway".

We obviously need to keep the links between those terms in the text, as done in -07 section 4 "LoRaWAN Architecture".

Thank you
Julien

[1] https://github.com/Acklio/schc-over-lorawan/commit/0bb8dbd133b7717a4066b952c1026c9a49415ea7
[2] https://github.com/Acklio/schc-over-lorawan/commit/9e300f780c92bc1b27a89922c721513a1cd278d6

Hi Dominique,

Best regards

Olivier

> From: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

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<http://www.semtech.com/legal>.

_______________________________________________
lp-wan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lp-wan