Yes, the recovery draft includes all the necessary timers (aside from the idle timeout, which I think is adequately covered). However, if you are talking about flow control specifically, then that does not necessarily need timers. Other commenters have bemoaned the lack of guidance regarding flow control and it has improved, but the prevailing view of the working group is that it is only a problem if you try to optimize. So we have what is written, which says that if you want tight flow control limits (in the order of BDP), then you risk performance problems if you don't provide timely updates.

The willingness to allow more flow control credit is (almost?) always triggered by an event, such as the application reading from the stream; or a stream being reset and the stack deciding to discard the buffered data. As such, flow control can be implemented purely on an event-based basis. Now, this isn't optimal for performance -- you might not want to generate flow control updates every time one of these events happens, but rather coalesce them -- but that's an optimization that implementations can decide whether and how to pursue.

Many stacks also increase their buffer allocations in response to increases in perceived BDP.

As this is an issue the working group has consensus on, I don't think we should change anything. However, it is more than simply editorial, so I can't close the issue. I propose that we do though.

Labelling this as design, but am noting your suggestion to close with no action.

I support closing with no action.

Closing this now that the IESG have approved the document(s).