Re: [Masque] Proposed draft charter

Generally LGTM. Some comments below.

On Tue, Feb 4, 2020 at 7:30 AM Eric Kinnear <ekinnear=
40apple.com@dmarc.ietf.org> wrote:

> Hi all,
>
> There’s been some good discussion on this thread, which has led to some
> potential improvements in the draft charter.
>
> Here’s some proposed text which tightens things up quite a bit and tries
> to clarify many of the parts that caused concern. Thoughts and feedback
> welcome!
>
> Thanks,
> Eric
>
>
>
> ==================
>
> 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 and can apply additional encryption
> where desirable (such as a VPN).
>
> QUIC is a good candidate protocol for tunneling these types of traffic, as
> QUIC
> provides secure connection establishment, multiplexed streams, and
> connection
> migration. Further, HTTP/3 provides an existing request/response syntax
> that can
> be used to set up and configure services
>

Note: not just secure connection establishment, but also secure transport.

.
>

>
>
> Using QUIC as a tunneling technology allows for proxying of both reliable
> stream
> (TCP) and unreliable datagram (UDP) flows. For stream flows, QUIC streams
> provide reliable in-order delivery across the client-proxy link. QUIC
> datagrams
> provide for unreliable data transmission, which allows for transporting
> UDP and
> other unreliable flows via a proxy without introducing potentially
> redundant or
> unnecessary recovery mechanisms. In addition, QUIC can carry both types of
> streams over the same connection while taking advantage of a unified
> congestion
> controller.
>

Maybe "both types of flows" because QUIC streams are a specific thing.

>
>
> This working group will work on MASQUE (Multiplexed Application Substrate
> over
> QUIC Encryption), a framework that allows concurrently running multiple
> proxied
> flows inside a QUIC connection. The MASQUE framework will specify a
> signaling
> protocol that is used between the endpoint(s) and the MASQUE server to
> negotiate
> proxy services that establish tunneled connectivity. The initial
> functionality
> will be limited to client-initiated proxy tunnels. The WG may subsequently
> recharter to consider other applications.
>
> Proxy services that extend the signaling of the base MASQUE protocol can be
> adopted by the group by creating a new milestone with AD review.
>
> If MASQUE requires any extensions to existing protocols, the group will
> coordinate closely with the respective group responsible for maintaining
> that
> protocol, such as the HTTPBIS, QUIC, or TLS working groups.
>
> ==================
>
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>