Ballot for draft-ietf-lpwan-ipv6-static-context-hc
Yes
No Objection
Note: This ballot was opened for revision 21 and is now closed.
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...