Original text:
HTTP/2 stream flow control, which limits the data on a single HTTP/2 stream.  For a WebTransport session, this includes all <del> capsules, including those that are exempt from session-level flow control. </del>  WebTransport session-level flow control, which limits the total amount of stream data that can be sent or received on streams <del> within the WebTransport session. </del>  WebTransport stream flow control, which limits data on individual streams within a session. 3.4.2.  WebTransport over HTTP/2 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in Section 3.2 of HTTP-DATAGRAM.  These capsules, referred

Reviewer comments:
Expand description of flow control and add additional notes NAME already wrote up a very nice overview of the layers we have, so added a little bit extra there and filled in the last little bit on limiting streams within a session to round everything out.
Document how MAXDATA interacts with the enclosing HTTP/2 flow control scheme Originally posted by NAME in URL
I tend to think we might want to have a section entirely on flow control since we've now got several layers: HTTP/2 connection level HTTP/2 stream for the CONNECT stream WTMAXDATA for the WT session Noting that this is different than the HTTP/2 layer's CONNECT stream, since we want to be able to indicate the sum of stream data separately from other control frames WTMAXSTREAMDATA for each WT stream And stream-count flow control HTTP/2 stream limits don't really apply once you've got the WT session up WTMAX_STREAMS limits stream counts within a WT session Just indicating the intended usage of each of these knobs would be helpful.
(From : Since QUIC's flow control credits work differently from H2, it may be worth explicitly stating how this works here.)
Chair notes from IETF 112 meeting: no one objected to proposal of resolving this by documenting how flow control works and pitfalls
Why do we need WTMAXDATA in first place? I thought that since we have flow control from the HTTP/2 side, we don't need it.
We want to be able to say "don't send me any more data on this stream" while still allowing control frames on that stream

Revised text:
HTTP/2 stream flow control, which limits the data on a single HTTP/2 stream.  For a WebTransport session, this includes all  <ins> capsules, including those that are exempt from WebTransport session-level flow control. </ins> WebTransport session-level flow control, which limits the total amount of stream data that can be sent or received on streams  <ins> within the WebTransport session.  Note that this does not limit other types of capsules within a WebTransport session, such as control messages or datagrams. </ins> WebTransport stream flow control, which limits data on individual streams within a session. 3.4.2. <ins> This document defines a capsule (WT_MAX_STREAMS) that allows each endpoint to limit the number of streams its peer is permitted to open as part of a WebTransport session.  There is a separate limit for bidirectional streams and for unidirectional streams.  Note that, unlike WebTransport over HTTP/3 WEBTRANSPORT-H3, because the entire WebTransport session is contained within HTTP/2 DATA frames on a single HTTP/2 stream, this limit is the only mechanism for an endpoint to limit the number of WebTransport streams that its peer can open on a session. 3.4.3. </ins> WebTransport over HTTP/2 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in Section 3.2 of HTTP-DATAGRAM.  These capsules, referred