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