clarify the precise condition

draft-ietf-quic-recovery.md

@@ -529,13 +529,13 @@ with two exceptions:
   and prevents a server from sending a 1-RTT packet on a PTO expiration before
   it has the keys to process an acknowledgement.
 
-* When the sender knows that the peer has all the information to generate the
-  next TLS handshake message the peer would be sending, the sender MAY postpone
-  the activation of the PTO timer until it receives such handshake message.
-  This is because lack of an acknowledgement might be due to the peer not
-  immediately being able to process the packet, in which case it is expected to
-  buffer and process that packet once it becomes possible to do so (Section
-  4.1.4 of {{QUIC-TLS}}).
+* Once the sender has received acknowledgements for all the handshake data
+  necessary for the peer to generate a TLS handshake message in response, the
+  sender MAY postpone the activation of the PTO timer until it receives such
+  handshake message.  This is because lack of an acknowledgement might be due to
+  the peer not immediately being able to process the packet, in which case it is
+  expected to buffer and process that packet once it becomes possible to do so
+  (Section 4.1.4 of {{QUIC-TLS}}).
 
 When a PTO timer expires, the PTO backoff MUST be increased, resulting in the
 PTO period being set to twice its current value. The PTO backoff factor is reset