[lp-wan] AD review of draft-ietf-lpwan-schc-compound-ack-10

["Eric Vyncke (evyncke)" <[e-mail]>]

# Éric Vyncke, INT AD, comments for draft-ietf-lpwan-schc-compound-ack-10

CC @evyncke



As usual, as the responsible AD for the ALPWAN WG, I have done an AD review before the IETF Last Call. Please find a MD-formatted review below. Before going further, I am requesting the authors to act/reply/comment on all the points below. The end goal is to ease the rest of the publication process.



Special thanks to Alexander for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.



I hope that this review helps to improve the document,



Regards,



-éric



## COMMENTS



### Early review by YANG doctors



Could the chairs request an early review by the YANG doctors ?



### Shepherd write-up



Please list the existing implementations. This always help the publication process.



### Abstract



The abstract must explicitly indicate that this document updates RFC 8724.



### Section 1



`such as the four LWPAN defined in [RFC8376], ` as RFC 8376 is informative, it cannot "define" but rather "cite or list".



Even if "LPWAN" is an accepted abbreviation, please expand it at first use.



### Section 3



One paragraph describing SCHC ack system and its associated window would help the reader understanding Compound Ack



### Section 3.1



Please some consistency between figures, i.e., same width for '---M--' and the '~' or '-' for the padding delimitator.



`the length of the message learnt from the underlying layer` or `the length of the message in the underlying layer` or even `the layer-2 MTU`



Honestly, I was unable to understand the specification, possibly because I am not a SCHC expert, hence not too familiar with SCHC fragmentation. Let's hope that a SCHC engineer will be able to understand it. First paragraph of section 3.2 should probably be included in section 3.1 to give an idea.



### Section 3.2



I do not remember any updating RFC using the notation of ***new text*** for _parts_ of the sentences. The update 'patch' is usually by whole sections or paragraph. Did the authors find a similar example ? As a side note, should `Old text is -- OLD TEXT --. New text replaces old text.` be replaced by `Old text is -- OLD TEXT --. The old text is to be ignored.`



Please let's be clear with something like `The following section 3.2.1 (and its subsections) replaces the sections 8.4.2 (and its subsections) of RFC 8724. For the convenience of the reader, the added text to the original RFC 8724 is highlighted with *** NEW TEXT *** and the deleted text from RFC 8724 is delimited by -- OLD TEXT --`.



Should the title of section 8.3.2 of RFC 8724 (SCHC ACK Format) also be updated by this I-D ? Because the new text always mentions "A SCHC ** Compound ** ACK" that it is not defined in RFC 8724 per se.



### Updated section 8.4.2



Perhaps an HTML rendering issue, but the text `**if the SCHC Compound ACK is used.**` appears to be dangling (i.e., unsure whether it applies to previous or missing or following text).



### Section 4



Please use the notation of figure 32 from draft-ietf-lpwan-schc-over-sigfox to indicate packet loss in figure 8.



### Section 6



Also, please formally update the appendix D of RFC 8724 by providing new text/old text rather than the current text.