Sorry for such a belated reply :(... Look below for EV>
On 13/05/2022, 06:58, "Mirja Kuehlewind" <[email protected]> wrote: Hi Eric, thanks for your review and your kind words! I'm opening github issue for most reviews right now but for your comments it's not fully clear to me how to address them, so I'm replying by email first. Please see below! Mirja On 19.04.22, 13:20, "Éric Vyncke via Datatracker" <[email protected]> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-quic-applicability-16: No Objection 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-quic-applicability/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Such a document is important for developers / operators wanting to use the new transport. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Matt Joras for the shepherd's write-up including the WG consensus and the intended status. I hope that this helps to improve the document, Regards, -éric Should there be a section about temporary address extension for IPv6 addresses RFC 8981 (as some OS can be very aggressive in changing to the next IPv6 address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one sentence in the introduction could be useful. What is the recommendation for these addresses, should the application keep always the first address as long as it is valid ? or should it switch to a new one ? [MK] I don't think this a problem as the address is usually (at least today) not changed during an on-going connection, or? EV> the previously used address may have become invalid (i.e., has expired) but this would only happen on very long-lasting connections. But my question is still the same: should the QUIC application tries to keep the 'original' address or should it try to use the most recent one? Giving guidance would be desirable? ## Section 2 "permits traversal of network middleboxes (including NAT)" could perhaps be refined as TCP also traverse NAT, perhaps something such as "using a new IP protocol would have issue with network middleboxes (Internet ossification)" ? [MK] I guess this should be rather s/IP protocol/transport protocol/. However, developing a new transport protocol on top of TCP doesn't make to much sense. I find the sense actually clear and straight-forward. Tending to not change anything... EV> as you prefer ## Section 4.4 (and some others) Sometimes the text is a little unclear on which part of the "application using QUIC" is discussed: the transport layer or the application layer in the "application" ? Unsure whether it is only me having this confusion though and I have no real suggestion on how to clarify things. [MK] Sorry this comment is not clear to me. Can you further explain? EV> my confusion may be sourced in my lack of QUIC understanding but I fail to understand which the explanations/recommendations are related to which part (either QUIC itself or in the application actually using QUIC). If this is clear for everyone, then I am in the rough and leave the text as it is. ## Section 5 For the last paragraph, should a reference to a TAPS API/parameter be given ? (if it exists of course) [MK] I don't think so; taps doesn't consider this specifically. EV> fair enough then ignore
