Hi Bernie, 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, including yours: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12 Please find below our inline responses: > Hi: > > I am an assigned INT directorate reviewer for > draft-ietf-lwig-tcp-constrained-node-networks (-11). These comments were > written primarily for the benefit of the Internet Area Directors. Document > editors and shepherd(s) should treat these comments just like they would > treat comments from any other IETF contributors and resolve them along > with any other Last Call comments that have been received. For more > details on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/. > > Reviewer: Bernie Volz > Review result: Ready (with minor nits) > > Minor nits: > > Section 2 should probably be updated to use the newer keyword boilerplate > (to reference RFC8174, etc.)? Actually, since the document does not use normative language, and according to the suggestions by some reviewers, we decided to remove Section 2. > In Section 4.1.2 RTO is used (and also later) but this isn't defined until > section 4.2.4. Perhaps this is better defined when first used? Agreed. > In section 4.2.2, the following paragraph is a bit odd: > > > One potentially relevant TCP option in the context of CNNs is TCP > > Fast Open (TFO) [RFC7413<https://tools.ietf.org/html/rfc7413>]. As > described in Section > 5.3<https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-11#section-5.3>, > TFO can be > > used to address the problem of traversing middleboxes that perform > > early filter state record deletion. > > Fast open isn't really used to address this issue. Section 5.3 is about > "TCP connection lifetime" and TFO is discussed there in the context of > reducing the (initial) messages and latency. Perhaps this paragraph needs > to be reworked a bit? If the point is about TFO, then you should indicate > what it is for (about optimizing short lived connections)? Yes, the paragraph was not in a very good shape, and perhaps TFO is not so specifically relevant to single-MSS stacks. Since TFO was better covered in Section 5.3 (now, Section 4.3) we decided to actually remove the paragraph. > General: While RFC-editor will do, s/subsection/section is probably a good > idea as subsection isn't generally used in IETF documents when doing > references. Done. > For section 8, it is too bad that some version/release information about > the particular "code" analyzed wasn't included. It says "be aware that > this Annex is based on information available as of the writing". But will > that still be valid when the RFC finally becomes available? Work started > on the document in Oct 2016 and I didn't go back to see when the various > sections were added. On the other hand, perhaps these implementations > don't evolve as rapidly as general software? It does seem to be a nice > survey of the available implementations. We understand that the information in section 8 is currently valid. We did our best to provide references (or version numbers) whenever possible. However, information sources are quite heterogeneous, and in a couple of cases (FreeRTOS, uC/OS) we were not able to find a specific release number related to the information provided. > And, there are at least the following typos: > > characterstic > codesize (perhaps code size) > bandwitdh > practise > differrent > communcation We made the corresponding corrections in our working copy, but I just realized that there is still one instance of "characterstic" and "codesize" in -12... The rest of typos have been corrected. Sorry for that. We will definitely address those in the next revision. :( > > * Bernie Thanks, Carles (on behalf of the authors) > > > > > _______________________________________________ > Lwip mailing list > Lwip@xxxxxxxx > https://www.ietf.org/mailman/listinfo/lwip > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
