Re: draft-opik-quic-qmux-00 (Re: WG Action: Rechartered QUIC (quic))

 Hi  folks,

With chair hat on, we intend to discuss this draft during tomorrow's session at IETF 124. If you didn't have a chance to read the document yet, now would be a good time.

Cheers
Lucas

On Wed, Oct 8, 2025, at 22:53, Kazuho Oku wrote:
> I'm very happy to see the charter being updated — thank you to the chairs, ADs, and the WG for driving it forward.
> 
> Just FWIW, draft-opik-quic-qmux-00 <https://datatracker.ietf.org/doc/draft-opik-quic-qmux/> is available and open for discussion. Aside from the name change, this draft is an updated version of the QUIC-on-Streams <https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-streams> draft.
> 
> Please let the authors know what you think.
> 
> Thank you in advance.
> 
> 2025年10月9日(木) 2:31 The IESG <iesg-secretary@ietf.org>:
>> The QUIC (quic) WG in the Web and Internet Transport of the IETF has been
>> rechartered. For additional information, please contact the Area Directors or
>> the WG Chairs.
>> 
>> QUIC (quic)
>> -----------------------------------------------------------------------
>> Current status: Active WG
>> 
>> Chairs:
>>   Matt Joras <matt.joras@gmail.com>
>>   Lucas Pardue <lucas@lucaspardue.com>
>> 
>> Assigned Area Director:
>>   Gorry Fairhurst <gorry@erg.abdn.ac.uk>
>> 
>> Web and Internet Transport Directors:
>>   Gorry Fairhurst <gorry@erg.abdn.ac.uk>
>>   Mike Bishop <mbishop@evequefou.be>
>> 
>> Mailing list:
>>   Address: quic@ietf.org
>>   To subscribe: https://www.ietf.org/mailman/listinfo/quic
>>   Archive: https://mailarchive.ietf.org/arch/browse/quic/
>> 
>> Group page: https://datatracker.ietf.org/group/quic/
>> 
>> Charter: https://datatracker.ietf.org/doc/charter-ietf-quic/
>> 
>> The QUIC WG originated the specifications describing version 1 of
>> QUIC, a UDP-based, stream-multiplexing, encrypted transport protocol.
>> 
>> The WG acts as the focal point for any QUIC-related work in the IETF.
>> It is chartered to pursue work in the areas detailed below:
>> 
>> 1. The first area of work is maintenance and evolution of the existing
>>    QUIC specifications:
>> 
>>    * Maintenance and evolution of the QUIC base specifications that
>>      describe its invariants, core transport mechanisms, security and
>>      privacy properties, loss detection and recovery, congestion control,
>>      version and extension negotiation, etc.
>> 
>>    * Maintenance and evolution of the existing QUIC extensions
>>      specified by the WG.
>> 
>>    * Specification of new versions of QUIC.
>> 
>>    WG adoption of work items falling into this first area of work
>>    needs to be strongly motivated by existing or ongoing production
>>    deployments of QUIC at scale, and needs to carefully consider its
>>    impact on the applications that have adopted QUIC as a transport.
>> 
>> 2. The second area of work is supporting the deployability of QUIC,
>>    which includes specifications, such as specification of a logging
>>    format and operation with load balancers; and informational documents
>>    such as applicability and manageability statements, and more.
>> 
>> 3. The third area of work is the specification of new extensions to
>>    QUIC.
>> 
>>    * The WG will primarily focus on extensions to the QUIC transport
>>    layer, i.e., extensions to QUIC that have broad applicability to
>>    multiple application protocols.
>> 
>>    * The WG may also publish Informational documents that
>>    publicly document deployed proprietary extensions or to enable
>>    wider experimentation with proposed new protocol features.
>> 
>> 4. The fourth area of work is the specification of how QUIC stream
>>    multiplexing and other application-oriented extensions (e.g. Datagram)
>>    can be adapted to work over a reliable and bidirectional byte stream
>>    substrate. When the substrate is insecure, TLS will be the default
>>    security provider; no effort will be made to enable unprotected
>>    communication without a security provider. Substrates must provide
>>    congestion-management capabilities applicable to their deployment
>>    environments.
>> 
>> Specifications published by the QUIC WG Specifications will be
>> published on the Standards Track providing they can demonstrate
>> sufficient maturity.
>> 
>> Specifications describing how new or existing application protocols
>> use the QUIC transport layer, called application protocol mappings
>> below, need not be specified in the QUIC WG, although they can. The
>> QUIC WG will collaborate with other groups that define such
>> application protocols that intend to use QUIC. New application
>> protocol mappings might require QUIC extensions and it may be
>> efficient to define these alongside the mapping specifications. Groups
>> that define application protocols using QUIC, or extensions to QUIC in
>> support of those protocols, are strongly requested to consult with the
>> QUIC WG and seek early and ongoing review of and collaboration on
>> proposals. This is intended to reduce the possibility of duplicate
>> work and/or conflicts with other extensions.
>> 
>> Defining new congestion control schemes is explicitly out of scope for
>> the WG. However, new QUIC extensions that support development and
>> experimentation with new congestion control schemes may fall under
>> the third area of work.
>> 
>> The QUIC WG originated HTTP/3, the mapping of HTTP to QUIC, and the
>> QPACK header compression scheme. These specifications are now
>> maintained in the HTTP WG.
>> 
>> Milestones:
>> 
>>    - QUIC Acknowledgement Frequency to IESG
>> 
>>    - Reliable Stream Resets to IESG
>> 
>>    - Qlog documents to IESG
>> 
>>    - Multipath Extension to QUIC to IESG
>> 
>>   Sep 2021 - QUIC-LB: Generating Routable QUIC Connection IDs to IESG
>> 
>>    - QUIC Retry Offload to IESG
>> 
>> 
> 
> 
> --
> Kazuho Oku