[Gen-art] Genart last call review of draft-ietf-ipsecme-rfc8229bis-06

Reese Enghardt via Datatracker <noreply@ietf.org> Tue, 31 May 2022 18:20 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 750C6C15AAEF; Tue, 31 May 2022 11:20:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Reese Enghardt via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: draft-ietf-ipsecme-rfc8229bis.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165402123047.5824.8550810378286288506@ietfa.amsl.com>
Reply-To: Reese Enghardt <ietf@tenghardt.net>
Date: Tue, 31 May 2022 11:20:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/W_qfV_SLWNSSB8G8o9i37VHvLVU>
Subject: [Gen-art] Genart last call review of draft-ietf-ipsecme-rfc8229bis-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.34
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2022 18:20:30 -0000

Reviewer: Reese Enghardt
Review result: Ready with Nits

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-ipsecme-rfc8229bis-06
Reviewer: Reese Enghardt
Review Date: 2022-05-31
IETF LC End Date: 2022-05-31
IESG Telechat date: Not scheduled for a telechat

Summary: This document is well-written, clear, and concise. It is basically
ready for publication, though I found a few nits, which could be fixed to make
it even easier to read.

Major issues: None.

Minor issues:

Section 4:

"The maximum message length is used as the effective MTU for connections that
are being encrypted using ESP, so the maximum message length will influence
characteristics of inner connections, such as the TCP Maximum Segment Size
(MSS)."

Here, it may be worth defining "inner connection" to make this paragraph easier
to understand - the "inner connection" is currently explained only later in
Section 10.1.

Section 9:

"TCP encapsulation of IKE should therefore use standard TCP behaviors to avoid
being dropped by middleboxes." I understand the use of "standard TCP" in a
colloquial sense, e.g., not using any TCP extensions which might be blocked by
middleboxes, even if the extensions are standardized in an RFC. Still, I wonder
if a different phrasing here would be clearer.

Nits/editorial comments:

"There is a trade-off in choosing the period of time after which TCP connection
is closed" -> "the TCP connection is closed"

"With TCP encapsulation this is generally not possible, because TCP/IP stack
manages DF bit in the outer IP header" -> "the TCP/IP stack"

"The frequency of sending such messages should be high enough to allow quick
detection and restoring of broken TCP connection." -> "connections"