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

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