Re: [lp-wan] Martin Duke's No Objection on draft-ietf-lpwan-schc-over-lorawan-12: (with COMMENT)

[Olivier Gimenez <[e-mail]>]

Hi Martin,

Just to let you know that we reverted to SCHC Message terminology for figure 5 after Dominique’s feedback, but we now define it.

Best regards
Olivier

The FPort field is part of the SCHC Message, as shown in {{Fig-lorawan-schc-payload}}. The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with the LoRaWAN payload to recompose the SCHC Message.

| FPort | LoRaWAN payload  |
+ ------------------------ +
|       SCHC Message       |

{: #Fig-lorawan-schc-payload title='SCHC Message in LoRaWAN'}
Note: SCHC Message is any datagram sent by SCHC C/D or F/R layers.


From: Martin Duke <[e-mail]>
Sent: 28 October 2020 15:34
To: Olivier Gimenez <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Dominique Barthel <[e-mail]>
Subject: Re: Martin Duke's No Objection on draft-ietf-lpwan-schc-over-lorawan-12: (with COMMENT)
Sounds good! thanks for the changes.

On Wed, Oct 28, 2020 at 7:32 AM Olivier Gimenez <[e-mail]<mailto:[e-mail]>> wrote:

Dear Martin,



Thank you for your feedback, I answered inline to your comments



Best regards

Olivier



> -----Original Message-----

> From: Martin Duke via Datatracker <[e-mail]<mailto:[e-mail]>>

>

>

> ----------------------------------------------------------------------

> COMMENT:

> ----------------------------------------------------------------------

>

> I found this document to be very tough going without reading through RFC8724.

>

> - I am not sure what Fig. 5 depicts. Does this mean that an "SCHC Packet" is a

> subset of an "SCHC Message", prepended by the Fport and LoRaWan payload?

> Because Fig. 4 of RFC 8724 says an "SCHC Packet" consists of a "Payload"

> prepended by the Rule ID (which corresponds to the FPort) and "Compression

> Residue". Please align the terminology!



[OG] Thank you for this cath. Figure 5 title and its introduction should be SCHC Packet instead of SCHC Message.

I also described what is composing the "LoRaWAN payload". Commit 78ee6f8<https://github.com/Acklio/schc-over-lorawan/commit/78ee6f83dd646bc19d4224494d92e500254ae21e>



> - There are numerous terms from 8724 that could use a brief definition here on

> first use: for example RuleID, MSB, RX1, RX2, and IID.



[OG] RuleID and IID: I have been asked to remove terminology present in RFC8724 from the SCHC over LoRaWAN draft.

Nevertheless I added, MSB, RX, RX1/RX2 in commit  eadd014<https://github.com/Acklio/schc-over-lorawan/commit/eadd014d96c476d1842954e3d75243c797bd8258>





> - Sec 5.6.2:

>    For battery powered devices, it is RECOMMENDED to use the ACK

>    mechanism at the end of each window instead of waiting until the end

>    of all windows...

>

>    For non-battery powered devices, the SCHC receiver MAY also choose to

>    send a SCHC ACK only at the end of all windows.  This will reduce

>    downlink load on the LoRaWAN network, by reducing the number of

>    downlinks.

>

> This text is ambiguous. For example, the first paragraph can be interpreted as

> "battery-powered devices SHOULD send an ACK at the end of each window,

> instead of waiting till the end of all windows", or "endpoints sending to battery-

> powered devices SHOULD send an ACK at the end of each window...."



[OG] We are in the section " Uplink fragmentation: From device to SCHC gateway"  where introduction define:

"the device is the fragment transmitter, and the SCHC gateway the fragment receiver"

so it cannot be "endpoints sending to battery-powered devices"



> To the

> layman, it is a little odd that the non-battery-powered devices are more

> encouraged to send fewer messages! Some explanatory text would be useful.



[OG] Ok, I explained it in commit bfe0c82<https://github.com/Acklio/schc-over-lorawan/commit/bfe0c82ea2be008076bb1ed126412784714bdbe7>: "This will avoid useless uplinks if the device has lost network coverage."





> - Sec 5.6.5.3.1

> "All fragments but the last have an FCN=0

>    (because window size is 1).  Following it, the device MUST transmit

>    the SCHC ACK message."

>

> What is "it"? All fragments, or the FCN=1 fragment?



[OG] The All-0 SCHC Fragment (ie FCN=0). Changed in commit 81a9b24<https://github.com/Acklio/schc-over-lorawan/commit/81a9b24888b7d94c848aef88d030ea9e6d0b4fb6>





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>.

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.