Hello Valery,
Thanks again for the discussion, it should help improving the I-D.
Look below for EV2>
Cheers
-éric
On 09/08/2022, 18:03, "Valery Smyslov" <s...@elvis.ru> wrote:
É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?
EV2> this is good enough for me (the 'typical' was not explained hence my
concern)
> > ### 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.
EV2> it looks good to me
> > 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?
EV2> indeed, sorry...
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?
EV2> confirmed ;-)
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
