Benjamin Kaduk has entered the following ballot position for draft-ietf-lwig-tcp-constrained-node-networks-11: 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-lwig-tcp-constrained-node-networks/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Mostly just editorial nits, but please see the comment on Section 5.3. Section 2 (I believe the existence of the RFC 8174 version of the BCP 14 boilerplate has already been noted.) Section 3.2 or devices with a pool of multiple send/receive buffers. In the latter case, it is possible that buffers also be shared for other protocols. nit: s/be/are/ (or any number of other minor tweaks) One key use case for the use of TCP in CNNs is a model where nit: "use case for the use" is probably redundant: "use case for TCP in CNNs" seems like it would work okay. middlebox (e.g. a firewall, NAT, etc.). Figure 1 illustrates such scenario. Note that the scenario is asymmetric, as the unconstrained nit: "such a scenario". Section 3.3 o Unidirectional transfers: An IoT device (e.g. a sensor) can send (repeatedly) updates to the other endpoint. Not in every case there is a need for an application response back to the IoT device. (editorial) I suggest "There is not always a need for an application response back to the IoT device". Section 4.1.1 smaller than 1220 bytes (e.g. not larger than 1200 bytes). Note that it is advised for TCP implementations to consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. Therefore, the suggestion of [my reading of RFC 6691 is that it was required to consume payload space, but only recommended to account for this behavior when advertising MSS. I guess Erik covered this in his Discuss point already, though.] Section 5.3 The message and latency overhead that stems from using a sequence of short-lived connections could be reduced by TCP Fast Open (TFO) [RFC7413], which is an experimental TCP extension, at the expense of increased implementation complexity and increased TCP Control Block (TCB) size. TFO allows data to be carried in SYN (and SYN-ACK) We should probably make at least a passing mention of the TFO security considerations here, possibly with some discussion of why they are less consequential for certain CNNs than in general. (Note that the security considerations for TFO are not limited to just the risk of replay, and that there are privacy considerations for the TFO cookie being used to link together multiple TCP connections between the same endpoints.) Section 10.1 RFC 3819 may not need to be listed as normative, given the nature of the one place in which it is referenced. Similarly, we don't say much about TCP-AP other than it exists, so RFC 5925 may not need to be normative either. Section 10.2 RFC 6092 appears to not be referenced from anywhere? idnits notes a couple other reference-related issues. _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip
