Re: [Masque] Updated proposed charter text

[Eric Rescorla <[e-mail]>]

On Mon, Apr 6, 2020 at 10:24 AM Mirja Kuehlewind <
[e-mail]> wrote:

> Hi Lucas, hi Ekr,
>
>
>
> see inline.
>
>
>
> *From: *Lucas Pardue <[e-mail]>
> *Date: *Monday, 6. April 2020 at 17:59
> *To: *Eric Rescorla <[e-mail]>
> *Cc: *Mirja Kuehlewind <[e-mail]>, Christopher Wood <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [Masque] Updated proposed charter text
>
>
>
>
>
>
>
> On Mon, Apr 6, 2020 at 4:48 PM Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Mon, Apr 6, 2020 at 8:43 AM Mirja Kuehlewind <mirja.kuehlewind=
> 40ericsson.com@dmarc..ietf.org <[e-mail]>> wrote:
>
> Hi Chris,
>
> In draft-schinazi-masque-protocol I would say that the QUIC, UDP, and IP
> proxying services run directly on top of QUIC without any HTTP in between
> (HTTP is only used only for the negotiation part but not for the
> forwarding/multiplexing).
>
>
>
> Philosophy aside, do we agree that these messages would be carried in QUIC
> Datagram frames (https://tools.ietf.org/html/draft-ietf-quic-datagram-00)?
>
>
>
> [MK] Yes, for datagram-based flows. And QUIC stream frames for
> stream-based flows.
>
>
OK.

Therefore I think it would be more correct to actually change this one
> occurrence of HTTP3 back to  QUIC in the following sentence:
>
> "The primary goal of this working group is to develop mechanisms that
> allow configuring and concurrently running multiple proxied stream- and
> datagram-based flows inside a HTTP/3 connection"
>
>
>
> I'm not sure that this is right. If you use the H3 ALPN token and then use
> H3 to negotiate but also negotiate datagram, this seems like an H3
> connection to me.
>
>
>
> [MK] I guess it gets a bit philosophical now: If we would have an own
> ALPN token for masque (which is reasonable for some use cases) but still
> use the HTTP-based scheme as proposed in draft-schinazi-masque-protocol by
> POSTing for configuration parameters, would that still be H3?
>
> Well, ISTM that if we are using H3 for negotiation, then we should be
using the H3 ALPN token.

-Ekr



>
> [MK] I mean I think we are aligned here what we want. I just don’t want to
> be over-restrictive in the charter by calling it there a H3 connection
> while calling it a QUIC connection would be fine as well.
>
>

>
>
>
> -Ekr
>
>
>
>
>
> I would find using "QUIC" in place of "HTTP/3" confusing. QUIC requires an
> authenticated negotiation of the application protocol and we use ALPN for
> that today. There is no mechanism to my knowledge that would allow the
> creation of just a QUIC connection, and I don't even think MASQUE requires
> that.
>
>
>
> IMO it be more accurate for us to say, "The primary goal of this working
> group is to develop HTTP mechanisms that allow configuration of QUIC
> transport features inside an HTTP/3 connection, with the aim to
> concurrently run multiple proxied stream- and datagram-based flows."
>
>
>
> [MK] I think we need more than just “configuration of QUIC transport
> features“ as the forwarding part itself and any operations needed for the
> forwarding part e.g. address translation or some kind of header compression
> are not a QUIC transport feature.
>
>
>
> [MK] However basically asking you the same again:
> draft-schinazi-masque-protocol proposed a POST-based mechanism to exchange
> configuration parameter. Is that really a HTTP mechanism for you? For me
> that a new protocol that uses HTTP underneath.
>
>
>
> Mirja
>
>
>
>
>
>