Hi Carles, Thank you for the updates; they look good and I have no further comments.
-Ben On Fri, Oct 30, 2020 at 09:38:38AM +0100, Carles Gomez Montenegro wrote: > 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
