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

From: "Martin Thomson" <[email-masked]>
Date: Sat, 01 Feb 2020 20:53:25 +0100

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*.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2020 02:23:29 -0800

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 <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 3 Feb 2020 11:42:07 +0100

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 <[email-masked]> 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
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2020 02:44:48 -0800

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 <[email-masked]> 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
>
>
>
> > 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
> >
> >
> > 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*.
> >
> > --

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 3 Feb 2020 11:52:52 +0100

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? 

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 <[email-masked]> 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
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2020 02:55:33 -0800

On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind <[email-masked]> 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
>
>
>
> > 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
> >
> >
> >
> > > 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.
> > >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 3 Feb 2020 11:57:05 +0100

No I meant do you have another protocol proposal (given you said you might not want what is proposed by Victor)?

> On 3. Feb 2020, at 11:55, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I'm fine with the current text. I'm arguing against the attempts to aggressively narrow it.
> 
> -Ekr
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2020 03:02:20 -0800

> 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

> > 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
> > > 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
> > > 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
> > >
> > >
> > >

---

From: David Schinazi <[email-masked]>
Date: Mon, 3 Feb 2020 12:10:13 +0100

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 <[email-masked]> wrote:

>> No I meant do you have another protocol proposal (given you said you
>> might not want what is proposed by Victor)?
>>
>
>> > 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?
>> >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 3 Feb 2020 12:40:42 +0100

I know (or hope) that is not the plan but this new text would still leave the option open to design a new version of http in this group… however, from a transport point of view this is certainly better.

When you say TLS in that next text, do you mean TLS or TCP, or was that meant to also include DTLS? 

Mirja

> On 3. Feb 2020, at 12:10, David Schinazi <[email-masked]> wrote:
> 
> 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
> 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 3 Feb 2020 12:42:50 +0100

My understanding is that Victor proposed a (separate) binding for H3 or QUIC + you say there should also be a binding for TCP (or I guess TLS over TCP). If that are the three option why not writing in the charter that the group works on either separate binding for these cases or one binding that might cover multiple of these protocols?

Mirja

> On 3. Feb 2020, at 12:02, Eric Rescorla <[email-masked]> wrote:
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Feb 2020 04:26:46 -0800

On Mon, Feb 3, 2020 at 3:42 AM Mirja Kuehlewind <[email-masked]> wrote:

> My understanding is that Victor proposed a (separate) binding for H3 or
> QUIC + you say there should also be a binding for TCP (or I guess TLS over
> TCP). If that are the three option why not writing in the charter that the
> group works on either separate binding for these cases or one binding that
> might cover multiple of these protocols?
>

I don't understand what this means. My point is I *don't* think we should
do an H3 binding.

-Ekr

---

From: David Schinazi <[email-masked]>
Date: Mon, 3 Feb 2020 14:32:27 +0100

Hi Mirja,

We have not yet reached consensus on the exact details of a solution, which
is what we'd like to do in the newly formed working group.
In particular, we don't know if the new protocol will run over HTTP/3 or
QUIC directly (or if we build both) for example.
Therefore we wrote the charter in such a way that the working group will be
able to make that decision.
The latest PR
<https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files> attempts
to clarify that this application protocol will run over QUIC or TLS (by TLS
I mean TLS, not anything else like DTLS or eTLS) to
address your concern that we might reinvent QUIC, which we explicitly do
not want to do.

If you don't think the PR
<https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files>
achieves this intent clearly, can you please propose text?

Thanks,
David

On Mon, Feb 3, 2020 at 1:27 PM Eric Rescorla <[email-masked]> 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
>> > > >
>> > > >
>> > > >

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 4 Feb 2020 09:15:36 +0000

Hi,

Please see inline. 

On Fri, 2020-01-31 at 19:09 -0800, Bernard Aboba wrote:
> Comments below.
> 
> > From: Magnus Westerlund via Datatracker <[email-masked]>
> > Date: January 31, 2020 at 08:39:10 PST
> > To: The IESG <[email-masked]>
> > Cc: [email-masked], [email-masked], [email-masked]
> > Subject: Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with
> > BLOCK and COMMENT)
> > Reply-To: Magnus Westerlund <[email-masked]>
> > 
> > Magnus Westerlund has entered the following ballot position for
> > charter-ietf-webtrans-00-00: Block
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/charter-ietf-webtrans/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > BLOCK:
> > ----------------------------------------------------------------------
> > 
> > This charter is so open ended on what protocol that is to be developed that
> > it
> > could define a new IP version as well as transport protocols. I don't think
> > that is the intention.
> 
> [BA] Definitely not the intention .
> 
> > To my understanding this effort could more clearly be
> > defined as defining one or two application protocol that fulfills the
> > WebTransport API and is using QUIC or HTTP/3.
> 
> The WebTransport working group will define new client-server protocols or
> protocol extensions using QUIC or HTTP3 in order to support the development of
> the W3C WebTransport API https://wicg.github.io/web-transport.
> 

As this part spun of into a rather long thread I will respond to this aspect
seperately. 

