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

Carles Gomez Montenegro <> Fri, 30 October 2020 08:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 365873A0CB9; Fri, 30 Oct 2020 01:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.033
X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_SOCKS=1.927, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mZQEks3LUkHr; Fri, 30 Oct 2020 01:03:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A82593A0BAE; Fri, 30 Oct 2020 01:03:40 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 09U83XRT030222; Fri, 30 Oct 2020 09:03:33 +0100
Received: from ( []) by (Postfix) with ESMTP id 640AC1D53C1; Fri, 30 Oct 2020 09:03:32 +0100 (CET)
Received: from by with HTTP; Fri, 30 Oct 2020 09:03:33 +0100
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Fri, 30 Oct 2020 09:03:33 +0100
From: "Carles Gomez Montenegro" <>
To: "Bernie Volz \(volz\)" <>
Cc: "" <>, "Eric Vyncke (evyncke)" <>, "" <>, "" <>, "" <>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: Delayed for 00:37:13 by milter-greylist-4.3.9 ( []); Fri, 30 Oct 2020 09:03:35 +0100 (CET)
Archived-At: <>
Subject: Re: [Int-dir] [Lwip] Int Dir telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Oct 2020 08:03:45 -0000

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:

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


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

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

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


Carles (on behalf of the authors)

> _______________________________________________
> Lwip mailing list