Change:
a packet.  Restarting this timer when sending a packet ensures that connections are not closed after new activity is initiated. <ins> 10.2.1. An endpoint that sends packets close to the effective timeout risks having them be discarded at the peer, since the peer might enter its draining state before these packets arrive. An endpoint can send a PING or another ack-eliciting frame to test the connection for liveness if the peer could time out soon, such as within a PTO; see Section 6.2 of QUIC-RECOVERY.  This is especially useful if any available application data cannot be safely retried. Note that the application determines what data is safe to retry. 10.2.2. </ins> An endpoint might need to send ack-eliciting packets to avoid an idle timeout if it is expecting response data, but does not have or is unable to send application data. <del> An endpoint that sends packets close to the effective timeout risks having them be discarded at the peer, since the peer might enter its draining state before these packets arrive.  An endpoint can send a PING or another ack-eliciting frame to test the connection for liveness if the peer could time out soon, such as within a PTO; see Section 6.2 of QUIC-RECOVERY.  This is especially useful if any available application data cannot be safely retried.  Note that the application determines what data is safe to retry. </del> <ins> An implementation of QUIC might provide applications with an option to defer an idle timeout.  This facility could be used when the application wishes to avoid losing state that has been associated with an open connection, but does not expect to exchange application data for some time.  With this option, an endpoint could send a PING frame periodically to defer an idle timeout; see frame-ping. Application protocols that use QUIC SHOULD provide guidance on when deferring an idle timeout is appropriate.  Unnecessary sending of PING frames could have a detrimental effect on performance. A connection will time out if no packets are sent or received for a period longer than the time negotiated using the max_idle_timeout transport parameter; see termination.  However, state in middleboxes might time out earlier than that.  Though REQ-5 in RFC4787 recommends a 2 minute timeout interval, experience shows that sending packets every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. </ins> 10.3.

Discussion:
This moves it up under the idle timeout section. As discussed on the issue, the HTTP draft is basically good.
The transport Draft states: This guidance was added to the HTTP Draft in , but was subsequently removed.
I guess that something to discuss in the applicability draft as well
Looks like made this text more generic, leaving the specifics of how to keep a connection alive (e.g. with PING frames) to the transport implementation. The text in question is now in Section 5.1: It's possible the transport draft needs a similar generalization, to recommend implementations expose a way for the application layer to control whether an connection is idle.
Actually there is a section on "Session resumption versus Keep-alive" in the applicability draft already. Do we need to say more? Is that needed in the transport draft as well?
On the whole, this is good. Might be worth having something a little stronger than "might provide"; that would be normative, but the old text already hinted fairly strongly that this was a capability that needed to be exposed to applications.