Draft: draft-ietf-quic-transport

Commentary: In most cases , this turned out to be the wrong word anyway . There is " can " , which is a simple statement of fact . There is " could " , for stating that something is possible . There is " MAY " , once , which might be wrong . There is also cases where the word was n't needed at all . I know that " may " is used in all of these cases in the strictly colloquial sense , with no normative intent , but it is a tiny bit distracting . 
 Yes , all of these look nit , but LGTM . Thanks for doing this !
Paragraph (version A):
A bidirectional stream is composed of sending and receiving parts.
Implementations may represent states of the bidirectional stream as
composites of sending and receiving stream states.  The simplest
model presents the stream as "open" when either sending or receiving
parts are in a non-terminal state and "closed" when both sending and
receiving streams are in terminal states.
Paragraph (version B):
A bidirectional stream is composed of sending and receiving parts.
Implementations can represent states of the bidirectional stream as
composites of sending and receiving stream states.  The simplest
model presents the stream as "open" when either sending or receiving
parts are in a non-terminal state and "closed" when both sending and
receiving streams are in terminal states.
Paragraph (version A):
Multiple QUIC packets - even of different packet types - can be
coalesced into a single UDP datagram; see packet-coalesce.  As a
result, this handshake may consist of as few as 4 UDP datagrams, or
any number more (subject to limits inherent to the protocol, such as
congestion control or anti-amplification).  For instance, the
server's first flight contains Initial packets, Handshake packets,
and "0.5-RTT data" in 1-RTT packets with a short header.
Paragraph (version B):
Multiple QUIC packets - even of different packet types - can be
coalesced into a single UDP datagram; see packet-coalesce.  As a
result, this handshake could consist of as few as 4 UDP datagrams, or
any number more (subject to limits inherent to the protocol, such as
congestion control and anti-amplification).  For instance, the
server's first flight contains Initial packets, Handshake packets,
and "0.5-RTT data" in 1-RTT packets with a short header.
Paragraph (version A):
On confirming a peer's ownership of its new address, an endpoint MUST
immediately reset the congestion controller and round-trip time
estimator for the new path to initial values (see Appendices A.3 and
B.3 in QUIC-RECOVERY) unless the only change in the peer's address is
its port number.  Because port-only changes are commonly the result
of NAT rebinding or other middlebox activity, the endpoint MAY
instead retain its congestion control state and round-trip estimate
in those cases instead of reverting to initial values.  In cases
where congestion control state retained from an old path is used on a
new path with substantially different characteristics, a sender may
transmit too aggressively until the congestion controller and the RTT
estimator have adapted.  Generally, implementations are advised to be
cautious when using previous values on a new path.
Paragraph (version A):
There may be apparent reordering at the receiver when an endpoint
sends data and probes from/to multiple addresses during the migration
period, since the two resulting paths may have different round-trip
times.  A receiver of packets on multiple paths will still send ACK
frames covering all received packets.
Paragraph (version A):
While multiple paths might be used during connection migration, a
single congestion control context and a single loss recovery context
(as described in QUIC-RECOVERY) may be adequate.  For instance, an
endpoint might delay switching to a new congestion control context
until it is confirmed that an old path is no longer needed (such as
the case in off-path-forward).
Paragraph (version B):
On confirming a peer's ownership of its new address, an endpoint MUST
immediately reset the congestion controller and round-trip time
estimator for the new path to initial values (see Appendices A.3 and
B.3 in QUIC-RECOVERY) unless the only change in the peer's address is
its port number.  Because port-only changes are commonly the result
of NAT rebinding or other middlebox activity, the endpoint MAY
instead retain its congestion control state and round-trip estimate
in those cases instead of reverting to initial values.  In cases
where congestion control state retained from an old path is used on a
new path with substantially different characteristics, a sender could
transmit too aggressively until the congestion controller and the RTT
estimator have adapted.  Generally, implementations are advised to be
cautious when using previous values on a new path.
Paragraph (version B):
There could be apparent reordering at the receiver when an endpoint
sends data and probes from/to multiple addresses during the migration
period, since the two resulting paths could have different round-trip
times.  A receiver of packets on multiple paths will still send ACK
frames covering all received packets.
Paragraph (version B):
While multiple paths might be used during connection migration, a
single congestion control context and a single loss recovery context
(as described in QUIC-RECOVERY) could be adequate.  For instance, an
endpoint might delay switching to a new congestion control context
until it is confirmed that an old path is no longer needed (such as
the case in off-path-forward).
Paragraph (version A):
When a packet containing an ACK frame is sent, the largest
acknowledged in that frame may be saved.  When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent
ACK frame.
Paragraph (version B):
When a packet containing an ACK frame is sent, the largest
acknowledged in that frame can be saved.  When a packet containing an
ACK frame is acknowledged, the receiver can stop acknowledging
packets less than or equal to the largest acknowledged in the sent
ACK frame.
Paragraph (version A):
Future versions of QUIC may have different requirements for the
lengths of connection IDs.  In particular, connection IDs might have
a smaller minimum length or a greater maximum length.  Version-
specific rules for the connection ID therefore MUST NOT influence a
server decision about whether to send a Version Negotiation packet.
Paragraph (version B):
Future versions of QUIC could have different requirements for the
lengths of connection IDs.  In particular, connection IDs might have
a smaller minimum length or a greater maximum length.  Version-
specific rules for the connection ID therefore MUST NOT influence a
server decision about whether to send a Version Negotiation packet.
Paragraph (version A):
Transport parameters with an identifier of the form "31 * N + 27" for
integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored.  These transport parameters
have no semantics, and may carry arbitrary values.
Paragraph (version B):
Transport parameters with an identifier of the form "31 * N + 27" for
integer values of N are reserved to exercise the requirement that
unknown transport parameters be ignored.  These transport parameters
have no semantics, and can carry arbitrary values.
Paragraph (version A):
The initial maximum bidirectional streams parameter is an integer
value that contains the initial maximum number of bidirectional
streams the peer may initiate.  If this parameter is absent or
zero, the peer cannot open bidirectional streams until a
MAX_STREAMS frame is sent.  Setting this parameter is equivalent
to sending a MAX_STREAMS (frame-max-streams) of the corresponding
type with the same value.
Paragraph (version A):
The initial maximum unidirectional streams parameter is an integer
value that contains the initial maximum number of unidirectional
streams the peer may initiate.  If this parameter is absent or
zero, the peer cannot open unidirectional streams until a
MAX_STREAMS frame is sent.  Setting this parameter is equivalent
to sending a MAX_STREAMS (frame-max-streams) of the corresponding
type with the same value.
Paragraph (version B):
The initial maximum bidirectional streams parameter is an integer
value that contains the initial maximum number of bidirectional
streams the peer is permitted to initiate.  If this parameter is
absent or zero, the peer cannot open bidirectional streams until a
MAX_STREAMS frame is sent.  Setting this parameter is equivalent
to sending a MAX_STREAMS (frame-max-streams) of the corresponding
type with the same value.
Paragraph (version B):
The initial maximum unidirectional streams parameter is an integer
value that contains the initial maximum number of unidirectional
streams the peer is permitted to initiate.  If this parameter is
absent or zero, the peer cannot open unidirectional streams until
a MAX_STREAMS frame is sent.  Setting this parameter is equivalent
to sending a MAX_STREAMS (frame-max-streams) of the corresponding
type with the same value.
Paragraph (version A):
An opaque blob that the client may use with a future Initial
packet.  The token MUST NOT be empty.  An endpoint MUST treat
receipt of a NEW_TOKEN frame with an empty Token field as a
connection error of type FRAME_ENCODING_ERROR.
Paragraph (version B):
An opaque blob that the client can use with a future Initial
packet.  The token MUST NOT be empty.  An endpoint MUST treat
receipt of a NEW_TOKEN frame with an empty Token field as a
connection error of type FRAME_ENCODING_ERROR.
Paragraph (version A):
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
indicate that it will no longer use a connection ID that was issued
by its peer.  This may include the connection ID provided during the
handshake.  Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use;
see connection-id.  New connection IDs can be delivered to a peer
using the NEW_CONNECTION_ID frame (frame-new-connection-id).
Paragraph (version B):
An endpoint sends a RETIRE_CONNECTION_ID frame (type=0x19) to
indicate that it will no longer use a connection ID that was issued
by its peer.  This includes the connection ID provided during the
handshake.  Sending a RETIRE_CONNECTION_ID frame also serves as a
request to the peer to send additional connection IDs for future use;
see connection-id.  New connection IDs can be delivered to a peer
using the NEW_CONNECTION_ID frame (frame-new-connection-id).
Paragraph (version A):
This section lists the defined QUIC transport error codes that may be
used in a CONNECTION_CLOSE frame with a type of 0x1c.  These errors
apply to the entire connection.
Paragraph (version B):
This section lists the defined QUIC transport error codes that can be
used in a CONNECTION_CLOSE frame with a type of 0x1c.  These errors
apply to the entire connection.
Paragraph (version A):
For this purpose, attacks are divided into passive and active
attacks.  Passive attackers have the capability to read packets from
the network, while active attackers also have the capability to write
packets into the network.  However, a passive attack may involve an
attacker with the ability to cause a routing change or other
modification in the path taken by packets that comprise a connection.
Paragraph (version B):
For this purpose, attacks are divided into passive and active
attacks.  Passive attackers have the capability to read packets from
the network, while active attackers also have the capability to write
packets into the network.  However, a passive attack could involve an
attacker with the ability to cause a routing change or other
modification in the path taken by packets that comprise a connection.
Paragraph (version A):
Endpoints are permitted to use other methods to detect and attempt to
recover from interference with the handshake.  Invalid packets may be
identified and discarded using other methods, but no specific method
is mandated in this document.
Paragraph (version B):
Endpoints are permitted to use other methods to detect and attempt to
recover from interference with the handshake.  Invalid packets can be
identified and discarded using other methods, but no specific method
is mandated in this document.
Paragraph (version A):
An attacker might be able to receive an address validation token
(address-validation) from a server and then release the IP address it
used to acquire that token.  At a later time, the attacker may
initiate a 0-RTT connection with a server by spoofing this same
address, which might now address a different (victim) endpoint.  The
attacker can thus potentially cause the server to send an initial
congestion window's worth of data towards the victim.
Paragraph (version B):
An attacker might be able to receive an address validation token
(address-validation) from a server and then release the IP address it
used to acquire that token.  At a later time, the attacker can
initiate a 0-RTT connection with a server by spoofing this same
address, which might now address a different (victim) endpoint.  The
attacker can thus potentially cause the server to send an initial
congestion window's worth of data towards the victim.
Paragraph (version A):
Normally, clients will open streams sequentially, as explained in
stream-id.  However, when several streams are initiated at short
intervals, loss or reordering may cause STREAM frames that open
streams to be received out of sequence.  On receiving a higher-
numbered stream ID, a receiver is required to open all intervening
streams of the same type; see stream-recv-states.  Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams.
Paragraph (version B):
Normally, clients will open streams sequentially, as explained in
stream-id.  However, when several streams are initiated at short
intervals, loss or reordering can cause STREAM frames that open
streams to be received out of sequence.  On receiving a higher-
numbered stream ID, a receiver is required to open all intervening
streams of the same type; see stream-recv-states.  Thus, on a new
connection, opening stream 4000000 opens 1 million and 1 client-
initiated bidirectional streams.