Script updating gh-pages from 1c9fcc3. [ci skip]

0rtt-cant-respond-to-1rtt/draft-ietf-quic-transport.html

@@ -2441,7 +2441,7 @@ <h3 id="rfc.section.17.2.3">
 <p id="rfc.section.17.2.3.p.5">A client MUST NOT reset the packet number it uses for 0-RTT packets.  The keys used to protect 0-RTT packets will not change as a result of responding to a Retry packet unless the client also regenerates the cryptographic handshake message.  Sending packets with the same packet number in that case is likely to compromise the packet protection for all 0-RTT packets because the same key and nonce could be used to protect different content.</p>
 <p id="rfc.section.17.2.3.p.6">Receiving a Retry packet, especially a Retry that changes the connection ID used for subsequent packets, indicates a strong possibility that 0-RTT packets could be lost.  A client only receives acknowledgments for its 0-RTT packets once the handshake is complete.  Consequently, a server might expect 0-RTT packets to start with a packet number of 0.  Therefore, in determining the length of the packet number encoding for 0-RTT packets, a client MUST assume that all packets up to the current packet number are in flight, starting from a packet number of 0.  Thus, 0-RTT packets could need to use a longer packet number encoding.</p>
 <p id="rfc.section.17.2.3.p.7">A client SHOULD instead generate a fresh cryptographic handshake message and start packet numbers from 0.  This ensures that new 0-RTT packets will not use the same keys, avoiding any risk of key and nonce reuse; this also prevents 0-RTT packets from previous handshake attempts from being accepted as part of the connection.</p>
-<p id="rfc.section.17.2.3.p.8">A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot contain any response to frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a 0-RTT packet, because that can only acknowledge a 1-RTT packet.  An acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.</p>
+<p id="rfc.section.17.2.3.p.8">A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server.  This means that 0-RTT packets cannot contain any response to frames from 1-RTT packets.  For instance, a client cannot send an ACK frame in a 0-RTT packet, because that can only acknowledge a 1-RTT packet.  An acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.  A server MAY treat a violation of remembered limits as a connection error of an appropriate type (for instance, a FLOW_CONTROL_ERROR for exceeding stream data limits).</p>
 <h3 id="rfc.section.17.2.4">
 <a href="#rfc.section.17.2.4">17.2.4.</a> <a href="#packet-handshake" id="packet-handshake">Handshake Packet</a>
 </h3>

0rtt-cant-respond-to-1rtt/draft-ietf-quic-transport.txt

@@ -4784,7 +4784,10 @@ Internet-Draft           QUIC Transport Protocol           February 2019
    contain any response to frames from 1-RTT packets.  For instance, a
    client cannot send an ACK frame in a 0-RTT packet, because that can
    only acknowledge a 1-RTT packet.  An acknowledgment for a 1-RTT
-   packet MUST be carried in a 1-RTT packet.
+   packet MUST be carried in a 1-RTT packet.  A server MAY treat a
+   violation of remembered limits as a connection error of an
+   appropriate type (for instance, a FLOW_CONTROL_ERROR for exceeding
+   stream data limits).
 
 17.2.4.  Handshake Packet
 
@@ -4810,9 +4813,6 @@ Internet-Draft           QUIC Transport Protocol           February 2019
 
 
 
-
-
-
 Iyengar & Thomson        Expires August 18, 2019               [Page 86]
 
 Internet-Draft           QUIC Transport Protocol           February 2019