Change:
3.3. <del> [EDITOR'S NOTE: see https://github.com/quicwg/ops-drafts/issues/6] </del> <ins> Because QUIC is encapsulated in UDP, applications using QUIC must deal with short idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry will be expired after just thirty seconds of inactivity. A QUIC application has three strategies to deal with this issue: Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods. Ensure there are no long idle periods. Resume the session after a long idle period, using 0-RTT resumption when appropriate. The first strategy is the easiest, but it only applies to certain applications. Either the server or the client in a QUIC application can send PING frames as keep-alives, to prevent the connection and any on-path state from timing out.  Recommendations for the use of keep-alives are application specific, mainly depending on the latency requirements and message frequency of the application.  In this case, the application mapping must specify whether the client or server is responsible for keeping the application alive.  Note that sending PING frames more frequently than every 30 seconds over long idle periods may result in a too much unproductive traffic and power usage for some situations. Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a client that wants to send data to a server over a connection idle longer than the server's idle timeout (available from the idle_timeout transport parameter) can simply reconnect.  When possible, this reconnection can use 0-RTT session resumption, reducing the latency involved with restarting the connection.  This of course only applies in cases in which 0-RTT data is safe, when the client is the restarting peer, and when the data to be sent is idempotent. The tradeoffs between resumption and keepalive need to be evaluated on a per-application basis.  However, in general applications should use keepalives only in circumstances where continued communication is highly likely; QUIC-HTTP, for instance, recommends using PING frames for keepalive only when a request is outstanding. </ins> 4.

Discussion:
An alternate approach to , following from NAME comment thereon.
I think the new text is now missing two points: 1) It might make sense to send keep-alives if the application know that is there is new data coming, e.g. an outstating reply or a following request. I think this is what is recommended for http. 2) as meantion in the transport draft we should probably say again that it must be clearly specified which party is performing the active ping-ing Also the text basically "just" explains the situation but doesn't really make any recommendation. Do we maybe what to say more than that?
Yay, unicorns mean that I can't see NAME comments here, though they appeared in email. In response to those, maybe it is OK to point to HTTP/QUIC's recommendations about keep-alives. There, it recommends limiting use of PING for keep-alive to while a request is outstanding.
The transport draft says: "The PING frame can be used to keep a connection alive when an application or application protocol wishes to prevent the connection from timing out. An application protocol SHOULD provide guidance about the conditions under which generating a PING is recommended. This guidance SHOULD indicate whether it is the client or the server that is expected to send the PING. Having both endpoints send PING frames without coordination can produce an excessive number of packets and poor performance." Probably we should state this in the applicability statement as well...
The transport draft also provides guidance on on the ping interval: "A connection will time out if no packets are sent or received for a period longer than the time specified in the 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."
That is not intended as guidance, but a caution. This is something that firmly fits in the application space. For instance, in HTTP, sending PING frames to keep the connection alive might be appropriate when a request is outstanding, but it shouldn't be used otherwise.
NAME I added a bit of text in PR . Can you have a look at it?
Resolved by PR