Re: [Masque] Proposed draft charter

[Eric Rescorla <[e-mail]>]

On Mon, Feb 10, 2020 at 4:31 PM Spencer Dawkins at IETF <
[e-mail]> wrote:

> I'm finally reading this charter, as opposed to looking at the words ...
> mostly, this looks fine to me.
>
> A couple of things inline.
>
> On Thu, Feb 6, 2020 at 6:05 AM Eric Kinnear <ekinnear=
> [e-mail]> wrote:
>
>> Awesome, thanks all for the feedback!
>>
>> Updating with the changes proposed by Ekr and Lucas, thanks for the great
>> suggestions.
>>
>> ===============
>>
>> 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 connectivity, multiplexed streams, and connection
>> migration.
>> Further, HTTP/3 supports an established request/response semantic that
>> can be
>> used to set up and configure services.
>>
>
> The definition of QUIC as practiced in 2020 is "HTTP/3 over QUIC",
> although we certainly see proposals for other application protocols over
> something QUIC-like. Would something like
>
> "HTTP/3, carried over QUIC, is a good candidate protocol for tunneling
> these types of traffic, as QUIC
> provides secure connectivity, multiplexed streams, and connection
> migration.
> Further, HTTP/3 supports an established request/response semantic that can
> be
> used to set up and configure services."
>
> make that clearer?
>
>
>> Using QUIC as a tunneling technology allows for proxying of both reliable
>> stream
>> (TCP) and unreliable datagram (UDP) flows.. For stream flows, QUIC streams
>>
>
> I'm a little confused here, about whether (HTTP/3-)QUIC is also in scope
> as a proxied protocol. Does everyone else know whether it is, and I'm just
> catching up?
>

Well, it's just UDP, so yes.

-Ekr