RFC editor will fix remaining typos so no need to worry about those. - Bernie > On Oct 30, 2020, at 4:03 AM, Carles Gomez Montenegro <carlesgo@xxxxxxxxxxxxx> wrote: > > 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 >> > > > _______________________________________________ > Int-dir mailing list > Int-dir@xxxxxxxx > https://www.ietf.org/mailman/listinfo/int-dir -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
