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 <[email protected]>: >> 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 <[email protected]> >> Lucas Pardue <[email protected]> >> >> Assigned Area Director: >> Gorry Fairhurst <[email protected]> >> >> Web and Internet Transport Directors: >> Gorry Fairhurst <[email protected]> >> Mike Bishop <[email protected]> >> >> Mailing list: >> Address: [email protected] >> 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
