Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-transport-encrypt-19

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 16 February 2021 09:28 UTC

To: Joel Halpern <jmh@joelhalpern.com>, gen-art@ietf.org
Cc: last-call@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-transport-encrypt.all@ietf.org
References: <161342920774.21307.750639857551709675@ietfa.amsl.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <93190fab-99cf-0de9-d3e1-ff8a075476e9@erg.abdn.ac.uk>
Date: Tue, 16 Feb 2021 09:28:39 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <161342920774.21307.750639857551709675@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/WvtW8gLMGWTfBE2oQivB24ICU9U>
Subject: Re: [tsvwg] Genart last call review of draft-ietf-tsvwg-transport-encrypt-19
Precedence: list

Thanks Joel for these helpful comments.

We think these issues could be addressed with a small number of 
additional clarifications, see below:

On 15/02/2021 22:46, Joel Halpern via Datatracker wrote:
> Reviewer: Joel Halpern
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-tsvwg-transport-encrypt-19
> Reviewer: Joel Halpern
> Review Date: 2021-02-15
> IETF LC End Date: 2021-02-19
> IESG Telechat date: Not scheduled for a telechat
> Summary: This document is ready for publication as an Informational RFC
>
> Major issues:
>
> Minor issues:
>       While section 2 does include a discussion of traffic mis-ordering, it does
>       not include a discussion of ECMP, and the dependence of ECMP on flow
>       identification to avoid significant packet mis-ordering.
This was assumed, it can be added.
>      Section 5.1 of this document discusses the use of Hop-by-Hop IPv6 options.
>      It seems that it should acknowledge and discuss the applicability of the
>      sentence "New hop-by-hop options are not recommended..." from section 4.8
>      of RFC 8200.  I think a good argument can be made in this case as to why
>      (based on the rest of the sentence from 8200) the recommendation does not
>      apply to this proposal.  The document should make the argument.
I would be OK with adding this, if there is no objection.
> Nits/editorial comments:
>       I found the discussion of header compression slightly confusing.  Given
>       that the TCP / UDP header is small even compared to the IP header, it is
>       difficult to see why encrypting it would have a significant impact on
>       header compression efficacy.
I suspect this needs a preface that explains that HC methods are most 
effective for bit-congestive links sending small packets (e.g. when 
sending control packets or small data packets over radio links).
>     The wording in section 6.2 on adding header information to an IP packet has
>     the drawback of seeming to imply that one could add (or remove) such
>     information in the network, without adding an encapsulating header.  That is
>     not permitted by RFC 8200.  It would be good to clarify the first paragraph.
>      (The example, which talks about the sender putting in the information is,
>     of course, fine.)
>
I think that would indeed be useful to add.

Gorry

[tsvwg] Genart last call review of draft-ietf-tsv… Joel Halpern via Datatracker
Re: [tsvwg] Genart last call review of draft-ietf… Gorry Fairhurst