Re: [Masque] Updated proposed charter text

[Christopher Wood <[e-mail]>]

On Tue, Mar 31, 2020, at 4:34 PM, Spencer Dawkins at IETF wrote:
> Hi, Christopher, 
> 
> Thanks for getting this update out so quickly. 
> 
> I have thoughts, but wanted to start with the first couple of paragraphs. 
> 
> On Tue, Mar 31, 2020 at 11:43 AM Christopher Wood <[e-mail]> wrote:
> > Based on last week's meeting, it seems folks are generally enthusiastic about some form of MASQUE moving forward. To help scope that particular form, here's an update to the proposed charter. 
> > 
> >  ~~~
> >  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). 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. In contrast, HTTP/3 is a viable candidate protocol for proxying arbitrary traffic, as it provides secure connectivity, multiplexed streams, and migration for a single connection while taking advantage of a unified congestion controller. HTTP/3 datagrams provide for unreliable data transmission, which enables transporting UDP and other unreliable flows via a proxy without introducing potentially redundant or unnecessary recovery mechanisms. Further, HTTP/3 supports an established request/response semantic that can set up and configure flows for different services.
> 
> If I remember correctly, somewhere between the audio conference and the 
> active jabber conversation, there were people who mentioned
>  * proxies
>  * relays
>  * tunnels
>  * VPNs
>  * NATs, and 
>  * now that I look at the second paragraph, maybe even firewalls
> Is it possible to agree on the functionalities that this community of 
> interest is thinking of, as part of the charter discussion? 
>
> ISTM that if we're talking about "connect for IP", we're closer to a 
> tunnel than a proxy, and I don't think that's what most of the MASQUE 
> folk were thinking of. 
>
> Perhaps this will fall out of the use cases people have been collecting?

Yep, I expect that to be the case! While the use cases in the charter are not meant to be exhaustive, more specificity would probably help frame the rest of the content. 

Meta question: are you looking for a specific change in the text, and if so, what might that be?

Best,
Chris