[Insert ARTART boilerplate here]

This specification builds on QUIC's capabilities for connection
migration to use multiple paths simultaneously for a single
connection.
It provides a mechanism for managing state necessary for running the
QUIC protocol with multiple concurrent paths, but deliberately leaves
address discovery, scheduling of packets over multiple paths, and
congestion control out of scope.

It is refreshing to see that the mechanism for multipath is being
specified before the obvious blanks (congestion control, scheduling)
can be filled in in a normative way.

The word “application” occurs about a dozen times, often in constructs
such as “suit the needs of the application”.
For example, the "[...]decision to setup or tear down paths are
assumed to be handled by the application" (introduction).
This reader expects some considerable innovation in how these needs
and decisions are communicated to the QUIC implementation, or, where
the application is in control, modulated by the state of the QUIC
implementation.

## General editorial

In some places, the document is heavy on passive usage.
On the passive sentences, it is not always clear to a new reader who
the actor is, or whether the verb is actually used as an adjective
(e.g., see last sentence of 3.1.2).

## Minor

2.1:
Path ID is supposed to be an unsigned integer < 2**32, but then 2.4
talks about the “least significant 32 bits of path_id”.
(It is also confusing that the term “value” is used for both the type,
which is a 60-bit number during the experiment phase, and the value of
the transport parameter.)

3.2.1: Is the “maximum path ID limit” discussed here related to
initial_max_path_id/MAX_PATH_ID?
Is the “active path limit” the same thing?
4.7 has a “maximum path ID that was allowed” — by whom?
(Maybe it would be worth to introduce clear terms for the most
recently unilaterally declared [ignoring non-monotonic MAX_PATH
messages] and the combined value state.)

This reader does not understand how concurrent allocation on the
shared number space of path IDs is managed.
Do the peer applications have to run some protocol to agree on how
which path ID is used for what?
What happens when this protocol and the protocol specified here run
out of sync?
Who controls the parameters (e.g., diffserv markings) used with a
specific path ID?

4.3 and elsewhere (3 times):
s/monotonically increasing/strictly increasing/

5.4:
What is “connection control” in this context?

6:
When the allocations are inserted into the registry, the specification
links need to mention the RFC number (RFC XXXX).

7.2:
Where QUIC has arrived at rather heavy normative amplification limits
(good!), this section is at the level of “might consider”.
(Maybe we need to understand potential attacks more before they can be
effectively mitigated, but this looks like it is introducing a period
of instability.)

## Nits

A couple dozen nits are addressed in
https://github.com/quicwg/multipath/pull/628

(This includes internally consistent spelling for "acknowledgements",
using the spelling from RFC 7322.)

7.3:
“This specification changes the AEAD calculation”:
I hope not.
It changes the calculation of the *input* to the AEAD.