Original text:
control window is set to the default initial window size until a WINDOW_UPDATE frame is received. <del> A </del>  <del> frame can alter the initial flow control window size for all streams in the "open" or "half closed (remote)" state.  When the value of </del>  changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and

Reviewer comments:
Thanks for the PR NAME Should we move the issue discussion (URL) to this PR?
LGTM
NAME if you have comments, please let me know ASAP.
Merged by RFC editor.
has the following text: Draft 17 added the changed to . Can someone clarify why would streams in other states be excluded?
Those are the only states in which data (or DATA) can be sent.
Does your stream have to be eligible for data to be sent to have its windows manipulated? For example are IDLE streams intentionally excluded? Would this mean that the initial settings frame wouldn't apply to any streams? I think it may make sense to be able to alter window sizes of streams in other states because of dependencies/priorities and how the windows are distributed amongst the tree.
While it is true than an idle stream is affected, the text there is to highlight the fact that streams with active flow control windows (i.e., ones that might be in use) might be affected.
Is it possible to clarify this? I think there are a few options: If we are going to explicitly call out states: we should call out all states where it could possibly impact streams. If we are not going to explicitly call out states: Use a description which implies stream state which is defined elsewhere in the spec. Something like: Note this is just an example... The current text in the specification is in conflict with this clarification you have provided in this issue. It seems like the following sentence in the spec may be sufficient by itself?
NAME - Ping.
The inclusion of stream state in your clerical response leads me to another question related to the priority tree, stream state, and flow control windows. indicates that . The flow control window is a resource which can be divided amongst nodes in the priority tree. However the frame can be sent/received in all states, but the frame is more restrictive in its allowed states. This discrepancy makes controlling the resource (the window) difficult (i.e. providing a mechanism to avoid deadlock). Is there any way to clarify or allow the resource (the window) to be controlled adequately along with priority?
As far as it goes, yes, a server might allocate flow control window based on priority. But that only applies to the logic that an implementation uses to decide how to allocate credit to flow control windows, which is intentionally (and expressly) unspecified. I don't think that it needs a special call-out.
I agree that it doesn't need to be specifically called out that the window can be treated as a resource, and that this is an implantation detail. However calling out the stream states when referencing frames that impact the flow control window may be overly restrictive. For example the are not the only states in which a stream may be in the priority tree. Here are what I believe to be the relevant portions of the specification which relate to flow control window and stream state. seems to be very careful about stream state and doesn't necessarily limit to just is much more restrictive and declares that is not allowed in , or . For there is special mention that these frames must be ignored, or may be an error (if it arrives ). If the clarifications in this issue are applied then it seems like the impact on the flow control windows is further limited to .
BTW, I consider the state associated with having a stream in the priority tree to be necessarily separate from the state that is maintained for an "active stream" (i.e., one with active send or receive state). Lumping them all together exposes you to some potential attacks.
Can you be more specific (particularly about the )? I guess what I'm after is two fold: Consistency amongst the sections that discuss window update and stream state. Not necessarily preventing window_update being controlled when a stream is in the priority tree, or rational as to why it makes sense to do so.
The amount of state you commit to a stream that is active is potentially large (flow control windows, primarily). That is strictly bounded though by your value of the MAXCONCURRENTSTREAMS setting. If that state has to live on the same lifetime as stream priority, then it is not covered by the setting and you are potentially in a position to commit a much larger amount of state. You can (obviously) manage this by careful management of the transition to and from the active states, but I believe that it is better to instead have separate tracking of priority.
One way to implement this cleanly is to have a (small) priority state for streams that is created and managed by a garbage-collector. Active stream state can be a separate object that maintains a reference to the priority state (that might be nullable, or you could require that only closed or idle streams be exposed to the GC).
I think we are straying into implementation details a bit, and we are in agreement that the state could be managed, but in the scope of this issue....I re-read your PR and I am fine with it :)
NAME Does "old value" here means the old initial window size?
Yes

Revised text:
control window is set to the default initial window size until a WINDOW_UPDATE frame is received.  <ins> In addition to changing the flow control window for streams that are not yet active, a </ins>  <ins> frame can alter the initial flow control window size for streams with active flow control windows (that is, streams in the "open" or "half closed (remote)" state).  When the value of </ins> changes, a receiver MUST adjust the size of all stream flow control windows that it maintains by the difference between the new value and