Since we're opening the naming bike shed, I would remind everyone that this work does not exist in a vacuum in the IETF. There are two other "multipath" transport protocol documents.
RFC 8684 - TCP Extensions for Multipath Operation with Multiple Addresses draft-ietf-tsvwg-multipath-dccp-24 - DCCP Extensions for Multipath Operation with Multiple Addresses draft-ietf-quic-multipath-16 - Multipath Extension for QUIC The DCCP naming clearly took the TCP one directly. Perhaps we should consider doing the same. This would suggest "QUIC Extensions for Multipath Operation with Multiple Addresses". The abstracts of the TCP and DCCP documents is also significantly longer than the QUIC document currently is. I will also note that the TCP work was proposed as Standards Track, and DCCP is also (currently) proposed as Standards Track. Matt On Mon, Oct 6, 2025 at 9:15 AM Lucas Pardue <[email protected]> wrote: > Hi Lars > > On Mon, Oct 6, 2025, at 16:51, Lars Eggert wrote: > > 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. > > Thank you, this was very helpful. > > I've created a GitHub issue to track further discussion on this matter. > > Cheers > Lucas > > > Thanks, > Lars > > > > *Attachments:* > > - signature.asc > > >
