The mechanisms themselves are unobjectionable/reasonable. -=R ________________________________ From: Lucas Pardue <[email protected]> Sent: Friday, February 6, 2026 3:12 PM To: Roberto Peon <[email protected]>; The IESG <[email protected]>; Deb Cooley <[email protected]> Cc: [email protected] <[email protected]>; QUIC WG Chairs <[email protected]>; [email protected] <[email protected]> Subject: The when/how/what of using paths (was; Re: Deb Cooley's No Objection on draft-ietf-quic-multipath-19: (with COMMENT))
Hi Roberto, On Fri, Feb 6, 2026, at 20: 03, Roberto Peon wrote: I'm still worried that we're not solving the API problem that has been inherent in most multipath attempts. From what I've seen to date, mechanism of multipath isn't the part that Hi Roberto, On Fri, Feb 6, 2026, at 20:03, Roberto Peon wrote: I'm still worried that we're not solving the API problem that has been inherent in most multipath attempts. From what I've seen to date, mechanism of multipath isn't the part that matters most to the success of multipath. When are we addressing the API for the policy that governs when/how/what path is used? I think this is an interesting topic but probably not 100% relevant to the SEC AD review. I'll also note that even pre adoption the emerging feeling appeared to be that scheduling of path usage is an active research topic and probably something difficult to try and find IETF consensus on. This I-D has taken great care to provide the mechanisms without verging on the more open class of problems. Maybe now folks want to talk about these topics. Its not clear to me if that has to be constrained to the QUIC WG. Cheers Lucas -=R ________________________________ From: Deb Cooley via Datatracker <[email protected]> Sent: Wednesday, February 4, 2026 2:33 PM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Deb Cooley's No Objection on draft-ietf-quic-multipath-19: (with COMMENT) Deb Cooley has entered the following ballot position for draft-ietf-quic-multipath-19: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!Bt8RZUm9aw!6_uL7GCS9p_vO4Swp0tAm9t7fFy81UoV8dHawd9IAVDNABNHJzuOJw-umGlRLRGyrf3HlQ4_yg$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/__;!!Bt8RZUm9aw!6_uL7GCS9p_vO4Swp0tAm9t7fFy81UoV8dHawd9IAVDNABNHJzuOJw-umGlRLRGyrf1-091siQ$ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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.]
