Hi Benjamin, Thank you very much for your review!
We just submitted revision -12, which aims at addressing the comments received from the IESG and related reviewers: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12 Please find below our inline responses: > 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.) Thanks. In fact, since the document does not use normative language, we removed Section 2 in the last document revision. > 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) Done. > 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. Done, thanks. > 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". Done. > 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". Done. > 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.] As per a subsequent discussion on the tcpm mailing list, we updated the second paragraph of current Section 3.1.1 is as follows: NEW: An IPv6 datagram size exceeding 1280 bytes can be avoided by setting the TCP MSS not larger than 1220 bytes. Note that it is already a requirement that TCP implementations consume payload space instead of increasing datagram size when including IP or TCP options in an IP packet to be sent [RFC6691]. Therefore, it is not required to advertise an MSS smaller than 1220 bytes in order to accommodate TCP options. > 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.) We made the following change: OLD: The cookie needs to be refreshed (and obtained by the client) after a certain amount of time. Nevertheless, TFO is more efficient than frequently opening new TCP connections with the traditional three-way handshake, as long as the cookie can be reused in subsequent connections. NEW: The cookie needs to be refreshed (and obtained by the client) after a certain amount of time. While a given cookie is used for multiple connections between the same two endpoints, the latter may become vulnerable to privacy threats. In addition, a valid cookie may be stolen from a compromised host and may be used to perform SYN flood attacks, as well as amplified reflection attacks to victim hosts (see Section 5 of RFC 7413). Nevertheless, TFO is more efficient than frequently opening new TCP connections with the traditional three-way handshake, as long as the cookie can be reused in subsequent connections. > 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. Done! > Section 10.2 > > RFC 6092 appears to not be referenced from anywhere? We removed the reference (it was used in some older version of the draft). > idnits notes a couple other reference-related issues. We believe that we cleared those as well in -12. Thanks, Carles (on behalf of the authors) _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
