Summary: Needs 8 more YES or NO OBJECTION positions to pass.
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 188.8.131.52.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?