Mostly editorial comments by Lucas

draft-ietf-quic-multipath.md

@@ -144,7 +144,7 @@ This extension can be used with different scheduling algorithms that,
 e.g., can range from support for failover to simulatenous
 use of the aggregated capacity across all open paths.
 There are currently no IETF specifications that define scheduling
-algorithms for simultaneously (concurrently) using multiple paths.
+algorithms for simultaneously (i.e., concurrently) using multiple paths.
 
 Specifically, while failover between Wi-Fi
 and mobile networks is a well-known multipath use case,
@@ -163,18 +163,22 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 {{!RFC2119}} {{!RFC8174}} when, and only when, they appear in all
 capitals, as shown here.
 
-We assume that the reader is familiar with the terminology used in
-{{QUIC-TRANSPORT}}. When this document uses the term "path", it refers
+This document uses the terminology defined in {{QUIC-TRANSPORT}}.
+When this document uses the term "path", it refers
 to the notion of "network path" used in {{QUIC-TRANSPORT}}.
 
-# Transport Handshake and Cryptographic Packet Protection
+The packet diagrams in this document uses the conventions defined
+in {{Section 1.3 of QUIC-TRANSPORT}}, including the notation (i) to denote
+variable-length integers, encoded as specified in {{Section 16 of QUIC-TRANSPORT}}.
+
+# Connection Lifecycle and Packet Protection
 
 This document defines a new transport parameter initial_max_path_id
 to indicate the support of the multipath extension.
-If any of the endpoints does not advertise the initial_max_path_id transport
-parameter, then the endpoints MUST NOT use any frame or
+If either of the endpoints does not advertise the initial_max_path_id transport
+parameter, then both endpoints MUST NOT use any frame or
 mechanism defined in this document.
-If the use of the multipath extension is agreed after handshake completion,
+If both endpoints advertise the initial_max_path_id transport parameter, once the handshake is completed
 a new AEAD usage applies to all 1-RTT packets, as specified in Section {{nonce}},
 and new paths can be used, as specified in Section {{path-management}}.
 
@@ -339,7 +343,7 @@ or how multiple open paths are used for sending.
 For path management this extension specifies the following frames in {{frames}}:
 
 * PATH_ABANDON (see {{path-abandon-frame}})
-* PATH_BACKUP (see {{path-backup-available-frame}})
+* PATH_STATUS_BACKUP (see {{path-backup-available-frame}})
 * PATH_STATUS_AVAILABLE (see {{path-backup-available-frame}})
 * PATH_NEW_CONNECTION_ID (see {{mp-new-conn-id-frame}})
 * PATH_RETIRE_CONNECTION_ID (see {{mp-retire-conn-id-frame}})
@@ -368,8 +372,8 @@ Until the client's address is
 validated, the anti-amplification limit from {{Section 8 of QUIC-TRANSPORT}}
 applies.
 
-If an endpoint sends a PATH_RESPONSE, it MUST be sent on the same path
-as used by the packet that contained the PATH_CHALLENGE frame,
+If an endpoint sends a PATH_RESPONSE ({{Section 19.18 of QUIC-TRANSPORT}}), it MUST be sent on the same path
+as used by the packet that contained the PATH_CHALLENGE frame ({{Section 19.17 of QUIC-TRANSPORT}}),
 using a connection ID associated with the same path ID.
 
 The server might receive packets for a yet unused path ID that do not
@@ -386,7 +390,7 @@ on another path, as specified in {{path-close}}.
 
 An endpoint that has no active connection ID for this path or
 lacks other resource to immediately configure a new path could
-delay sending the PATH_RESPONSE until sufficient resource are available.
+delay sending the PATH_RESPONSE until sufficient resources are available.
 Long delays might cause the peer to repeat the PATH_CHALLENGE and eventually
 send a PATH_ABANDON, in which case the procedures specified in
 Section {{path-close}} apply.
@@ -1130,7 +1134,7 @@ With the multipath extension, each
 path uses a separate packet number space.
 This is a major difference from
 {{QUIC-TRANSPORT}}, which only defines three number spaces (Initial,
-Handshake and Application packets).
+Handshake and Application data packets).
 
 For any given path, connection ID rotation, NAT rebinding, or client initiated migration
 as specified in {{QUIC-TRANSPORT}} might occur, like on a single path.