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

From: Martin Duke via Datatracker <[email-masked]>
Date: Mon, 26 Oct 2020 18:24:50 -0700

Martin Duke has entered the following ballot position for
draft-ietf-lpwan-schc-over-lorawan-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-lorawan/

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

- There are numerous terms from 8724 that could use a brief definition here on
first use: for example RuleID, MSB, RX1, RX2, and IID.

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

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

---

From: Olivier Gimenez <[email-masked]>
Date: Wed, 28 Oct 2020 14:32:28 +0000

Dear Martin,

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

Best regards

Olivier

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

> From: Martin Duke via Datatracker <[email-masked]>

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

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

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

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

---

From: Martin Duke <[email-masked]>
Date: Wed, 28 Oct 2020 07:34:18 -0700

Sounds good! thanks for the changes.

On Wed, Oct 28, 2020 at 7:32 AM Olivier Gimenez <[email-masked]>
wrote:

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

---

From: Olivier Gimenez <[email-masked]>
Date: Thu, 29 Oct 2020 16:15:27 +0000

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 <[email-masked]>
Sent: 28 October 2020 15:34
To: Olivier Gimenez <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Dominique Barthel <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Dear Martin,

Best regards

Olivier

> From: Martin Duke via Datatracker <[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>.