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

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 »
<lp-wan-bounces@ietf.org on behalf of ogimenez@semtech.com> 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 <lp-wan-bounces@ietf.org> On Behalf Of internet-
>> drafts@ietf.org
>> Sent: 17 April 2020 16:33
>> To: i-d-announce@ietf.org
>> Cc: lp-wan@ietf.org
>> 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
>> lp-wan@ietf.org
>> 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
>lp-wan@ietf.org
>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.