Script updating gh-pages from 2793b5c. [ci skip]

quicwg · Feb 9, 2020 · 8c6634b · 8c6634b
1 parent 7f9996c
commit 8c6634b
Show file tree

Hide file tree

Showing 3 changed files with 1,795 additions and 1,795 deletions.
diff --git a/ianswett-why-send-handshake/draft-ietf-quic-transport.html b/ianswett-why-send-handshake/draft-ietf-quic-transport.html
@@ -3295,8 +3295,8 @@ <h3 id="name-address-validation-during-c">
 payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by the amplification restriction.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
-<p id="section-8.1-4">Packet loss, in particular loss of a Handshake packet from the server, can cause
-a situation in which the server cannot send due to the anti-amplification limit
+<p id="section-8.1-4">Loss of an Initial or Handshake packet from the server can cause a situation in
+which the server cannot send due to the anti-amplification limit
 and the client has no data to send because client Initial packets have been
 acknowledged and it does not yet have Handshake data to send. In order to avoid
 this causing a handshake deadlock, clients MUST send a packet upon a probe

diff --git a/ianswett-why-send-handshake/draft-ietf-quic-transport.txt b/ianswett-why-send-handshake/draft-ietf-quic-transport.txt
@@ -2263,13 +2263,13 @@ Internet-Draft           QUIC Transport Protocol           February 2020
    the server is not overly constrained by the amplification
    restriction.
 
-   Packet loss, in particular loss of a Handshake packet from the
-   server, can cause a situation in which the server cannot send due to
-   the anti-amplification limit and the client has no data to send
-   because client Initial packets have been acknowledged and it does not
-   yet have Handshake data to send.  In order to avoid this causing a
-   handshake deadlock, clients MUST send a packet upon a probe timeout,
-   as described in [QUIC-RECOVERY].  If the client has no data to
+   Loss of an Initial or Handshake packet from the server can cause a
+   situation in which the server cannot send due to the anti-
+   amplification limit and the client has no data to send because client
+   Initial packets have been acknowledged and it does not yet have
+   Handshake data to send.  In order to avoid this causing a handshake
+   deadlock, clients MUST send a packet upon a probe timeout, as
+   described in [QUIC-RECOVERY].  If the client has no data to
    retransmit, it MUST send an Initial packet in a UDP datagram of at
    least 1200 bytes if it does not have Handshake keys, and otherwise
    send a Handshake packet.