Re: Call for adoption - WEBRTC-QUIC

Based on Harald's description (below), I am in favor of adopting this work.
I believe that a low-level unreliable transport API with built-in security
and bandwidth management would address many existing and novel use cases,
and while we don't yet have all the answers, we have a credible starting
point that we can iterate on.

My personal read is that adoption as a WG document means that "we have
consensus that there is a problem here that needs solving, the problem is
within the scope of this WG, and this document is a start on the way to
solving it".


Regarding the arguments against:
1) "QUIC is too new." QUIC has matured significantly over the past 18
months, and if we wait for QUIC to be done before we start, we will
probably lose the ability to make important changes.
2) "This is the wrong working group." Maybe, but I can't think of another
WG that would have the same need for unreliable transport; we have many
interested parties in this WG. In any case, if we decide another forum is
better, moving to another venue is straightforward.
3) "Existing technology X already does everything that QUIC can do."
Perhaps, but this has been said about QUIC multiple times already (e.g. TCP
Fast Open). I think QUIC has enough novel behaviors that it's worth
exploring further.

Respectfully,
Justin

On Wed, Nov 28, 2018 at 8:33 PM Eric Rescorla <ekr@rtfm.com> wrote:

> On Tue, Nov 20, 2018 at 12:59 AM Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
>> *From the Lyon summary of decisions:*
>>
>>
>>
>> * "The WG will ask the list if we should adopt the WEBRTC-QUIC API
>> document (in room: 2 opposed, ~10 in favor)" The question is whether we
>> should adopt this document: https://w3c.github.io/webrtc-quic/
>> <https://w3c.github.io/webrtc-quic/> as a Working Group document Adoption
>> as a WG document does not mean commitment to any specific part of the API,
>> or any specific timeline for processing the document to CR and beyond, but
>> does mean that we can issue the document as a first public working draft
>> (FPWD) and ask for IPR declarations (if any). My personal read is that
>> adoption as a WG document means that "we have consensus that there is a
>> problem here that needs solving, the problem is within the scope of this
>> WG, and this document is a start on the way to solving it". Non-adoption
>> would indicate either that the problem shouldn't be solved, that the
>> problem is out of scope for this WG, or that this document is so far away
>> from the right solution that it's not a starting point the WG wants to
>> consider. We are seeking both statements of support and statements of
>> opposition. The chairs will tally the responses and attempt to draw a
>> conclusion. Please state your opinion to the list on or before Wednesday,
>> November 28.*
>>
>
> I am not in favor of adopting this work at this time, for two reasons:
>
> 1. The IETF QUIC work is not sufficiently mature to support this.
> Presently, it's just for HTTP.2
> 2. The problem statement is very unclear; it seems primarily to be "have
> QUIC support", but that's not a problem statement, it's a statement of
> solution. The place to start here is with a statement of the technical
> functionality that we want that we don't currently have, and that's not
> what there is now.
>
> -Ekr
>
> * Harald, for the chairs *
>>
>>