Draft: draft-ietf-quic-transport

Commentary: There are other uses of " in order " that the editors may like to address to avoid potential misunderstanding : /An adversarial receiver might intentionally not acknowledge packets containing stream data in order to force the sender to store the unacknowledged stream data for retransmission./ would be clearer as /An adversarial receiver might intentionally not acknowledge packets containing stream data so that it forces the sender to store the unacknowledged stream data for retransmission./ 
 There are other uses of " in order " that the editors may like to address to avoid potential misunderstanding : This also is potentially misread : /An adversarial sender might intentionally send fragments of stream data in order to cause disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure./ and could be /An adversarial sender might intentionally send fragments of stream data that cause disproportionate receive buffer memory commitment and/or creation of a large and inefficient data structure./ 
 There are other uses of " in order " that the editors may like to address to avoid potential misunderstanding : /Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet./ ... seem like /Servers SHOULD be able to read longer connection IDs from other QUIC versions to properly form a version negotiation packet./ 
 " in order to " seems like a well - known construction , so I 'm not concerned about its existence . Your rewording loses the implication of " SHOULD ... because you 'll need to .... " Though I see your point that this sentence could be parsed as " reading in order " being the thing servers SHOULD be able to do . Perhaps " In order to properly form X , servers SHOULD Y " ? 
 Also , this seems to be the same sentence as ? 
 That works for me - starting with the construction seems clear .   The new PR appears to have all the in orders in good order then ! 
 There are other uses of " in order " that the editors may like to address to avoid potential misunderstanding : /Servers SHOULD be able to read longer connection IDs from other QUIC versions in order to properly form a version negotiation packet./ ... this might be misread as an ordering requirement , but I think is intend to be : /Servers SHOULD be able to read longer connection IDs from other QUIC versions to properly form a version negotiation packet./ 
 FYI , it 's more readable to quote with , e.g. , this might be misread as an ordering requirement , but I think is intend to be : 
 All looks clear to me .
Paragraph (version A):
The byte following the version contains the length in bytes of the
Destination Connection ID field that follows it.  This length is
encoded as an 8-bit unsigned integer.  In QUIC version 1, this
value MUST NOT exceed 20.  Endpoints that receive a version 1 long
header with a value larger than 20 MUST drop the packet.  Servers
SHOULD be able to read longer connection IDs from other QUIC
versions in order to properly form a version negotiation packet.
Paragraph (version B):
The byte following the version contains the length in bytes of the
Destination Connection ID field that follows it.  This length is
encoded as an 8-bit unsigned integer.  In QUIC version 1, this
value MUST NOT exceed 20.  Endpoints that receive a version 1 long
header with a value larger than 20 MUST drop the packet.  In order
to properly form a Version Negotiation packet, servers SHOULD be
able to read longer connection IDs from other QUIC versions.
Paragraph (version A):
The byte following the Destination Connection ID contains the
length in bytes of the Source Connection ID field that follows it.
This length is encoded as a 8-bit unsigned integer.  In QUIC
version 1, this value MUST NOT exceed 20 bytes.  Endpoints that
receive a version 1 long header with a value larger than 20 MUST
drop the packet.  Servers SHOULD be able to read longer connection
IDs from other QUIC versions in order to properly form a version
negotiation packet.
Paragraph (version B):
The byte following the Destination Connection ID contains the
length in bytes of the Source Connection ID field that follows it.
This length is encoded as a 8-bit unsigned integer.  In QUIC
version 1, this value MUST NOT exceed 20 bytes.  Endpoints that
receive a version 1 long header with a value larger than 20 MUST
drop the packet.  In order to properly form a Version Negotiation
packet, servers SHOULD be able to read longer connection IDs from
other QUIC versions.
Paragraph (version A):
An adversarial sender might intentionally send fragments of stream
data in order to cause disproportionate receive buffer memory
commitment and/or creation of a large and inefficient data structure.
Paragraph (version A):
An adversarial receiver might intentionally not acknowledge packets
containing stream data in order to force the sender to store the
unacknowledged stream data for retransmission.
Paragraph (version B):
An adversarial sender might intentionally send fragments of stream
data in an attempt to cause disproportionate receive buffer memory
commitment and/or creation of a large and inefficient data structure.
Paragraph (version B):
An adversarial receiver might intentionally not acknowledge packets
containing stream data in an attempt to force the sender to store the
unacknowledged stream data for retransmission.