Re: [Masque] Proposed draft charter

Thank you Eric (Kinnear) for writing this. I like the new charter,
especially the fact that the scope is much narrower now.

David

On Tue, Feb 4, 2020 at 4:37 PM Eric Rescorla <ekr@rtfm.com> wrote:

> 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
>>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>