Script updating gh-pages from 7bb735a. [ci skip]

draft-ietf-quic-transport.html

@@ -1613,19 +1613,11 @@ <h2 id="rfc.section.8.4">
 <a href="#rfc.section.8.4">8.4.</a> <a href="#path-validation-responses" id="path-validation-responses">Path Validation Responses</a>
 </h2>
 <p id="rfc.section.8.4.p.1">On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.</p>
-<p id="rfc.section.8.4.p.2">To ensure that packets can be both sent to and received from the peer, the PATH_RESPONSE MUST be sent on the same path as the triggering PATH_CHALLENGE.  That is, from the same local address on which the PATH_CHALLENGE was received, to the same remote address from which the PATH_CHALLENGE was received.</p>
 <h2 id="rfc.section.8.5">
 <a href="#rfc.section.8.5">8.5.</a> <a href="#successful-path-validation" id="successful-path-validation">Successful Path Validation</a>
 </h2>
-<p id="rfc.section.8.5.p.1">A new address is considered valid when a PATH_RESPONSE frame is received that meets the following criteria:</p>
-<p></p>
-
-<ul>
-<li>It contains the data that was sent in a previous PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer.</li>
-<li>It was sent from the same remote address to which the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received from a different remote address than the one to which the PATH_CHALLENGE was sent, path validation is considered to have failed, even if the data matches that sent in the PATH_CHALLENGE.</li>
-<li>It was received on the same local address from which the corresponding PATH_CHALLENGE was sent.</li>
-</ul>
-<p id="rfc.section.8.5.p.3">Note that receipt on a different local address does not result in path validation failure, as it might be a result of a forwarded packet (see <a href="#off-path-forward" class="xref">Section 9.3.3</a>) or misrouting. It is possible that a valid PATH_RESPONSE might be received in the future.</p>
+<p id="rfc.section.8.5.p.1">A new address is considered valid when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE. Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer.</p>
+<p id="rfc.section.8.5.p.2">Note that receipt on a different local address does not result in path validation failure, as it might be a result of a forwarded packet (see <a href="#off-path-forward" class="xref">Section 9.3.3</a>) or misrouting. It is possible that a valid PATH_RESPONSE might be received in the future.</p>
 <h2 id="rfc.section.8.6">
 <a href="#rfc.section.8.6">8.6.</a> <a href="#failed-path-validation" id="failed-path-validation">Failed Path Validation</a>
 </h2>
@@ -1640,10 +1632,10 @@ <h2 id="rfc.section.8.6">
 <h1 id="rfc.section.9">
 <a href="#rfc.section.9">9.</a> <a href="#migration" id="migration">Connection Migration</a>
 </h1>
-<p id="rfc.section.9.p.1">The use of a connection ID allows connections to survive changes to endpoint addresses (that is, IP address and/or port), such as those caused by an endpoint migrating to a new network.  This section describes the process by which an endpoint migrates to a new address.</p>
+<p id="rfc.section.9.p.1">The use of a connection ID allows connections to survive changes to endpoint addresses (IP address and port), such as those caused by an endpoint migrating to a new network.  This section describes the process by which an endpoint migrates to a new address.</p>
 <p id="rfc.section.9.p.2">An endpoint MUST NOT initiate connection migration before the handshake is finished and the endpoint has 1-RTT keys.  The design of QUIC relies on endpoints retaining a stable address for the duration of the handshake.</p>
 <p id="rfc.section.9.p.3">An endpoint also MUST NOT initiate connection migration if the peer sent the <samp>disable_migration</samp> transport parameter during the handshake.  An endpoint which has sent this transport parameter, but detects that a peer has nonetheless migrated to a different network MAY treat this as a connection error of type INVALID_MIGRATION.  Similarly, an endpoint MUST NOT initiate migration if its peer supplies a zero-length connection ID as packets without a Destination Connection ID cannot be attributed to a connection based on address tuple.</p>
-<p id="rfc.section.9.p.4">Not all changes of peer address are intentional migrations. The peer could experience NAT rebinding: a change of address due to a middlebox, usually a NAT, allocating a new outgoing port or even a new outgoing IP address for a flow.  NAT rebinding is not connection migration as defined in this section, though an endpoint SHOULD perform path validation (<a href="#migrate-validate" class="xref">Section 8.2</a>) if it detects a change in the IP address of its peer.</p>
+<p id="rfc.section.9.p.4">Not all changes of peer address are intentional migrations. The peer could experience NAT rebinding: a change of address due to a middlebox, usually a NAT, allocating a new outgoing port or even a new outgoing IP address for a flow.  An endpoint MUST perform path validation (<a href="#migrate-validate" class="xref">Section 8.2</a>) if it detects any change to a peer&#8217;s address, unless it has previously validated that address.</p>
 <p id="rfc.section.9.p.5">When an endpoint has no validated path on which to send packets, it MAY discard connection state.  An endpoint capable of connection migration MAY wait for a new path to become available before discarding connection state.</p>
 <p id="rfc.section.9.p.6">This document limits migration of connections to new client addresses, except as described in <a href="#preferred-address" class="xref">Section 9.6</a>. Clients are responsible for initiating all migrations.  Servers do not send non-probing packets (see <a href="#probing" class="xref">Section 9.1</a>) toward a client address until they see a non-probing packet from that address.  If a client receives packets from an unknown server address, the client MUST discard these packets.</p>
 <h2 id="rfc.section.9.1">