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

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Fri, 30 October 2020 08:03 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365873A0CB9; Fri, 30 Oct 2020 01:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.033
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZQEks3LUkHr; Fri, 30 Oct 2020 01:03:41 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82593A0BAE; Fri, 30 Oct 2020 01:03:40 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.40.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 09U83XRT030222; Fri, 30 Oct 2020 09:03:33 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 640AC1D53C1; Fri, 30 Oct 2020 09:03:32 +0100 (CET)
Received: from 83.38.106.121 by webmail.entel.upc.edu with HTTP; Fri, 30 Oct 2020 09:03:33 +0100
Message-ID: <64715ab7503a1fb4f54fb7bab64f789b.squirrel@webmail.entel.upc.edu>
In-Reply-To: <BN7SPR01MB0024B07CE9E12A1509EA39D5CF1F0@BN7SPR01MB0024.namprd11.prod.outlook.com>
References: <BN7SPR01MB0024B07CE9E12A1509EA39D5CF1F0@BN7SPR01MB0024.namprd11.prod.outlook.com>
Date: Fri, 30 Oct 2020 09:03:33 +0100
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: "Bernie Volz \(volz\)" <volz=40cisco.com@dmarc.ietf.org>
Cc: "int-dir@ietf.org" <int-dir@ietf.org>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "draft-ietf-lwig-tcp-constrained-node-networks@ietf.org" <draft-ietf-lwig-tcp-constrained-node-networks@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "lwip@ietf.org" <lwip@ietf.org>
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 (violet.upc.es [147.83.2.51]); Fri, 30 Oct 2020 09:03:35 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/aYPvabH7Ys8eUOfizAF9UnHYISA>
Subject: Re: [Int-dir] [Lwip] Int Dir telechat review of draft-ietf-lwig-tcp-constrained-node-networks-11
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=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:
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>]3>].  As
> described in Section
> 5.3<https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-11#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
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
>