Hi, On Oct 6, 2025, at 17:08, Lucas Pardue <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP
