WebTransport
charter-ietf-webtrans-01

[Ballot comment]
I agree with Ben that it would seem appropriate to mention HTTP somewhere in the charter.

I'm also a bit worried that this work is so closely coupled to the work on the WebTransport API of another SoD that is further still in an unclear state. But I also don't have a good solution to that. Probably correct to start with requirement in this case...

I would like to see the relationship of this new group to taps clarified in the charter!

[Ballot comment]
It's left pretty implicit that this work expects to tie into HTTP and use QUIC, but perhaps we don't need to constrain ourselves in that manner.

[Ballot comment]
This looks like an interesting work to be done. Just as non-blocking comments:

1) the milestones are really aggressive (and perhaps unrealistic)

2) when talking about "owners of the WebTransport API" this would be worth adding a reference to those owners.

Good luck and fair winds to this potential new WG

-éric

[Ballot comment]
Thanks, this new charter do address the blocking points I have.

The coordination with the API development still is unclear on this level. I do understand the challenge to be clear on it. So just leaving this as a comment.

[Ballot comment]
I will follow the discussion around the BLOCK points of my fellow AD but I wonder why this is in ART and not in TSV?

-éric

[Ballot comment]
In support of Alissa's and Magnus' blocks I would also like to see this (initially) more narrowly scoped. Especially talking about "protocols or protocol extensions" without constraining this statement to a set of transport protocols that need to be used, as well as not constraining the list "range of simple communication methods" to a limited (initial) list basically allows this charter to define more or less any kind of protocol (over the whole stack).

[Ballot block]
Based on the responses to Magnus' comment I think there are two issues to sort out before proceeding further.

1) Whether the API is creating requirements for the protocol, or the protocol is creating requirements for the API. The charter is written as if the situation is the former, but the list mail points towards the latter. The charter should be clear about this before it goes out for external review.

2) It sounds like there is still some chance that the change control for the API shifts from the W3C to the WHATWG. Would this group re-charter (or close) if that happens, or would it be better to make the charter more generically tied to the API but not to its change controller?

Please keep the IESG on cc on all replies. Thanks.

[Ballot 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. 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. 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 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 HTTP/3 and QUIC to the relevant WG.

[Ballot 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. 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.

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.