Original text:
1. <del> This document specifies an extension to QUIC v1 QUIC-TRANSPORT to enable the simultaneous usage of multiple paths for a single </del>  connection. This proposal is based on several basic design points: <del> Re-use as much as possible mechanisms of QUIC-v1.  In particular this proposal uses path validation as specified for QUIC v1 and aims to re-use as much as possible of QUIC's connection migration. </del>  <del> Use the same packet header formats as QUIC v1 to avoid the risk of packets being dropped by middleboxes (which may only support QUIC v1) </del>  Congestion Control, RTT measurements and PMTU discovery should be per-path (following QUIC-TRANSPORT) If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new ACK frame format is used as specified in ack-mp-frame.  Compared to <del> the QUIC v1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used </del>  to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID. Therefore, the packet number space for 1-RTT packets can be 7.2.1. <del> Packet protection for QUIC v1 is specified is Section 5 of QUIC-TLS. The general principles of packet protection are not changed for QUIC Multipath.  No changes are needed for setting packet protection keys, initial secrets, header protection, use of 0-RTT keys, receiving out- of-order protected packets, receiving protected packets, or retry packet integrity.  However, the use of multiple number spaces for 1-RTT packets requires changes in AEAD usage. </del>  Section 5.3 of QUIC-TLS specifies AEAD usage, and in particular the use of a nonce, N, formed by combining the packet protection IV with 7.2.2. <del> The Key Phase bit update process for QUIC v1 is specified in </del>  Section 6 of QUIC-TLS.  The general principles of key update are not <del> changed in this specification.  Following QUIC v1, the Key Phase bit is used to indicate which packet protection keys are used to protect the packet.  The Key Phase bit is toggled to signal each subsequent key update.  Because of network delays, packets protected with the older key might arrive later than the packets protected with the new key.  Therefore, the endpoint needs to retain old packet keys to allow these delayed packets to be processed and it must distinguish between the new key and the old key.  In QUIC V1, this is done using packet numbers so that the rule is made simple: Use the older key if packet number is lower than any packet number frame the current key phase. </del>  When using multiple packet number spaces on different paths, some care is needed when initiating the Key Update process, as different

Reviewer comments:
Be consistent with RFC9000
In order to be consistent with RFC9000, use "QUIC version 1" instead of "QUIC v1" through the document.

Revised text:
1.  <ins> This document specifies an extension to QUIC version 1 QUIC-TRANSPORT to enable the simultaneous usage of multiple paths for a single </ins> connection. This proposal is based on several basic design points:  <ins> Re-use as much as possible mechanisms of QUIC version 1.  In particular this proposal uses path validation as specified for QUIC version 1 and aims to re-use as much as possible of QUIC's connection migration. </ins>  <ins> Use the same packet header formats as QUIC version 1 to avoid the risk of packets being dropped by middleboxes (which may only support QUIC version 1) </ins> Congestion Control, RTT measurements and PMTU discovery should be per-path (following QUIC-TRANSPORT) If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new ACK frame format is used as specified in ack-mp-frame.  Compared to  <ins> the QUIC version 1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used </ins> to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID. Therefore, the packet number space for 1-RTT packets can be 7.2.1.  <ins> Packet protection for QUIC version 1 is specified is Section 5 of QUIC-TLS.  The general principles of packet protection are not changed for QUIC Multipath.  No changes are needed for setting packet protection keys, initial secrets, header protection, use of 0-RTT keys, receiving out-of-order protected packets, receiving protected packets, or retry packet integrity.  However, the use of multiple number spaces for 1-RTT packets requires changes in AEAD usage. </ins> Section 5.3 of QUIC-TLS specifies AEAD usage, and in particular the use of a nonce, N, formed by combining the packet protection IV with 7.2.2.  <ins> The Key Phase bit update process for QUIC version 1 is specified in </ins> Section 6 of QUIC-TLS.  The general principles of key update are not  <ins> changed in this specification.  Following QUIC version 1, the Key Phase bit is used to indicate which packet protection keys are used to protect the packet.  The Key Phase bit is toggled to signal each subsequent key update.  Because of network delays, packets protected with the older key might arrive later than the packets protected with the new key.  Therefore, the endpoint needs to retain old packet keys to allow these delayed packets to be processed and it must distinguish between the new key and the old key.  In QUIC version 1, this is done using packet numbers so that the rule is made simple: Use the older key if packet number is lower than any packet number frame the current key phase. </ins> When using multiple packet number spaces on different paths, some care is needed when initiating the Key Update process, as different