Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)

I think we are all in agreement with what the WG should do here,
which is write one or several application-layer protocols over QUIC or TLS.
I wrote a short PR to attempt to clarify this in the charter:
https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files

Thoughts?

David

On Mon, Feb 3, 2020 at 12:03 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind <ietf@kuehlewind.net>
> wrote:
>
>> No I meant do you have another protocol proposal (given you said you
>> might not want what is proposed by Victor)?
>>
>
> Well, what I'm actually saying is that it's not clear that we need *all*
> the ones proposed by Victor.
>
> With that said, it's not clear to me if Victor has a TCP binding yet, but
> one is clearly needed.
>
> -Ekr
>
>
>> > On 3. Feb 2020, at 11:55, Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> >
>> >
>> > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind <ietf@kuehlewind.net>
>> wrote:
>> > Yes, totally understood that you don’t want to put any specific
>> protocol suggestions in the charter but right now it seem a bit too loose
>> (from a transport point of view). So if you don’t want what is proposed
>> currently, do you have another proposal?
>> >
>> > I'm fine with the current text. I'm arguing against the attempts to
>> aggressively narrow it.
>> >
>> > -Ekr
>> >
>> > If you are working on a draft yourself, I think it would actually be
>> nice to have a first version of this draft out before the groups is fully
>> started to people discussion the charter right now, would actually better
>> understand what the discussion is about.
>> >
>> > Mirja
>> >
>> >
>> >
>> > > On 3. Feb 2020, at 11:44, Eric Rescorla <ekr@rtfm.com> wrote:
>> > >
>> > > Well, I certainly don't think we should build a new version of QUIC,
>> and it seems likely that QUIC will be involved somehow, but Victor had some
>> quite specific protocol suggestions which might or might not be what we
>> want. In addition we need to ensure that there's some parity via a
>> TCP-based mechanism.
>> > >
>> > > -Ekr
>> > >
>> > >
>> > >
>> > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <ietf@kuehlewind.net>
>> wrote:
>> > > Hi Ekr, hi Martin,
>> > >
>> > > I thought that building something on top of QUIC or H3 are
>> preconditions for any solution. If that is the case I would also prefer to
>> put this in the charter (to exclude it clearly from the scope of this group
>> to rebuild a new QUIC or a new version of quic or something like that which
>> should be done in the quic group; similar for http which should be done in
>> the httpbis in future). If you think that is somehow too restrictive what
>> are the option open, you would want to work on in this new group?
>> > >
>> > > Mirja
>> > >
>> > >
>> > >
>> > > > On 3. Feb 2020, at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
>> > > >
>> > > > As MT says, I would not be comfortable if the charter defined the
>> specific protocol starting points, given the uncertainty about exactly
>> which pieces we will do.
>> > > >
>> > > > -Ekr
>> > > >
>> > > >
>> > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net>
>> wrote:
>> > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
>> > > > > [BA] Would it be sufficient to add this clarification to the
>> existing
>> > > > > sentence? The result would look like this.
>> > > > >
>> > > > > The WebTransport working group will define new client-server
>> protocols
>> > > > > or protocol extensions using QUIC or HTTP3 in order to support
>> the
>> > > >
>> > > > I would instead say "building on existing protocol work" and then
>> point out separately that this will definitely not define a new transport
>> (or lower) layer protocol.
>> > > >
>> > > > At Mozilla we are still uncertain about the set of protocols as
>> currently proposed, and would feel uncomfortable limiting this to just
>> those two *in the charter*.
>> > > >
>> > > > --
>> > > > Webtransport mailing list
>> > > > Webtransport@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/webtransport
>> > > > --
>> > > > Webtransport mailing list
>> > > > Webtransport@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/webtransport
>> > >
>> >
>>
>>