Script updating gh-pages from 5a6461e. [ci skip]

ianswett-rtt-path-challenge/draft-ietf-quic-recovery.html

@@ -824,7 +824,7 @@ <h2 id="rfc.section.6.2">
 <p id="rfc.section.6.2.p.1">Data in CRYPTO frames is critical to QUIC transport and crypto negotiation, so a more aggressive timeout is used to retransmit it.</p>
 <p id="rfc.section.6.2.p.2">The initial crypto retransmission timeout SHOULD be set to twice the initial RTT.</p>
 <p id="rfc.section.6.2.p.3">At the beginning, there are no prior RTT samples within a connection.  Resumed connections over the same network SHOULD use the previous connection&#8217;s final smoothed RTT value as the resumed connection&#8217;s initial RTT.  If no previous RTT is available, or if the network changes, the initial RTT SHOULD be set to 500ms, resulting in a 1 second initial handshake timeout as recommended in <a href="#RFC6298" class="xref">[RFC6298]</a>.</p>
-<p id="rfc.section.6.2.p.4">A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to seed initial_rtt for a new path, but the delay MUST NOT be considered an RTT sample.</p>
+<p id="rfc.section.6.2.p.4">A connection MAY use the delay between sending a PATH_CHALLENGE and receiving a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT be considered an RTT sample.</p>
 <p id="rfc.section.6.2.p.5">When a crypto packet is sent, the sender MUST set a timer for twice the smoothed RTT.  This timer MUST be updated when a new crypto packet is sent and when an acknowledgement is received which computes a new RTT sample. Upon timeout, the sender MUST retransmit all unacknowledged CRYPTO data if possible.  The sender MUST NOT declare in-flight crypto packets as lost when the crypto timer expires.</p>
 <p id="rfc.section.6.2.p.6">On each consecutive expiration of the crypto timer without receiving an acknowledgement for a new packet, the sender MUST double the crypto retransmission timeout and set a timer for this period.</p>
 <p id="rfc.section.6.2.p.7">Until the server has validated the client&#8217;s address on the path, the amount of data it can send is limited, as specified in Section 8.1 of <a href="#QUIC-TRANSPORT" class="xref">[QUIC-TRANSPORT]</a>.  If not all unacknowledged CRYPTO data can be sent, then all unacknowledged CRYPTO data sent in Initial packets should be retransmitted.  If no data can be sent, then no alarm should be armed until data has been received from the client.</p>

ianswett-rtt-path-challenge/draft-ietf-quic-recovery.txt

@@ -700,7 +700,7 @@ Internet-Draft             QUIC Loss Detection                  May 2019
 
    A connection MAY use the delay between sending a PATH_CHALLENGE and
    receiving a PATH_RESPONSE to seed initial_rtt for a new path, but the
-   delay MUST NOT be considered an RTT sample.
+   delay SHOULD NOT be considered an RTT sample.
 
    When a crypto packet is sent, the sender MUST set a timer for twice
    the smoothed RTT.  This timer MUST be updated when a new crypto