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

[Martin Duke <[e-mail]>]

Sounds good! thanks for the changes.

On Wed, Oct 28, 2020 at 7:32 AM Olivier Gimenez <[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]>
>
> >
>
> >
>
> > ----------------------------------------------------------------------
>
> > 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.
>