Hi Reese, thank you for your review! Please find my comments below. > -----Original Message----- > From: Reese Enghardt via Datatracker [mailto:noreply@xxxxxxxx] > Sent: Tuesday, May 31, 2022 9:21 PM > To: gen-art@xxxxxxxx > Cc: draft-ietf-ipsecme-rfc8229bis.all@xxxxxxxx; ipsec@xxxxxxxx; last-call@xxxxxxxx > Subject: Genart last call review of draft-ietf-ipsecme-rfc8229bis-06 > > 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. How about: 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 these connections, such as the TCP Maximum Segment Size (MSS). > 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. Definitely, the "standard TCP behaviors" here does not mean that TCP extensions should not be used. How about the following text: TCP encapsulation of IKE should therefore use common TCP behaviors to avoid being dropped by middleboxes. > 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" Fixed. > "With TCP encapsulation this is generally not possible, because TCP/IP stack > manages DF bit in the outer IP header" -> "the TCP/IP stack" Fixed. > "The frequency of sending such messages should be high enough to allow quick > detection and restoring of broken TCP connection." -> "connections" Fixed. Thank you! Regards, Valery. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
