Éric Vyncke's No Objection on draft-ietf-quic-applicability-16: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

É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 ?

## 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)" ?

## 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.

## Section 5

For the last paragraph, should a reference to a TAPS API/parameter be given ?
(if it exists of course)