[lp-wan] Mirja Kühlewind's No Objection on draft-ietf-lpwan-ipv6-static-context-hc-21: (with COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-lpwan-ipv6-static-context-hc-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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...