Draft: draft-ietf-quic-qpack

Commentary: if you are OK with this , merge it . You are the last one . 
 ping 
 :D 
 Merging .
Paragraph (version A):
An endpoint MAY avoid creating an encoder stream if it's not going to
be used (for example if its encoder doesn't wish to use the dynamic
table, or if the maximum size of the dynamic table permitted by the
peer is zero).
Paragraph (version B):
An endpoint MAY avoid creating an encoder stream if it's not going to
be used (for example if its encoder does not wish to use the dynamic
table, or if the maximum size of the dynamic table permitted by the
peer is zero).
Paragraph (version A):
The choice to mark that a header field should never be indexed
depends on several factors.  Since QPACK doesn't protect against
guessing an entire header field value, short or low-entropy values
are more readily recovered by an adversary.  Therefore, an encoder
might choose not to index values with low entropy.
Paragraph (version B):
The choice to mark that a header field should never be indexed
depends on several factors.  Since QPACK does not protect against
guessing an entire header field value, short or low-entropy values
are more readily recovered by an adversary.  Therefore, an encoder
might choose not to index values with low entropy.
Paragraph (version A):
Peer violated protocol requirements in a way that doesn't match a
more specific error code, or endpoint declines to use the more
specific error code.
Paragraph (version B):
Peer violated protocol requirements in a way that does not match a
more specific error code, or endpoint declines to use the more
specific error code.
Paragraph (version A):
This document doesn't mandate a specific method for negotiating the
use of an extension but notes that a setting (settings-parameters)
could be used for that purpose.  If both peers set a value that
indicates willingness to use the extension, then the extension can be
used.  If a setting is used for extension negotiation, the default
value MUST be defined in such a fashion that the extension is
disabled if the setting is omitted.
Paragraph (version B):
This document does not mandate a specific method for negotiating the
use of an extension but notes that a setting (settings-parameters)
could be used for that purpose.  If both peers set a value that
indicates willingness to use the extension, then the extension can be
used.  If a setting is used for extension negotiation, the default
value MUST be defined in such a fashion that the extension is
disabled if the setting is omitted.
Paragraph (version A):
An endpoint that doesn't monitor this behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a connection error (errors) of
type H3_EXCESSIVE_LOAD, but false positives will result in disrupting
valid connections and requests.
Paragraph (version B):
An endpoint that does not monitor this behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a connection error (errors) of
type H3_EXCESSIVE_LOAD, but false positives will result in disrupting
valid connections and requests.
Paragraph (version A):
The primary goal of this document is to ensure that it is possible to
deploy new versions of QUIC.  By documenting the properties that
can't change, this document aims to preserve the ability for QUIC
endpoints to negotiate changes to any other aspect of the protocol.
As a consequence, this also guarantees a minimal amount of
information that is made available to entities other than endpoints.
Unless specifically prohibited in this document, any aspect of the
protocol can change between different versions.
Paragraph (version B):
The primary goal of this document is to ensure that it is possible to
deploy new versions of QUIC.  By documenting the properties that
cannot change, this document aims to preserve the ability for QUIC
endpoints to negotiate changes to any other aspect of the protocol.
As a consequence, this also guarantees a minimal amount of
information that is made available to entities other than endpoints.
Unless specifically prohibited in this document, any aspect of the
protocol can change between different versions.
Paragraph (version A):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP, and below) don't cause
packets for a QUIC connection to be delivered to the wrong QUIC
endpoint.  The connection ID is used by endpoints and the
intermediaries that support them to ensure that each QUIC packet can
be delivered to the correct instance of an endpoint.  At the
endpoint, the connection ID is used to identify which QUIC connection
the packet is intended for.
Paragraph (version B):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP, and below) do not cause
packets for a QUIC connection to be delivered to the wrong QUIC
endpoint.  The connection ID is used by endpoints and the
intermediaries that support them to ensure that each QUIC packet can
be delivered to the correct instance of an endpoint.  At the
endpoint, the connection ID is used to identify which QUIC connection
the packet is intended for.
Paragraph (version A):
These state machines shown in this section are largely informative.
This document uses stream states to describe rules for when and how
different types of frames can be sent and the reactions that are
expected when different types of frames are received.  Though these
state machines are intended to be useful in implementing QUIC, these
states aren't intended to constrain implementations.  An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements these
states.
Paragraph (version B):
These state machines shown in this section are largely informative.
This document uses stream states to describe rules for when and how
different types of frames can be sent and the reactions that are
expected when different types of frames are received.  Though these
state machines are intended to be useful in implementing QUIC, these
states are not intended to constrain implementations.  An
implementation can define a different state machine as long as its
behavior is consistent with an implementation that implements these
states.
Paragraph (version A):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) don't cause packets for
a QUIC connection to be delivered to the wrong endpoint.  Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method that will allow packets with that
connection ID to be routed back to the endpoint and to be identified
by the endpoint upon receipt.
Paragraph (version B):
The primary function of a connection ID is to ensure that changes in
addressing at lower protocol layers (UDP, IP) do not cause packets
for a QUIC connection to be delivered to the wrong endpoint.  Each
endpoint selects connection IDs using an implementation-specific (and
perhaps deployment-specific) method that will allow packets with that
connection ID to be routed back to the endpoint and to be identified
by the endpoint upon receipt.
Paragraph (version A):
Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects.  Clients that choose to
receive zero-length connection IDs can use the local address and port
to identify a connection.  Packets that don't match an existing
connection are discarded.
Paragraph (version B):
Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects.  Clients that choose to
receive zero-length connection IDs can use the local address and port
to identify a connection.  Packets that do not match an existing
connection are discarded.
Paragraph (version A):
A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period
of inactivity.  Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection
migration.  This ensures that the mechanisms that support migration
are exercised even for clients that don't experience NAT rebindings
or genuine migrations.  Changing port number can cause a peer to
reset its congestion state (see migration-cc), so the port SHOULD
only be changed infrequently.
Paragraph (version B):
A client might wish to reduce linkability by employing a new
connection ID and source UDP port when sending traffic after a period
of inactivity.  Changing the UDP port from which it sends packets at
the same time might cause the packet to appear as a connection
migration.  This ensures that the mechanisms that support migration
are exercised even for clients that do not experience NAT rebindings
or genuine migrations.  Changing port number can cause a peer to
reset its congestion state (see migration-cc), so the port SHOULD
only be changed infrequently.
Paragraph (version A):
To support this process, a token is sent by endpoints.  The token is
carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
frame.  Servers can also specify a stateless_reset_token transport
parameter during the handshake that applies to the connection ID that
it selected during the handshake; clients cannot use this transport
parameter because their transport parameters don't have
confidentiality protection.  These tokens are protected by
encryption, so only client and server know their value.  Tokens are
invalidated when their associated connection ID is retired via a
RETIRE_CONNECTION_ID frame (frame-retire-connection-id).
Paragraph (version B):
To support this process, a token is sent by endpoints.  The token is
carried in the Stateless Reset Token field of a NEW_CONNECTION_ID
frame.  Servers can also specify a stateless_reset_token transport
parameter during the handshake that applies to the connection ID that
it selected during the handshake; clients cannot use this transport
parameter because their transport parameters do not have
confidentiality protection.  These tokens are protected by
encryption, so only client and server know their value.  Tokens are
invalidated when their associated connection ID is retired via a
RETIRE_CONNECTION_ID frame (frame-retire-connection-id).
Paragraph (version A):
If there are open streams that haven't been explicitly closed, they
are implicitly closed when the connection is closed.
Paragraph (version B):
If there are open streams that have not been explicitly closed, they
are implicitly closed when the connection is closed.