Re: WG Review: Multiplexed Application Substrate over QUIC Encryption (masque)

In a case like the one below, it would be extremely helpful to have a 
(pointer to a) diff between the current and the proposed charter.

Regards,   Martin.

On 2023-04-21 06:51, The IESG wrote:
> The Multiplexed Application Substrate over QUIC Encryption (masque) WG in the
> Transport Area of the IETF is undergoing rechartering. The IESG has not made
> any determination yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to the
> IESG mailing list (iesg@ietf.org) by 2023-04-30.
> 
> Multiplexed Application Substrate over QUIC Encryption (masque)
> -----------------------------------------------------------------------
> Current status: Active WG
> 
> Chairs:
>    Christopher Wood <caw@heapingbits.net>
>    Eric Kinnear <ekinnear@apple.com>
> 
> Assigned Area Director:
>    Martin Duke <martin.h.duke@gmail.com>
> 
> Transport Area Directors:
>    Martin Duke <martin.h.duke@gmail.com>
>    Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
> 
> Mailing list:
>    Address: masque@ietf.org
>    To subscribe: https://www.ietf.org/mailman/listinfo/masque
>    Archive: https://mailarchive.ietf.org/arch/browse/masque/
> 
> Group page: https://datatracker.ietf.org/group/masque/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-masque/
> 
> Many network topologies lead to situations where transport protocol proxying
> is beneficial. For example, proxying enables endpoints to communicate when
> end-to-end connectivity is not possible or to apply additional encryption
> where desirable (such as a VPN). Proxying can also improve client privacy,
> e.g., by hiding a client's IP address from a target server. Proxying
> technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own
> shortcomings. For example, SOCKS signalling is not encrypted and HTTP CONNECT
> is currently limited to TCP.
> 
> The primary goal of this working group is to develop mechanism(s) that allow
> configuring and concurrently running multiple proxied stream- and
> datagram-based flows inside an HTTP connection. The group has specified
> CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this
> functionality. MASQUE leverages the HTTP request/response semantics,
> multiplexes flows over streams, uses a unified congestion controller,
> encrypts flow metadata, and enables unreliable delivery suitable for UDP and
> IP-based applications.
> 
> The MASQUE working group will now develop HTTP extensions, which might be
> specific to the HTTP version, to the core client-initiated CONNECT-UDP and
> CONNECT-IP functionality. Services that a proxy initiates without any prompt
> from a client are out of scope.
> 
> Exercising the extension points defined by CONNECT-UDP and CONNECT-IP helps
> to make it easier to support new use cases or accommodate changes in the
> environment in which these protocols are deployed. The initial set of
> extensions will be in support of UDP listening, and CONNECT-UDP proxying
> optimizations when the UDP traffic is QUIC. Additional extensions that
> provide missing functionality, improve performance, or otherwise ease
> deployability for use cases may be adopted where there are multiple
> implementation and/or deployment proponents. The intended status is Standards
> Track, but the WG may downgrade if it believes that is appropriate for the
> ultimate document maturity level.
> 
> Extensions to HTTP Datagrams will be coordinated with HTTPBIS. Extensions
> that solely relate to generic proxying functionality, and are not specific to
> the core MASQUE documents, are out of scope.
> 
> Specifying proxy server discovery mechanisms is out of scope. New congestion
> control and loss recovery algorithms are also out of scope. However, the
> working group will consider implications of tunneling protocols with
> congestion control and loss recovery over MASQUE proxies, and may issue
> recommendations accordingly.
> 
> The working group will consider how the protocols it defines might operate
> over versions of HTTP that use TCP rather than QUIC, for use when QUIC is
> unavailable. This might include defining alternative extensions specifically
> for use in these HTTP versions.
> 
> IP multicast is out of scope. Designs need not explicitly preclude multicast,
> but they will not focus on multicast-specific features.
> 
> Impacts on address migration, NAT rebinding, and future multipath mechanisms
> of QUIC are not anticipated. However, the working group should document these
> impacts, or those of any other QUIC developments, if they arise.
> 
> The group will coordinate closely with other working groups responsible for
> maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It
> will also coordinate closely with ICCRG and TSVWG on congestion control and
> loss recovery considerations, and intarea for IP Proxying.
> 
> MASQUE is not intended to be a long-lived working group.
> 
> Milestones:
> 
>     - Submit an extension for UDP listeners
> 
>     - Submit an extension for QUIC-aware proxying
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce