Éric, please see my comments below. For readability I removed some of the stuff we agreed upon.
> Hello Valery, > > Thank you for the prompt reply. > > It looks like Erik Kline could be my twin brother as we often emit the same > comments. FYI, I never read other ADs' ballot to avoid being biased. > > I agree with all your replies and explanations except when there is EV> > > Regards > > -éric > > > On 09/08/2022, 15:59, "Valery Smyslov" <s...@elvis.ru> wrote: > > Hi Éric, > > thank you for your comments. Please see inline. > > > Éric Vyncke has entered the following ballot position for > > draft-ietf-ipsecme-rfc8229bis-07: Yes > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling- > > ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-rfc8229bis-07 > > CC @evyncke > > > > Thank you for the work put into this document. There must be several use > > cases > > for it. > > > > Please find below some non-blocking COMMENT points (but replies would > be > > appreciated even if only for my own education). > > > > Special thanks to Tero Kivinen for the shepherd's detailed write-up > including > > the WG consensus, but it lacks the justification of the intended status. > > > > Thanks as well to Brian Haberman for his INT directorate review, his > review > has > > a 'ready' status. > > > > I hope that this review helps to improve the document, > > > > Regards, > > > > -éric > > [snip] > > ### Section 3 > > > > ``` > > Although a TCP stream may be able to send very long messages, > > implementations SHOULD limit message lengths to typical UDP datagram > > ESP payload lengths. > > ``` > > > > What is the 'typical' length ? > > It's usually the size of PMTU. > > EV> then it is worth mentioning I'd rather to change the whole sentence: Current: Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths to typical UDP datagram ESP payload lengths. Proposed: Although a TCP stream may be able to send very long messages, implementations SHOULD limit message lengths as if UDP encapsulation of ESP is used. Thus we eliminate the word "typica", which is problematic, and keep the idea - don't send very long messages with TCP encapsulation. Are you OK with this? > > ### Section 6.1 what about IP address changes ? > > > > ``` > > Since new TCP connections > > may use different ports due to NAT mappings or local port allocations > > changing, the TCP Responder MUST allow packets for existing SAs to be > > received from new source ports. > > ``` > > For some NAT devices (or IPv6 nodes w/o NAT but with temporary > addresses), > > the > > IP address could also change. This document should describe what to do > in > this > > case. > > The responder may have policy restricting source IP addresses. The whole > point > of this text is that it should not restrict source ports, with TCP they > are > usually ephemeral. > > EV> then, would the document benefit with some text around "TCP responder > MAY allow packets for existing SAs to be received from new IP addresses" ? How about: Current: Since new TCP connections may use different ports due to NAT mappings or local port allocations changing, the TCP Responder MUST allow packets for existing SAs to be received from new source ports. Proposed: Since new TCP connections may use different IP addresses and/or ports due to NAT mappings or local IP or port allocations changing, the TCP Responder MUST allow packets for existing SAs to be received from new source IP addresses and ports. > > Even if somehow obvious, should there be a statement about the IPv6 > Flow-ID > > header field ? > > Hm... Can you propose a text? > > EV> say something around Flow-ID must remain constant to avoid ECMP load > balancing must or probably MUST? I've added text at the end of this para: Note that the IPv6 Flow-ID header MUST remain constant when new TCP connection is created to avoid ECMP load balancing. Is that what you wanted? Thank you, Valery. > > ### TCP Fast Open support > > > > Is TCP fast open supported by this doc ? > > This was already asked by Erik, and the answer was that I see no reason > why > TCP fast open cannot be used with this spec. Probably Tommy would add > more. > > EV> Tommy, worth mentioning ? > > Thank you, > Valery. > > > ## Notes > > > > This review is in the ["IETF Comments" Markdown format][ICMF], You can > use > > the > > [`ietf-comments` tool][ICT] to automatically convert this review into > > individual GitHub issues. > > > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > > [ICT]: https://github.com/mnot/ietf-comments > > > > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
