SCHC: Generic Framework for Static Context Header Compression and Fragmentation

Note: This ballot was opened for revision 21 and is now closed.

(Suresh Krishnan) Yes

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2019-08-21 for -21)
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.

Roman Danyliw (was Discuss) No Objection

Comment (2019-11-11 for -22)
No email
send info
Thank you for addressing my DISCUSSes and COMMENTs.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-11-01 for -22)
No email
send info
Thank you for addressing my Discuss points!

(Mirja Kühlewind) No Objection

Comment (2019-08-21 for -21)
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
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...

Barry Leiba No Objection

Comment (2019-08-21 for -21)
Just a couple of things that didn’t show up in other reviews:

— Section 3 —

   LPWAN technologies have similar network architectures but different

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

— Section —

   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.

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

Comment (2019-08-20 for -21)
Please reference the appendices from the text -- only D is referenced.  Are E and F intended to be normative?

(Adam Roach) No Objection

Éric Vyncke (was Discuss) No Objection

Comment (2019-08-22 for -21)
Thank you for addressing all my DISCUSS and COMMENTS and writing a useful and clear document.