Original text:
off between resource commitment and overhead when determining how large a limit is advertised. <del> A receiver MAY use an autotuning mechanism to tune the frequency and </del>  amount of advertised additional credit based on a round-trip time estimate and the rate at which the receiving application consumes <del> data, similar to common TCP implementations. </del>  If a sender runs out of flow control credit, it will be unable to send new data and is considered blocked.  It is generally considered

Reviewer comments:
This doesn't need normative text. This adds NAME recommendation about only sending flow control frames when there are other frames to send. Though I added another note about the peer being explicitly blocked, which I think is a useful transition to the next paragraph.
I don't think so. Flow control credits can go out with acknowledgments. The advice is there so that you don't have the MAX_DATA frame go out immediately, with a delayed ACK going out 20ms later. They can both go out together.
Bundling frames definitely makes sense, but I don’t think we need the “or when a peer is blocked” part.
Your assertion being that a blocked peer will already have to live with being blocked for a round trip, so the gain isn't worth documenting?
I’m saying that you shouldn’t let your peer become blocked under normal circumstances. I just noticed that in the corner case where the peer is blocked because the application is consuming data too slowly, it actually makes sense to not bundle the flow control update. So I guess the text is fine as is.
The text just says that sending more packets causes more packets to be sent. That is kind of obvious. Also, sending flow control with other frames isn't working if there isn't anything to ACK or anything to send once the application gets around to drain its buffer and inform transport about more credits.
Looks fine, one suggestion.
In light of the first paragraph which says that I can do whatever I want, what is the purpose of this MAY? It seems like you should either recommend that people do this or just remove the normative language.
I agree the MAY isn't doing anything here. The one thing I think should be encouraged is bundling flow control updates with other data instead of sending them in their own packets, since the frames themselves are very small.
It takes one RTT for the sender to learn that the receiver is blocked and to grant additional flow control credit, so this will lead to frequent stalls of the connection, if one receiver has nothing else to send.

Revised text:
off between resource commitment and overhead when determining how large a limit is advertised.  <ins> A receiver can use an autotuning mechanism to tune the frequency and </ins> amount of advertised additional credit based on a round-trip time estimate and the rate at which the receiving application consumes  <ins> data, similar to common TCP implementations.  As an optimization, sending frames related to flow control only when there are other frames to send or when a peer is blocked ensures that flow control doesn't cause extra packets to be sent. </ins> If a sender runs out of flow control credit, it will be unable to send new data and is considered blocked.  It is generally considered