SCHC: Generic Framework for Static Context Header Compression and Fragmentation
RFC 8724
Yes
No Objection
Note: This ballot was opened for revision 21 and is now closed.
Alvaro Retana No Objection
Please reference the appendices from the text -- only D is referenced. Are E and F intended to be normative?
Roman Danyliw (was Discuss) No Objection
Thank you for addressing my DISCUSSes and COMMENTs.
Éric Vyncke (was Discuss) No Objection
Thank you for addressing all my DISCUSS and COMMENTS and writing a useful and clear document. -éric
(Suresh Krishnan; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
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.
(Barry Leiba; former steering group member) No Objection
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.
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thank you for addressing my Discuss points!
(Deborah Brungard; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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...