Original text:
capablities.  Usually application error codes are defined to be applicabile to all three frames. <del> Alternatively, a QUIC connection will be silently closed by each endpoint separately after an idle timeout.  The idle timeout is announce for each endpoint during connection established and should be accessible by the application.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alives messages.  See {#resumption-v-keepalive} for further guidance. </del>  9.

Reviewer comments:
One concern I have with short idle timeout is impact on VM live migration. The current guidance with TCP default timeouts allows LM to have a blackout period of under 9 seconds. Do we need any guidance here to not use very low default timeouts?
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by
This is related to quicwg/base-drafts and depends on the outcome there.
PR now indicated that the idle timeout could be exposed to the application. However, we should probably say a bit more what to do with it. I guess the minimum would be to say that the keep-alive frequency needs to be clearly smaller than the idle timeout, e.g. half the timeout. Is there anything more we could say? NAME NAME any thoughts? Or text you can provide?
PR provides some more guidance now but it still doesn't discuss suitable value or ranges. What values are used in current implementations? Should we say more?
This is reasonable advice. A little redundant with the advice in the spec, but not overly so, I think.

Revised text:
capablities.  Usually application error codes are defined to be applicabile to all three frames.  <ins> Alternatively, a QUIC connection can be silently closed by each endpoint separately after an idle timeout.  If enabled as indicated by a transport parameter in the handshake, the idle timeout is announced for each endpoint during connection establishment and the effective value for this connection is the minimum of the two advertised values.  An application therefore should be able to configure its own maximum value as well as have access to the computed minimum value for this connection.  An application may adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory more quickly.  If an application desires to keep the connection open for longer than the announced timeout, it can send keep-alives messages, or a QUIC implementation may provide an option to defer the time-out to avoid unnecessary load, as specified in Section 10.2.2 of QUIC.  See resumption-v-keepalive for further guidance on keep- alives. </ins> 9.