Managing multiple paths for a QUIC connection
draft-ietf-quic-multipath-21

# Andy Newton, ART AD, comments for draft-ietf-quic-multipath-19
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-quic-multipath-19.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Thanks to Carsten Bormann for the ARTART review.


## Comments

This is an impressive specification. Thanks for the work from the authors and the working group.

I did spend an inordinate amount of time looking at the difference in the RFC9001 AEAD nonce and the AEAD nonce in this draft.  I do believe that one *could* make this clearer.  I'll only give one suggestion.

Section 2.4, last paragraph:  This example would be easier to see/understand in a table/figure form with the IV, path ID, two bits of 0, packet number, and XOR'd result all lined up in three rows.    

Section 7.3, last para: This specification does not change how the 'AEAD' works.  It does change the calculation of the AEAD nonce that is an input to the algorithm.  I would change the first sentence to:  'This specification changes the AEAD nonce calculation by including the path ID as part of the calculation.'  Otherwise, the paragraph is inaccurate.  [Thanks to Carsten Bormann for this.  I (obviously) agree with him.]

Thanks for the work done in this document.

Special thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request and on short notice), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-quic-multipath-19-intdir-telechat-fressancourt-2026-02-04/

In addition to Antoine's review, and in the light of https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, I noted some SHOULD (e.g., sections 2.3, 2.5) that are without the required guidance per the IESG statement (in short, why not a MUST?).

Let me also expression my surprise (knowing many of the authors) that section 5.2 uses IPv4 only example... On this topic, a dual-stack example would have been nice (especially, as Wi-Fi is often IPv4-only and 3GPP/cellular is often IPv6-enable or IPv6-only).

Thank you for your updates to address my previous ballot.

Hi Yanmei, Yunfei, Quentin, Olivier, Christian, and Mirja, 

Thank you for the discussion and for the changes made [1]. This addresses key point in my previous ballot [2].

Looking forward to see more operational experience and hopefuly more guidance on scheduling part.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-quic-multipath-19&url2=draft-ietf-quic-multipath-20&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/quic/Kx2r3Pc7RzucmgsLkNqgqymftXA/

Thank you to Meral Shirazipour for the GENART review.

Thank you for addressing my DISCUSS feedback.

# Internet AD comments for draft-ietf-quic-multipath-19
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1

* In addition to working with QUIC v1, I assume it will work with other
  v1-compatible version, e.g. "v2"/RFC 9369?

* "There are currently no IETF specifications ..."

  Is this really true?  Does RFC 6356 count as one such specification?