[Last-Call] Genart last call review of draft-ietf-ipsecme-rfc8229bis-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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"


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux