Re: [Iot-directorate] Iotdir telechat review of draft-ietf-lpwan-schc-over-lorawan-10

[Olivier Gimenez <[e-mail]>]

Thank you for your feedback. I replied in your email

Olivier

From: Rahul Jadhav <[e-mail]>

[RJ] Actually for me fig 3 was very helpful. However, there is big friction to understand and relate the terms from the text section to that with the figure. One way to handle this is to mention both the terms, keeping the RFC 8376 terms in brackets, and explicitly stating the origin of those terms as a note in the figure.

[OG] Ok, I added them in 2e6aed7<https://github.com/Acklio/schc-over-lorawan/commit/2e6aed7f44fc75f99753b520cd9799c103d0cec3>



> Section 4.1:

> "The lower the downlink latency, the higher the power consumption."
[RJ] Works. However, check minor nits raised as a review comment in the corresponding commit.

[OG] Thanks, fixed in 509d679<https://github.com/Acklio/schc-over-lorawan/commit/509d6796ebf932f8a43417cc569462511d52916f>


> Section 5.1:
[RJ] I did not find any statement in Section 5.2 which says that the "FPortUp must be different that FPortDown".  Which statement are you referring to?

[OG] Sorry it was not explicit in the document. I added it in a9bd3f9<https://github.com/Acklio/schc-over-lorawan/commit/a9bd3f9029bc8b165648c748f85b8352ffa03fa2>:
FPortUp value MUST be different from FPortDown



> Section 5.2:

> "RuleID = 22 (8-bit) for which SCHC compression was not possible..."

[OG] Its aim is to be used when no compression rule is defined more that when the

device wants to send uncompressed IPv6. Should I change it to the description of RFC8724:

for  which SCHC compression was not possible (i.e., no matching

         compression Rule was found).

?
[RJ] I am not sure which description of RFC 8724 are you referring to. Can you please quote the section etc?

[OG] Ok, added in commit beb0dd6<https://github.com/Acklio/schc-over-lorawan/commit/beb0dd6a315ee248d9d995327c19e8e1c390e3e8>:
RuleID = 22 (8-bit) for which SCHC compression was not possible
      (i.e., no matching compression Rule was found), as described in  [RFC8724] section 6.





> Section 5.3:

> "There is a small probability of IID collision in a LoRaWAN network, if such

> event occurs the IID can be changed by rekeying the device on L2 level (ie:

> trigger a LoRaWAN join)." [RJ] As I understand, IID collision can be detected

> only by the Network Gateway. How would the Network Gateway initiate a

> LoRaWAN join? Section 4.4 defines that only the end device can initiate a

> JoinRequest frame.



[OG] It has been discussed by the working group and the consensus have been that

it should be defined by the application if the IID collision is a concern in the

application (collision risk grows with the number of devices in a network)



[OG] For your information Section 4.4 does says that the joinRequest is send by

a device but not how it is triggered. In LoRaWAN v1.1, NGW is able to trigger a

new joinRequest of a connected device.
 [RJ] Collision can only be detected on the NGW. If LoRaWAN v1.1 can handle it from NGW, an implementer should know. I see that lora-spec v1.1 is not mentioned in informative ref. Is this spec available in public? If yes, can we add a ref?

[OG] IID collision is detected by SCHC gateway. Then, in LoRaWAN v1.1, this SCHC gateway can ask the NGW to trigger a new join to rekey the device, thus change the IID. It has been decided by the working group that the new join trigger is out of scope, as written section 5.3. Do you recommend to reconsider it ?
The way the device is rekeyed
   is out of scope of this document and left to the implementation





> Section 5.6.3:

> The term "applicative uplink" is used in this and subsequent sections. Are you

> referring to the application uplink? Not sure of what applicative means in the

> context?



[OG] Clarified in commit b08f639<https://github.com/Acklio/schc-over-lorawan/commit/b08f639f0dd775e4ddde9cef2d57cef8a455e260> as:

As this uplink is to open an RX window any LoRaWAN uplink frame from the device

MAY reset this counter.


[RJ] The term "applicative"  is used several places. The commit fixes it in just one place. Please go a grep and consider fixing other places as well.

[OG] I explained “applicative payload” in the example introduction. commit 04929da<https://github.com/Acklio/schc-over-lorawan/commit/04929daa34ab52d6596c8fd602c75cc2c2812695>:

   In following examples "applicative payload" refers to the IPv6
   payload send by the application to the SCHC layer.

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.