On 10/02/2026 17:04, Roberto Peon wrote:
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
I concur on the adoption of the present document by the QUIC WG.
I also agree that the topic of HOW to use multipath transports and what
scheduling to use likely does fall within the Area and would encourage
people to bring forward experience and measurement data to help progress
these topics, and hopefully, when ready, to produce
specifications/guidance. Please contact me as AD if you need help to
find the best venue for your contributions,
Gorry
(WIT AD)
-=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.]
