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

[Rahul Jadhav <[e-mail]>]

Thanks Olivier. Most of the changes work for me. Few nits suggested in the
commits.

@Eric, I believe it should definitely be possible to get an updated ID by
next week since Olivier responses are prompt and I'll make sure I follow
suit.

Regards,
Rahul


On Fri, 2 Oct 2020 at 14:09, Olivier Gimenez <[e-mail]> wrote:

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

[RJ] This works great for me. Thanks.

>
>
> > 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>
>
[RJ] Ok

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

[RJ] Perfect.

>
>
> > 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.*
>
[RJ] Works. Reference to Section 6 of RFC 8724 definitely helps since it
has a clear requirement towards keeping such an ID explicit.

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

[RJ] I take that as, lora-spec v1.1 is not publicly available and thus we
need to keep these rekeying specifics out of the document. If that's the
case, it works for me.

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

[RJ]  Works. Small nits in the text raised as comments in the commit.


>

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