> > If the charter can be clarified
> > to not include transport protocol work and which existing transport
> > protocols
> > or other protocols the solution will build on it would be much better and
> > well
> > defined work. I also think creating mappings to other transport protocols
> > should require rechartering to enable a wider discussion of such choices.
> > 
> > Secondly:
> > 
> > The group will also coordinate with related working groups within the IETF,
> > such as QUIC and HTTPBIS, as appropriate.
> > 
> > With the current state of QUIC development and HTTP/3 mapping definition,
> > i.e.
> > still working on the initial version, I would like to have a more firm
> > wording
> > that the WebTrans WG will actually have to take any requests for extensions
> > of
> > HTTP/3 and QUIC to the relevant WG.
> 
> [BA] Would the following work?
> 
> “The group will also coordinate with related working groups within the IETF,
> such as QUIC and HTTPBIS, as appropriate.  Requests for extensions of HTTP/3
> and QUIC will be brought to the relevant WG.”

Yes. 

> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > I also would appreciate if someone can clarify what stage of formality the
> > Web-Transport API has been adopted in W3C and is being worked on.
> 
> [BA] The WebTransport API is currently under development within the W3C WICG: 
> https://wicg.github.io/web-transport/
> 
> Since the API is maturing, there is interest in moving ahead with the
> standardization process.  However, the next steps are not yet clear.  My last
> conversation with W3C management indicated that they were considering the
> implications of the recently concluded W3C-WHATWG agreement.  See the end of
> this message for details. 

So to my understanding the current formality standing in the W3C is something
equal to a proposed BOF. There exist individual drafts that a set of proponents
are working on, but no formal WG to take on the work. 

So for the moment I think the charter is missrepresenting what the actual W3C
state of the effort actually is. I understand the issues with moving target
here. Do we have an okay from W3C in doing in it this way. From a reputation
aspect I don't want IETF's acting here result in souring the relationship. 

I also think the next comment from me is relevant in this discussion as it is a
matter on who is pushing requirements for this effort on who. 

> 
> > Trying to
> > find anything about which group it belongs to on the W3C page didn't give me
> > any information. All I found is that there have been a workshop on game
> > communication where this was discussed and raised in some discussions.
> > Having lived through the WebRTC / RTCWeb interactions it would good to know
> > more how the interaction between the bodies are intended to work. Especially
> > as
> > changes to the API can have significant impact on what work needs to happen
> > in
> > the IETF.
> 
> [BA] Overall, the information flow seems more likely to go from protocol to
> API than the other way around.  At least that’s how things have worked so far
> with the WebTransport API, whose development mirrored the development of the
> QUIC transport protocol (e.g. Introducing uni-directional streams once this
> was introduced in the protocol).  Also, please keep in mind that protocols
> tend to have a longer lifetime than APIs (e.g. there are multiple WebSockets
> APIs, some message-based, others streams-based). 

I would note that I think this actually have significant impact on the IETF
charter. First I thought the API would be the requirements generating process
for this work that IETF would need to follow. Now I have the impression that the
WG will discuss and agree on what semantics the WebTrans protocol(s) will
provide. Thus, it is the IETF that will push the basic semantics onto W3C. Are
they formally fine with that? 

This makes me wondering if the charter either needs to be explicit about the
need to come to consensus on what those simple communication methods are. The
charter lists unreliable messages, reliable messages and ordered streams of
reliable messages. So this is in the charter not an exhaustive list, and thus
there is an opening for the WG to add more. 

> 
> > The current API draft does not include any discussion of priority. However
> > draft-vvv-webtrans-overview does mention priorities. As this API appears to
> > support multiple parallel transmissions and transfers I think at a minimal a
> > sender transport protocol scheduling or HTTP/3 priority  would be likely to
> > be
> > part of the work. I also have to ask if this is likely to attempted to be
> > mapped also towards the network level, for example DSCPs? If any such work
> > is
> > expected and intended I think that needs to be raised. Otherwise I would
> > assume
> > that at most what this work will be to use the undefined APIs to HTTP/3 and
> > QUIC to influence those protocol to perform stream priorities.
> 
> [BA] Priority has not faired well within recent W3C API efforts, including
> RTCDataChannel and WebRTC.  So not sure how much energy there is. Also see
> Ted’s message relating to the status of priority in HTTP/3. 

Okay, so no initial intention and there is potential work that is ongoing that
may be relevant for the future. So, should this be explicit out of scope, or
just not mentioned leaving some wiggle room for the WG? 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 4 Feb 2020 09:32:55 +0000

Hi,

Please read my answer to Bernard's initial answer on my block as this is part of
the context for this response. 

So from my perspective, I think it is good to explicitly state that the WG will
use existing transport protocols. I think what Mirja was fishing after, is the
question, do you actually intended to use UDP/DTLS and build something on top of
that? I would strongly prefer that you do not. Becasue if you do the WG will
have to a have a congestion control solution baked into this. Which at a minimal
forces the WG to develop a protocol with a feedback solution over UDP to carry
information necessary for the congestion control loop. In that case I think this
WG slides sufficiently into transport land that I would request that this
becomes a TSV WG. So can we at least rule UDP/DTLS out of scope? 

