Re: [Lwip] Int Dir telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11

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@ietf.org
> https://www.ietf.org/mailman/listinfo/lwip
>