Re: Second WGLC for Multipath Extension for QUIC

[Lars Eggert <[e-mail]>]

Hi,

On Oct 6, 2025, at 17:08, Lucas Pardue <[e-mail]> wrote:
> There were comments from individuals such as Martin Duke and Lars Eggert that I, as a chair, interpret to mean that they could live with a standards-track document (i.e. not calling for an experimental document) if it would make some editorial changes. For instance clarify and reinforce the foundational capabilities of the extension, and what things specific deployments or use cases would need to consider, while avoiding normative references on something that is a research topic. I believe the document updates made and captured in (at the time of writing) draft 16 address these requests. Do you think there are further changes needed?

I was thinking I was alone in my dissent, but then Ian emailed, and I got triggered :-)

I just briefly rechecked -16:

The title is still very generic, implying that this is a (*the*?) multipath extension for QUIC. Same in the abstract.

The last three paragraphs of the introduction then have some text that was maybe added to address the raised concern, i.e., that this doc specifies extensions for *managing multiple paths* for QUIC connection. But that that alone is not resulting in "multipath QUIC", i.e., an IETF standard for how you actually safely and effectively utilize those multiple paths at the same time. I think the document needs to be much more blunt in stating that caveat ("We give you paths. We don't tell you how to use them. This is a required piece of multipath QUIC, but not a complete standard.")

I hope this makes my concern a bit clearer. It's not that I disagree that what the doc normativley describes isn't ready for PS, it's that the doc is titled and introduced as if that was all the pieces needed for multipath QUIC when that's not the case.

Proposal: Title change to "Managing multiple paths for a QUIC connection". Abstract and introduction accurately summarize standardized content. 

Thanks,
Lars