Frankly I don't care if this is QUIC and/or HTTP/3 specific or also have a
TCP/TLS mapping also. However, this discussion do indicates that the WG would
need to start with forming some consensus on those questions. And I think it
also affects the timeline of the work. 

The other relevant aspect of this scope setting was my comment that the API does
not appear to be binding at all, rather it becomes a question of what the WG
have consensus on. The current charter text defines that the WG must at least do
three communciation methods:
 - Unreliable messages (if it can support fragemntation or not is undefined)
 - Reliable messages (based on wording likely with fragmentation, i.e. support
larger messages than one Path MTU)
 - Ordered streams of reliable messages (I assume supporting large message
sizes)

But, the above is not necessary an exhaustive list. Also the additiona details
are not defined. To me this indicates that the WG will have to either do an
initial effort to define the desired properties or take the proposals and then
document the actual properties. Does the charter needs any wording on how it
intends to work on that aspect. 

Cheers

Magnus Westerlund
TSV AD

On Mon, 2020-02-03 at 14:32 +0100, David Schinazi wrote:
> Hi Mirja,
> 
> We have not yet reached consensus on the exact details of a solution, which is
> what we'd like to do in the newly formed working group.
> In particular, we don't know if the new protocol will run over HTTP/3 or QUIC
> directly (or if we build both) for example.
> The latest PR attempts to clarify that this application protocol will run over
> QUIC or TLS (by TLS I mean TLS, not anything else like DTLS or eTLS) to
> address your concern that we might reinvent QUIC, which we explicitly do not
> want to do.
> 
> If you don't think the PR achieves this intent clearly, can you please propose
> text?
> 
> Thanks,
> David
> 
> 
> > I don't understand what this means. My point is I *don't* think we should do
> > an H3 binding.
> > 
> > -Ekr
> > 
> > > Mirja
> > > 
> > > 
> > > 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 <[email-masked]
> > > > wrote:
> > > > > > Hi Ekr, hi Martin,
> > > > > > 
> > > 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
> > > > > > 
> > > > > > 
> > > > > > 
-- 
Cheers

Magnus Westerlund

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 4 Feb 2020 11:06:41 +0100

I believe most of those have been addressed in David's PR, so I'll try to
reply
primarily to those that I have something to add to.

> https://datatracker.ietf.org/doc/charter-ietf-webtrans/
[snip]

> With the current state of QUIC developement and HTTP/3 mapping definition,
> i.e.
> that the WebTrans WG will actually have to take any requests for
> extensions of

While there are no extensions to QUIC among the proposed WG documents, some
of
the drafts do extend HTTP using custom SETTINGS parameters (which is the
intended HTTP extensibility mechanism).  I've hitherto assumed that webtrans
would work with HTTP experts in httpbis/quic to ensure that the proposed
extensions are architecturally sound and follow best practices, but the main
bulk of work would be done in the new working group itself.

> Web-Transport API has been adopted in W3C and is being worked on. Trying to

It's a WICG draft, which basically means no formal status.  We had a
discussion
session at TPAC last year, and I believe most people who'd be normally
involved
are aware of it, but my current understanding is that the editors of the W3C
spec currently do not believe we have enough real-world implementation
experience with the proposal to advance it further in the formal process.

> more how the interaction between the bodies are intended to work.
> Especially as
> changes to the API can have significant impact on what work needs to
> happen in
> the IETF.
>

I mostly agree with Bernard here.  My plan was that the -overview doc would
list all of the protocol requirements and API expectations, acting as
integration point between W3C and IETF specs.

> sender transport protocol scheduling or HTTP/3 priority  would be likely
> to be

This is mostly a gap in the API spec.  I've been meaning to write this up
further, but there's a lot of text to write.

Before I elaborate further, I would like to point out that there are two
types
of priorities here, and those are often confused:
(1) Priorities that the application indicates to the transport layer for the
    purpose of scheduling writes.
(2) Priorities that are communicated to the peer on the wire as a hint.

Most of the discussion in HTTPBIS and QUIC WGs was about #2.  I don't
believe
any of the proposed drafts cover that topic, and I'd rather wait for
quic/httpbis to come up with a mechanism first.

The priorities mentioned in -overview are of the #1 kind.  Section 2.3 of
draft-ietf-quic-transport-25 explicitly encourages implementations (that
would
include the proposed Web APIs) to provide those:

"""
[QUIC] relies on receiving priority information from the application that
uses
QUIC.

A QUIC implementation SHOULD provide ways in which an application can
indicate
the relative priority of streams. When deciding which streams to dedicate
resources to, the implementation SHOULD use the information provided by the
application.
"""

Besides, I don't believe we can avoid defining a write scheduling mechanism
in
the API.  QUIC itself treats it as an implementation detail, but Web APIs
generally try really hard to avoid implementation-defined behavior.  If
every browser had a completely different write scheduling approach,
that could make the job of writing performant cross-browser code really
difficult.

Thanks,
  Victor.

---

From: David Schinazi <[email-masked]>
Date: Thu, 6 Feb 2020 14:46:34 +0100

Hi Magnus,

I realized that some of our earlier replies were accidentally not sent to
the IESG list, for which I apologize.

