Hi Roberto, I’m not sure this is the right thread for this discussion. Anyway, a quick reply: yes, scheduling was decided to not be covered by this spec. This spec provides the basics that enables people to developed more advanced mechanism when needed for certain uses cases and then bring it back to the IETF in a follow-up spec.
Mirja From: Roberto Peon <[email protected]> Date: Friday, 6. February 2026 at 21:03 To: The IESG <[email protected]>, Deb Cooley <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: Deb Cooley's No Objection on draft-ietf-quic-multipath-19: (with COMMENT) Resent from: <[email protected]> Resent to: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Resent date: Friday, 6. February 2026 at 21:03 You don't often get email from [email protected]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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? -=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.]
