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

[Magnus Westerlund <[e-mail]>]

Hi,

Please see inline. 

On Fri, 2020-01-31 at 19:09 -0800, Bernard Aboba wrote:
> Comments below.
> 
> > From: Magnus Westerlund via Datatracker <[e-mail]>
> > Date: January 31, 2020 at 08:39:10 PST
> > To: The IESG <[e-mail]>
> > Cc: [e-mail], [e-mail], [e-mail]
> > Subject: Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with
> > BLOCK and COMMENT)
> > Reply-To: Magnus Westerlund <[e-mail]>
> > 
> > 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.
> 
> [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 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  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------