To summarize that discussion:

- It is not our intention to build a new transport protocol here.
The WEBTRANS WG would build application protocols that
run over QUIC, or TLS/TCP. This would ensure we benefit
from their security and congestion control properties.
Here is a PR to the charter that should clarify this:
https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files

- The WEBTRANS WG would not modify QUIC or HTTP.
Any discussion of modifying those core protocols would
happen in their existing respective working groups.
However, discussion of extensions to these protocols could
be allowed in this WG, as long as any document WGLC is
also sent to the mailing list responsible for that protocol.

Would that be an acceptable scope?

Thanks,
David

On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev <[email-masked]> wrote:

>> With the current state of QUIC developement and HTTP/3 mapping
>> definition, i.e.
> While there are no extensions to QUIC among the proposed WG documents,
> some of
>> mapped also towards the network level, for example DSCPs? If any such
>> work is
> Besides, I don't believe we can avoid defining a write scheduling
> mechanism in

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 11 Feb 2020 13:38:13 +0100

Hi David,

One more comment below.

> On 6. Feb 2020, at 14:46, David Schinazi <[email-masked]> wrote:
> 
> Hi Magnus,
> 

I think this is not sufficient, at least not for QUIC. More discussion is needed in the QUIC group on this but currently I think the assumption should be that all extensions will be done within the QUIC group. So just sending a WGLC there is not sufficient.

More generally deciding on processes for other protocols/groups in this charter is not appropriate. I’m not sure what the defined process is for HTTP and TLS but that should be specified in their charter and not here.

For QUIC, I would like to rather see that extension or modification are out of scope for this group. Of course that doesn’t mean that this group cannot talk about any extension but as soon as the group thinks an extension is needed, it needs to go to the QUIC group and cannot just adapt anything within WebTransport.

Please also double-check what the right process is for TLS and HTTP. I assume for TLS it's the same but for HTTP it might be different…?

Mirja

> I believe most of those have been addressed in David's PR, so I'll try to reply
> On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker <[email-masked]> wrote:
> With the current state of QUIC developement and HTTP/3 mapping definition, i.e.
> still working on the initial version, I would like to have a more firm wording
> that the WebTrans WG will actually have to take any requests for extensions of
> While there are no extensions to QUIC among the proposed WG documents, some of
> It's a WICG draft, which basically means no formal status.  We had a discussion
> session at TPAC last year, and I believe most people who'd be normally involved
> more how the interaction between the bodies are intended to work. Especially as
> changes to the API can have significant impact on what work needs to happen in
> the IETF.
> 
> sender transport protocol scheduling or HTTP/3 priority  would be likely to be
> mapped also towards the network level, for example DSCPs? If any such work is
> expected and intended I think that needs to be raised. Otherwise I would assume
> Before I elaborate further, I would like to point out that there are two types
> Most of the discussion in HTTPBIS and QUIC WGs was about #2.  I don't believe
> draft-ietf-quic-transport-25 explicitly encourages implementations (that would
> [QUIC] relies on receiving priority information from the application that uses
> QUIC.
> 
> A QUIC implementation SHOULD provide ways in which an application can indicate
> Besides, I don't believe we can avoid defining a write scheduling mechanism in

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 Feb 2020 12:46:39 -0800

Hi Mirja,

I'm not sure I agree with your interpretation. The fact that a WG is
responsible for a protocol does not mean that other working groups
cannot write extensions to that protocol.

For example, the QUIC WG is defining the quic_transport_parameters
TLS extension. That extension is not defined in the TLS WG.
https://tools.ietf.org/html/draft-ietf-quic-tls-25#section-8.2

Similarly, the ACME WG is defining the Cert-Not-Before HTTP
header, not the HTTP WG.
https://tools.ietf.org/html/draft-ietf-acme-star-11#section-6.7

Additionally, MPTCP is an extension to TCP that was not
defined in the TCPM WG. The list goes on.

We don't yet have examples for QUIC as the QUIC IANA
registries haven't been created yet, but I don't see why QUIC
would be different from TLS, HTTP, or TCP.

David

On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind <[email-masked]>
wrote:

> I think this is not sufficient, at least not for QUIC. More discussion is
> needed in the QUIC group on this but currently I think the assumption
> should be that all extensions will be done within the QUIC group. So just
> sending a WGLC there is not sufficient.
>
> More generally deciding on processes for other protocols/groups in this
> charter is not appropriate. I’m not sure what the defined process is for
> HTTP and TLS but that should be specified in their charter and not here.
>
> For QUIC, I would like to rather see that extension or modification are
> out of scope for this group. Of course that doesn’t mean that this group
> cannot talk about any extension but as soon as the group thinks an
> extension is needed, it needs to go to the QUIC group and cannot just adapt
> anything within WebTransport.
>
> Please also double-check what the right process is for TLS and HTTP. I
> assume for TLS it's the same but for HTTP it might be different…?
>
> Mirja
>
>
>
> >

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 12:49:30 -0800

I basically agree with David. I might argue for a slightly higher level of
implied coordination between the WGs than WGLC, but honestly given the
large degree of overlap, I don't think we need to be that prescriptive.

-Ekr

On Tue, Feb 11, 2020 at 12:47 PM David Schinazi <[email-masked]>
wrote:

>> > (2) Priorities that are communicated to the peer on the wire as a hint..
>> >

---

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Tue, 11 Feb 2020 22:30:57 +0100

Hi David,

I didn’t say that other groups cannot define extension. I did say that it’s the decision of the working group that maintains the protocol how to handle that and for Quic we didn’t have had that discussion yet. 

Examples for groups that explicitly define process for extending the protocol in their charter are dhc and 6man. As you can see different groups/protocols have different process and as we didn’t define anything yet for Quic, the working assumption for now should be that all extension work will be fine in the Quic group.

Mirja

> Am 11.02.2020 um 21:47 schrieb David Schinazi <[email-masked]>:
> 
> 
> Hi Mirja,
> 
>> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind <[email-masked]> wrote:
>> Hi David,
>> 
>> One more comment below.
>>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Feb 2020 13:34:32 -0800

On Tue, Feb 11, 2020 at 1:31 PM "Mirja Kühlewind (IETF)" <
[email-masked]> wrote:

> Hi David,
>
> I didn’t say that other groups cannot define extension. I did say that
> it’s the decision of the working group that maintains the protocol how to
> handle that and for Quic we didn’t have had that discussion yet.
>
> Examples for groups that explicitly define process for extending the
> protocol in their charter are dhc and 6man. As you can see different
> groups/protocols have different process and as we didn’t define anything
> yet for Quic, the working assumption for now should be that all extension
> work will be fine in the Quic group.
>

Well, the IANA considerations for QUIC transport seem fairly clear:

https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4

Most of the code points are assigned via Specification Required, so I don't
see why you would infer that all extensions happen within the QUIC WG.

-Ekr

>> > (2) Priorities that are communicated to the peer on the wire as a
>> hint...
>> >

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 Feb 2020 14:03:59 -0800

> work will be fine in the Quic group.

Your examples don't prevent other working groups from defining extensions.
The 6man charter is very clear on this point: it gives 6man the option to
provide input on IPv6 extensions defined in other WGs, it does not prevent
other WGs from defining IPv6 extensions. RPL (RFC 6550) is an example of
the ROLL WG defining an IPv6 extension.
RFC 5986 is an example of the GEOPRIV WG defining a DHCP option. On this
specific one, the DHC charter has an explicit custom definition of a DHCP
option vs a DHCP extension, but any extensions that WEBTRANS would produce
would be closer to options than to extensions in the DHC meaning of the
terms. And the QUIC WG has an existing charter that does not prevent work
on QUIC extensions in other WGs.
Could you elaborate on why you want to prevent the WEBTRANS WG from
producing extensions? I think I'm misunderstanding the motivation here.

David

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 Feb 2020 00:33:25 -0500

Magnus, the charter has been updated.  Will you check whether -01 will
clear your BLOCK?

Thanks,
Barry

On Fri, Jan 31, 2020 at 11:39 AM Magnus Westerlund via Datatracker <
[email-masked]> wrote:

> This charter is so open ended on what protocol that is to be developed
> that it
> that is the intention. To my understanding this effort could more clearly
> be
> WebTransport API and is using QUIC or HTTP/3. If the charter can be
> clarified

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 12 Feb 2020 11:45:44 +0100

Hi David,

Again, I don’t want to prevent anybody from defining extension, I’m only saying the process is not defined yet (as you say below, there is nothing in the QUIC charter (yet) that talks about it because so far there was not even an option to define extensions for QUIC at all because QUIC didn’t exists fully yet).

We have to have this discussion in the QUIC group and need to add something to the QUIC charter with the new re-charter we likely will do in summer. And therefore it is not okay to make up an alternative process within the WebTransport charter.

Mirja

> On 11. Feb 2020, at 23:03, David Schinazi <[email-masked]> wrote:
> 
> 
> 
> On Tue, Feb 11, 2020 at 1:31 PM "Mirja Kühlewind (IETF)" <[email-masked]> wrote:
> Hi David,
> 
> The 6man charter is very clear on this point: it gives 6man the option to provide input on IPv6 extensions defined in other WGs, it does not prevent other WGs from defining IPv6 extensions. RPL (RFC 6550) is an example of the ROLL WG defining an IPv6 extension.
> RFC 5986 is an example of the GEOPRIV WG defining a DHCP option. On this specific one, the DHC charter has an explicit custom definition of a DHCP option vs a DHCP extension, but any extensions that WEBTRANS would produce would be closer to options than to extensions in the DHC meaning of the terms. And the QUIC WG has an existing charter that does not prevent work on QUIC extensions in other WGs.
> Could you elaborate on why you want to prevent the WEBTRANS WG from producing extensions? I think I'm misunderstanding the motivation here.
> 
> David
> 
>  
> Mirja
> 
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 12 Feb 2020 11:48:38 +0100

Hi Ekr,

Yes, it is specification required, however, if we decide to pushing an RFC then we need to decide where this work in the IETF can be don best. 

All I’m saying that the process how and where to define QUIC extensions in the IETF needs to be decided by the QUIC group and a future QUIC charter and not by the charter of any other working group. Again that doesn’t mean that in future it will not be possible for other groups to define extension but we need to have that discussion first.

Mirja

> On 11. Feb 2020, at 22:34, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> Most of the code points are assigned via Specification Required, so I don't see why you would infer that all extensions happen within the QUIC WG.
> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
> Mirja
> 
> 
>> > (2) Priorities that are communicated to the peer on the wire as a hint....
>> >

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Feb 2020 06:14:44 -0800

On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind <[email-masked]>
wrote:

> Hi Ekr,
>
> Yes, it is specification required, however, if we decide to pushing an RFC
> then we need to decide where this work in the IETF can be don best.
>

This seems like a very odd position. As soon as the QUIC RFC is published,
anyone else in the world can assign new QUIC code points, but inside the
IETF, until there;s some discussion in the QUIC there won't be any process
other than asking the QUIC WG?

> All I’m saying that the process how and where to define QUIC extensions in
> the IETF needs to be decided by the QUIC group and a future QUIC charter
> and not by the charter of any other working group.

I don't understand what process you think requires this. There was never
any such formal discussion in the TLS WG AFAIK. In my experience when some
WG wants to define a TLS extension there's a brief discussion between the
chairs and ADs about whether it's orthogonal enough to do separately. It's
not in the TLS charter, for instance, AFAICT.

-Ekr

Again that doesn’t mean that in future it will not be possible for other
> groups to define extension but we need to have that discussion first.
>
> Mirja
>
>
>
> > Most of the code points are assigned via Specification Required, so I
> don't see why you would infer that all extensions happen within the QUIC WG.
> >
> > -Ekr
> >
> >
> >
> >
> >
> >
> >
> > Mirja
> >
> >
> >> Am 11.02.2020 um 21:47 schrieb David Schinazi <[email-masked]
> >:
> >>
> >> 
> >> Hi Mirja,
> >>
> >> I think this is not sufficient, at least not for QUIC. More discussion
> is needed in the QUIC group on this but currently I think the assumption
> hint....

---

From: Barry Leiba <[email-masked]>
Date: Wed, 12 Feb 2020 09:26:09 -0500

I have to agree with EKR here: I'm not aware of any other protocols
that define Specification Required extension mechanisms where we say
that the original working group should be in control of the
extensions.  I wouldn't want to start it here.

The ADs will designate experts to review the extension specifications,
and that is the mechanism for the working group to have its say in the
extensions.  And in this case, the charter explicitly says that
webtrans will coordinate with quic.  I see no reason to be more
specific here, nor to require more.

Barry

On Wed, Feb 12, 2020 at 9:15 AM Eric Rescorla <[email-masked]> wrote:
>
>
>
> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind <[email-masked]> wrote:
>>
>> Hi Ekr,
>>
> This seems like a very odd position. As soon as the QUIC RFC is published, anyone else in the world can assign new QUIC code points, but inside the IETF, until there;s some discussion in the QUIC there won't be any process other than asking the QUIC WG?
>
>
>>
>> All I’m saying that the process how and where to define QUIC extensions in the IETF needs to be decided by the QUIC group and a future QUIC charter and not by the charter of any other working group.
>
>
> I don't understand what process you think requires this. There was never any such formal discussion in the TLS WG AFAIK. In my experience when some WG wants to define a TLS extension there's a brief discussion between the chairs and ADs about whether it's orthogonal enough to do separately. It's not in the TLS charter, for instance, AFAICT.
>
> -Ekr
>
>> Again that doesn’t mean that in future it will not be possible for other groups to define extension but we need to have that discussion first.
>>
>> Mirja
>>
>>
>>
>> >> > On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker <noreply@ietf..org> wrote:
>> >> > It's a WICG draft, which basically means no formal status..  We had a discussion
>> >> > QUIC to influence those protocol to perform stream priorities..
>> >> >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 12 Feb 2020 15:40:22 +0100

The whole point is that the QUIC protocol is not finished yet and the respective registry doesn’t exists yet. All I’m saying that we should not bake process in the the webtransport charter that might restrict a future discuss we want to have in the QUIC group.

> On 12. Feb 2020, at 15:26, Barry Leiba <[email-masked]> wrote:
> 
>>>> Most of the code points are assigned via Specification Required, so I don't see why you would infer that all extensions happen within the QUIC WG..
>>>> 
>>>> -Ekr
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Mirja
>>>> 
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Feb 2020 07:13:21 -0800

On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind <[email-masked]>
wrote:

> The whole point is that the QUIC protocol is not finished yet and the
> respective registry doesn’t exists yet.

And WebTransport will have a normative dependency on QUIC and therefore
will not be finished prior to that registry existing.

All I’m saying that we should not bake process in the the webtransport
> charter that might restrict a future discuss we want to have in the QUIC
> group.
>

What future discussion? As I said, the IANA considerations implicit decide
this matter. Is someone arguing to change those to Standards Track?

-Ekr

> >>> Yes, it is specification required, however, if we decide to pushing an
> RFC then we need to decide where this work in the IETF can be don best.
> >>
> >>
> >> This seems like a very odd position. As soon as the QUIC RFC is
> published, anyone else in the world can assign new QUIC code points, but
> inside the IETF, until there;s some discussion in the QUIC there won't be
> any process other than asking the QUIC WG?
> >>
> >>
> >>>
> >>> All I’m saying that the process how and where to define QUIC
> extensions in the IETF needs to be decided by the QUIC group and a future
> QUIC charter and not by the charter of any other working group.
> >>
> >>
> >> I don't understand what process you think requires this. There was
> never any such formal discussion in the TLS WG AFAIK. In my experience when
> some WG wants to define a TLS extension there's a brief discussion between
> the chairs and ADs about whether it's orthogonal enough to do separately.
> It's not in the TLS charter, for instance, AFAICT.
> >>
> >> -Ekr
> >>
> >>> Again that doesn’t mean that in future it will not be possible for
> other groups to define extension but we need to have that discussion first.
> >>>
> >>> Mirja
> >>>
> >>>
> >>>
> >>>> I didn’t say that other groups cannot define extension. I did say
> that it’s the decision of the working group that maintains the protocol how
> to handle that and for Quic we didn’t have had that discussion yet.
> >>>>
> don't see why you would infer that all extensions happen within the QUIC
> WG..
> >>>>
> >>>> -Ekr
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Mirja
> >>>>
> >>>>
> >>>>> I think this is not sufficient, at least not for QUIC. More
> discussion is needed in the QUIC group on this but currently I think the
> assumption should be that all extensions will be done within the QUIC
> group. So just sending a WGLC there is not sufficient.
> >>>>>
> >>>>> More generally deciding on processes for other protocols/groups in
> this charter is not appropriate. I’m not sure what the defined process is
> for HTTP and TLS but that should be specified in their charter and not here.
> >>>>>
> >>>>> For QUIC, I would like to rather see that extension or modification
> are out of scope for this group. Of course that doesn’t mean that this
> group cannot talk about any extension but as soon as the group thinks an
> >>>>> Please also double-check what the right process is for TLS and HTTP.
> I assume for TLS it's the same but for HTTP it might be different…?
> >>>>>
> >>>>> Mirja
> >>>>>
> >>>>>
> >>>>>
> >>>>>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 12 Feb 2020 16:17:14 +0100

> On 12. Feb 2020, at 16:13, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind <[email-masked]> wrote:
> The whole point is that the QUIC protocol is not finished yet and the respective registry doesn’t exists yet.
> 
> And WebTransport will have a normative dependency on QUIC and therefore will not be finished prior to that registry existing.

But the charter will be finished before that and we need to decide now what to write in there. That’s what we are discussing.

> 
> 
> All I’m saying that we should not bake process in the the webtransport charter that might restrict a future discuss we want to have in the QUIC group.
> 
> What future discussion? As I said, the IANA considerations implicit decide this matter. Is someone arguing to change those to Standards Track?

As Magnus wrote several times in the resented re-chartering discussion:

"A reason for the two step rechartering is that I think we will need to have a
serious discussion of how to work on v2 and extensions more generally. I think
going into these details now is premature. But we will need to come back to this
later.”

Mirja

> >>>>>> happen in their existing respective working groups..
> >>>>>> primarily to those that I have something to add to..
> >>>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Feb 2020 07:21:15 -0800

Well, I don't really agree that this needs to be a live issue, but as you
insist:
Extensions to QUIC should be possible in WGs across the IETF, with proper
coordination with the QUIC WG. This isn't really a decision for the QUIC
WG, but rather for the IESG, In any case, this is precisely what is
contemplated by the current draft. If you think this needs to go in some
charter text, then it should go there now.

-Ekr

On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind <[email-masked]>
wrote:

> But the charter will be finished before that and we need to decide now
> what to write in there. That’s what we are discussing.
>
> >
> >
> > What future discussion? As I said, the IANA considerations implicit
> decide this matter. Is someone arguing to change those to Standards Track?
>
> > >>> Yes, it is specification required, however, if we decide to pushing
> an RFC then we need to decide where this work in the IETF can be don best.
> > >>
> > >>
> > >>>> Examples for groups that explicitly define process for extending
> the protocol in their charter are dhc and 6man. As you can see different
> > >>>> Most of the code points are assigned via Specification Required, so
> I don't see why you would infer that all extensions happen within the QUIC
> WG..
> > >>>>
> > >>>> -Ekr
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Mirja
> > >>>>
> > >>>>
> > >>>>> For QUIC, I would like to rather see that extension or
> modification are out of scope for this group. Of course that doesn’t mean
> that this group cannot talk about any extension but as soon as the group
> thinks an extension is needed, it needs to go to the QUIC group and cannot
> just adapt anything within WebTransport.
> > >>>>>
> > >>>>> Please also double-check what the right process is for TLS and
> HTTP. I assume for TLS it's the same but for HTTP it might be different…?
> > >>>>>
> > >>>>> Mirja
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 12 Feb 2020 16:28:57 +0100

Yes, that is a decision by the IESG so we should not baked it into the WebTransport charter at this point of time. What I’m requesting is to rather remove the following sentence from the proposed new charter text:

"The WebTransport working group may define extensions to these protocols, but any working group last call defining such extensions shall also be sent to the mailing list of the respective working group.”

And then the following sentence should probably also be change to remove the word “core” or even replace “changes to these core protocols” with “extension to the respective protocols”:

"In particular, any changes to these core protocols shall be discussed in their respective working groups.”

I think it is actually true for all three protocols (QUIC, HTTP, and TLS) that changes to the _core_ protocol must be done in the respectively working group. 

Mirja

> On 12. Feb 2020, at 16:21, Eric Rescorla <[email-masked]> wrote:
> 
> Well, I don't really agree that this needs to be a live issue, but as you insist:
> Extensions to QUIC should be possible in WGs across the IETF, with proper coordination with the QUIC WG. This isn't really a decision for the QUIC WG, but rather for the IESG, In any case, this is precisely what is contemplated by the current draft. If you think this needs to go in some charter text, then it should go there now.
> 
> -Ekr
> 
> 
> On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind <[email-masked]> wrote:
> 
> 
> > >>>>> I'm not sure I agree with your interpretation.. The fact that a WG is

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 12 Feb 2020 16:48:14 +0000

I’m not sure how likely QUIC extensions are for WebTransport, but would it be possible to defer the decision of exactly where extensions work is done, if required?

I.e., rather than:

The WebTransport working group may define extensions to these protocols,
but any working group last call defining such extensions will also be sent
to the mailing list of the relevant working group.

perhaps:

The WebTransport working group may consider extensions to these protocols, but if required, the relevant working groups shall be consulted to agree the most appropriate working group to progress the work, and all relevant working groups must be involved in WGLC requests.

Regards,
Rob

From: iesg <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: 12 February 2020 15:21
To: Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>
Cc: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; WebTransport <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; David Schinazi <[email-masked]<mailto:[email-masked]>>; Victor Vasiliev <[email-masked]<mailto:[email-masked]>>; Barry Leiba <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)

-Ekr

On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:

> On 12. Feb 2020, at 16:13, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
> On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:

Mirja

>
> -Ekr
>
>
>
> > On 12. Feb 2020, at 15:26, Barry Leiba <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > On Wed, Feb 12, 2020 at 9:15 AM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
> >>
> >>
> >>
> >> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
> >>>
> >>> Hi Ekr,
> >>>
> >>>> On 11. Feb 2020, at 22:34, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja Kühlewind (IETF)" <[email-masked]<mailto:[email-masked]>> wrote:
> >>>> Hi David,
> >>>>
> >>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi <[email-masked]<mailto:[email-masked]>>:
> >>>>>
> >>>>> 
> >>>>> Hi Mirja,
> >>>>>
> >>>>> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
> >>>>> Hi David,
> >>>>>
> >>>>> One more comment below.
> >>>>>
> >>>>>> On 6. Feb 2020, at 14:46, David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
> >>>>>>
> >>>>>> Hi Magnus,
> >>>>>>
> >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev <[email-masked]<mailto:[email-masked]>> wrote:
> >>>>>> On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker <noreply@ietf..org<mailto:noreply@ietf..org>> wrote:
> >>>>>> [email-masked]<mailto:[email-masked]>
> >>>> [email-masked]<mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Feb 2020 08:56:13 -0800

I don't think there is anything new to say here, other than that I am not
in favor of these changes to the charter, which I believe would be unwise.

-Ekr

On Wed, Feb 12, 2020 at 7:29 AM Mirja Kuehlewind <[email-masked]>
wrote:

> Yes, that is a decision by the IESG so we should not baked it into the
> WebTransport charter at this point of time. What I’m requesting is to
> rather remove the following sentence from the proposed new charter text:
>
> "The WebTransport working group may define extensions to these protocols,
> but any working group last call defining such extensions shall also be sent
> to the mailing list of the respective working group.”
>
> And then the following sentence should probably also be change to remove
> the word “core” or even replace “changes to these core protocols” with
> “extension to the respective protocols”:
>
> I think it is actually true for all three protocols (QUIC, HTTP, and TLS)
> that changes to the _core_ protocol must be done in the respectively
> working group.
>
> Mirja
>
>
>
> > Extensions to QUIC should be possible in WGs across the IETF, with
> proper coordination with the QUIC WG. This isn't really a decision for the
> QUIC WG, but rather for the IESG, In any case, this is precisely what is
> > > And WebTransport will have a normative dependency on QUIC and
> therefore will not be finished prior to that registry existing.
> >
> > > >>> Yes, it is specification required, however, if we decide to
> pushing an RFC then we need to decide where this work in the IETF can be
> don best.
> > > >>
> > > >>
> > > >>>> Most of the code points are assigned via Specification Required,
> so I don't see why you would infer that all extensions happen within the
> QUIC WG..
> > > >>>>
> > > >>>> -Ekr
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> Mirja
> > > >>>>
> > > >>>>
> > > >>>>> More generally deciding on processes for other protocols/groups
> in this charter is not appropriate. I’m not sure what the defined process
> is for HTTP and TLS but that should be specified in their charter and not
> here.
> > > >>>>>