SCHC: Generic Framework for Static Context Header Compression and Fragmentation
draft-ietf-lpwan-ipv6-static-context-hc-24

Thank you for addressing my DISCUSSes and COMMENTs.

Thank you for addressing all my DISCUSS and COMMENTS and writing a useful and clear document.

-éric

Please respond to the Gen-ART review.

It seems as though RFC 8376 should be a normative reference given its use in the terminology section.

Please reference the appendices from the text -- only D is referenced.  Are E and F intended to be normative?

Just a couple of things that didn’t show up in other reviews:

— Section 3 —

   LPWAN technologies have similar network architectures but different
   terminologies.

Similar to what?  Do you mean “Different LPWAN technologies”, or are you comparing LPWAN technologies to something else?

— Section 8.2.2.2 —

   o  their numbers MUST increase from 0 upward, from the start of the
      SCHC Packet to its end.

Just increase?  Or increase by 1?  The example in Figure 11 shows increasing by 1.  If that’s a requirement, it should say.

Figure 11 appears to have 29 windows, not 28, as it says.

Thank you for addressing my Discuss points!

Thanks for the well-written document!

A few quick comments:

1) This text on ECN in sec 10.3:
    " ECN functionality depends on both bits of the ECN field, which are
      the 2 LSBs of this field, hence sending only a single LSB of this
      field is NOT RECOMMENDED."
probably belongs in section 10.2 instead, no?

2) If I understand the protocol correctly, I believe it should be a normative requirement that the Inactivity Timer is always larger than the Retransmission Timer?
Related to this, Appendix F says:
"The initial value of the Inactivity timer is
   expected to be greater than that of the Retransmission timer, in
   order to make sure that a (buffered) SCHC Fragment to be
   retransmitted can find an opportunity for that transmission.  One
   exception to this recommendation is the special case of the All-1
   SCHC Fragment transmission."
I think this section should be moved into the body of the document. Further, if you need a different timer value for the All-1 SCHC Fragment, you should give this timer a distinct name and value.

3) I also agree with Alvaro that appendix E should be moved into the body of the document if you intent to specify something normatively there.

4) Editorial in Sec 10.11:
"...with a strength that is identical or better to the UDP
   checksum."
Not sure what you mean by "better"...?

5) I wondering if you want to say maybe something about pacing out different fragments (mostly when a window is used). I know that any recommendation would be technology dependent but in some cases sending a burst of packets e.g. could overload some network queues; therefore it could be good to at least mention it...?

6) Without having thought too hard about it: is it possible with this compression scheme to specify a rule that increases a counter/sequence number by 1 (given the initial value is known)? Would maybe be nice to say something about this in the document...