Draft: draft-ietf-quic-transport

Commentary: This picks those changes from that are good that do n't conflict with other changes that are in flight ( to the best of my knowledge , that is ) . I 've done some additional editorial work around some of these as no surrounding text is safe when these edits land . 
 one nit , but LGTM
Paragraph (version A):
An opaque identifier that is used to identify a QUIC connection at
an endpoint.  Each endpoint selects one or more Connection IDs for
its peer to include in packets sent towards the endpoint.
Paragraph (version B):
An identifier that is used to identify a QUIC connection at an
endpoint.  Each endpoint selects one or more Connection IDs for
its peer to include in packets sent towards the endpoint.  This
value is opaque to the peer.
Paragraph (version A):
Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application.  Streams can be unidirectional or
bidirectional.  An alternative view of QUIC unidirectional streams is
a "message" abstraction of practically unlimited length.
Paragraph (version B):
Streams in QUIC provide a lightweight, ordered byte-stream
abstraction to an application.  Streams can be unidirectional or
bidirectional.
Paragraph (version A):
A receiver can advertise a larger limit for a stream by sending a
MAX_STREAM_DATA frame with the Stream ID field set appropriately.  A
MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a
stream.  A receiver could use the current offset of data consumed to
determine the flow control offset to be advertised.  A receiver MAY
send MAX_STREAM_DATA frames in multiple packets in order to make sure
that the sender receives an update before running out of flow
control, even if one of the packets is lost.
Paragraph (version B):
Senders MUST not send data in excess of either limit.
Paragraph (version B):
A receiver can advertise a larger limit for a stream by sending a
MAX_STREAM_DATA frame with the corresponding stream ID.  A
MAX_STREAM_DATA frame indicates the maximum absolute byte offset of a
stream.  A receiver could use the current offset of data consumed to
determine the flow control offset to be advertised.
Paragraph (version A):
To avoid blocking a sender, a receiver can send a MAX_STREAM_DATA or
MAX_DATA frame multiple times within a round trip or send it early
enough to allow for recovery from loss of the frame.
Paragraph (version B):
To avoid blocking a sender, a receiver MAY send a MAX_STREAM_DATA or
MAX_DATA frame multiple times within a round trip or send it early
enough to allow for recovery from loss of the frame.
Paragraph (version A):
Version negotiation ensures that client and server agree to a QUIC
version that is mutually supported.  A server sends a Version
Negotiation packet in response to each packet that might initiate a
new connection; see packet-handling for details.
Paragraph (version B):
Version negotiation allows a server to indicate that it does not
support the version the client used.  A server sends a Version
Negotiation packet in response to each packet that might initiate a
new connection; see packet-handling for details.
Paragraph (version A):
During the handshake, packets with the long header (long-header) are
used to establish the connection IDs in each direction.  Each
endpoint uses the Source Connection ID field to specify the
connection ID that is used in the Destination Connection ID field of
packets being sent to them.  Upon receiving a packet, each endpoint
sets the Destination Connection ID it sends to match the value of the
Source Connection ID that it receives.
Paragraph (version B):
During the handshake, packets with the long header (long-header) are
used to establish the connection IDs used by both endpoints.  Each
endpoint uses the Source Connection ID field to specify the
connection ID that is used in the Destination Connection ID field of
packets being sent to them.  After processing the first Initial
packet, each endpoint sets the Destination Connection ID field in
subsequent packets it sends to the value of the Source Connection ID
field that it received.
Paragraph (version A):
To protect the connection from failing due to such a spurious
migration, an endpoint MUST revert to using the last validated peer
address when validation of a new peer address fails.
Paragraph (version B):
To protect the connection from failing due to such a spurious
migration, an endpoint MUST revert to using the last validated peer
address when validation of a new peer address fails.  Additionally,
receipt of packets with higher packet numbers from the legitimate
peer address will trigger another connection migration.  This will
cause the validation of the address of the spurious migration to be
abandoned, thus containing migrations initiated by the attacker
injecting a single packet.
Paragraph (version A):
Note that receipt of packets with higher packet numbers from the
legitimate peer address will trigger another connection migration.
This will cause the validation of the address of the spurious
migration to be abandoned.
Paragraph (version A):
Once the handshake is confirmed, the client SHOULD select one of the
two server's preferred addresses and initiate path validation (see
migrate-validate) of that address using any previously unused active
connection ID, taken from either the preferred_address transport
parameter or a NEW_CONNECTION_ID frame.
Paragraph (version B):
Once the handshake is confirmed, the client SHOULD select one of the
two addresses provided by the server and initiate path validation
(see migrate-validate).  A client constructs packets using any
previously unused active connection ID, taken from either the
preferred_address transport parameter or a NEW_CONNECTION_ID frame.
Paragraph (version A):
A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
assured that the server has accepted 0-RTT and so sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the
application error code might not be received.
Paragraph (version B):
A client that sends CONNECTION_CLOSE in a 0-RTT packet cannot be
assured that the server has accepted 0-RTT.  Sending a
CONNECTION_CLOSE frame in an Initial packet makes it more likely
that the server can receive the close signal, even if the
application error code might not be received.
Paragraph (version A):
The algorithms in QUIC-RECOVERY are expected to be resilient to
receivers that do not follow guidance offered above.  However, an
implementation should only deviate from these requirements after
careful consideration of the performance implications of a change,
for connections made by the endpoint and for other users of the
network.
Paragraph (version B):
The algorithms in QUIC-RECOVERY are expected to be resilient to
receivers that do not follow the guidance offered above.  However, an
implementation should only deviate from these requirements after
careful consideration of the performance implications of a change,
for connections made by the endpoint and for other users of the
network.
Paragraph (version A):
Two bits (those with a mask of 0x0c) of byte 0 are reserved across
multiple packet types.  These bits are protected using header
protection; see Section 5.4 of QUIC-TLS.  The value included prior
to protection MUST be set to 0.  An endpoint MUST treat receipt of
a packet that has a non-zero value for these bits, after removing
both packet and header protection, as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.3 of QUIC-TLS.
Paragraph (version B):
Two bits (those with a mask of 0x0c) of byte 0 are reserved across
multiple packet types.  These bits are protected using header
protection; see Section 5.4 of QUIC-TLS.  The value included prior
to protection MUST be set to 0.  An endpoint MUST treat receipt of
a packet that has a non-zero value for these bits after removing
both packet and header protection as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.3 of QUIC-TLS.
Paragraph (version A):
The next Initial packet from the client uses the connection ID and
token values from the Retry packet; see negotiating-connection-ids.
Aside from this, the Initial packet sent by the client is subject to
the same restrictions as the first Initial packet.  A client MUST use
the same cryptographic handshake message it includes in this packet.
A server MAY treat a packet that contains a different cryptographic
handshake message as a connection error or discard it.
Paragraph (version B):
The next Initial packet from the client uses the connection ID and
token values from the Retry packet; see negotiating-connection-ids.
Aside from this, the Initial packet sent by the client is subject to
the same restrictions as the first Initial packet.  A client MUST use
the same cryptographic handshake message it included in this packet.
A server MAY treat a packet that contains a different cryptographic
handshake message as a connection error or discard it.
Paragraph (version A):
STREAM frames implicitly create a stream and carry stream data.  The
STREAM frame takes the form 0b00001XXX (or the set of values from
0x08 to 0x0f).  The value of the three low-order bits of the frame
type determines the fields that are present in the frame.