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

[Carles Gomez Montenegro]

Hi again, Bernie,

> 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. :(

We just submitted -13, where those typos are now fixed:
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-13

Thanks,

Carles (on behalf of the authors)

___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Carles Gomez Montenegro]

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].  As
> described in 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
>


___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip

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

[Bernie Volz (volz)]

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.)?

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?

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].  As 
described in 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)?

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.

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.

And, there are at least the following typos:

characterstic
codesize (perhaps code size)
bandwitdh
practise
differrent
communcation


  *   Bernie




___
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip