Telechat Review of draft-ietf-quic-multipath-19
review-ietf-quic-multipath-19-intdir-telechat-fressancourt-2026-02-04-00

I am an assigned INT directorate reviewer for draft-ietf-quic-multipath-19 -
*Managing multiple paths for a QUIC connection*. These comments were written
primarily for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat comments
from any other IETF contributors and resolve them along with any other Last
Call comments that have been received. For more details on the INT Directorate,
see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as YES or
NO OBJECTION.

The following are issues I found with this document that SHOULD be corrected
before publication:

* In section 3, a definition of what a path is in this document would help. Of
course, there is a whole research group about this question, but the clarity of
the document would be improved if it was clear from this section that a path is
not only defined by a 4-tuple, and that different paths can have the same
4-tuple in your definition.

* In section 3.1, it is unclear how long a path can be considered valid after
it has been validated following section 8 of RFC 9000. This question is later
addressed in the document in section 5.9, but this does not settle this matter.
The use of PING frames as keepalives is mentioned, while its use is not
recommended. This issue should be clarified and given a clear answer to better
guide protocol implementers.

* In section 3.3, the path status management behavior is not sufficiently clear
in my perspective. The document should give a minimal path selection mechanism
considering available paths status to guide implementers, even if the document
allows diverging from the proposed path management policy.

* In section 3.4, the document should clarify the behavior expected when a peer
sends a PATH_ABANDON frame but does not receive the corresponding PATH_ABANDON
frame in return.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

* In section 2, as you are describing the Connection IDs and Path IDs, I would
place a schema to help the reader picture properly how those IDs depend on one
another in QUIC multipath. Similarly, in section 2.4, I would make a schema to
present how the nonce is built.

* In section 7.2, I am wondering why, in the anti-amplification mechanism, the
authors are not suggesting using a quota per path AND an overarching quota for
the whole connection.