Draft: draft-ietf-quic-qpack

Commentary: " This is a description of something technical ; see { { place } } [ for more details ] . " is more correct than " This is a description of something technical , see { { place } } [ for more details ] . " because the " { { place } } " is a separate thought . The comma is appropriate when it 's saying " For more details , see { { place } } . " because that 's a single thought . We have a mix throughout the documents ; this PR attempts to reconcile them . 
 I think this is just waiting for you . 
 Seems fine ?
Paragraph (version A):
Post-Base references are used for entries inserted after base,
starting at 0 for the first entry added after the Base, see post-
base.
Paragraph (version B):
Post-Base references are used for entries inserted after base,
starting at 0 for the first entry added after the Base; see post-
base.
Paragraph (version A):
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets.  The maximum ack delay is communicated in the
max_ack_delay transport parameter, see Section 18.1 of QUIC-
TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint
promises to never delay acknowledgments of an ack-eliciting packet by
more than the indicated value.  If it does, any excess accrues to the
RTT estimate and could result in spurious retransmissions from the
peer.  For Initial and Handshake packets, a max_ack_delay of 0 is
used.
Paragraph (version B):
An endpoint MUST NOT excessively delay acknowledgements of ack-
eliciting packets.  The maximum ack delay is communicated in the
max_ack_delay transport parameter; see Section 18.1 of QUIC-
TRANSPORT.  max_ack_delay implies an explicit contract: an endpoint
promises to never delay acknowledgments of an ack-eliciting packet by
more than the indicated value.  If it does, any excess accrues to the
RTT estimate and could result in spurious retransmissions from the
peer.  For Initial and Handshake packets, a max_ack_delay of 0 is
used.
Paragraph (version A):
A PTO timer expiration event does not indicate packet loss and MUST
NOT cause prior unacknowledged packets to be marked as lost.  When an
acknowledgement is received that newly acknowledges packets, loss
detection proceeds as dictated by packet and time threshold
mechanisms, see ack-loss-detection.
Paragraph (version B):
A PTO timer expiration event does not indicate packet loss and MUST
NOT cause prior unacknowledged packets to be marked as lost.  When an
acknowledgement is received that newly acknowledges packets, loss
detection proceeds as dictated by packet and time threshold
mechanisms; see ack-loss-detection.
Paragraph (version A):
After QUIC moves to a new encryption level, packet protection keys
for previous encryption levels can be discarded.  This occurs several
times during the handshake, as well as when keys are updated (see
key-update).  Initial packet protection keys are treated specially,
see discard-initial.
Paragraph (version B):
After QUIC moves to a new encryption level, packet protection keys
for previous encryption levels can be discarded.  This occurs several
times during the handshake, as well as when keys are updated (see
key-update).  Initial packet protection keys are treated specially;
see discard-initial.
Paragraph (version A):
The current encryption level secret and the label "quic key" are
input to the KDF to produce the AEAD key; the label "quic iv" is used
to derive the IV, see aead.  The header protection key uses the "quic
hp" label, see header-protect.  Using these labels provides key
separation between QUIC and TLS, see key-diversity.
Paragraph (version B):
The current encryption level secret and the label "quic key" are
input to the KDF to produce the AEAD key; the label "quic iv" is used
to derive the IV; see aead.  The header protection key uses the "quic
hp" label; see header-protect.  Using these labels provides key
separation between QUIC and TLS; see key-diversity.
Paragraph (version A):
An endpoint SHOULD retain old keys for a period of no more than three
times the Probe Timeout (PTO, see QUIC-RECOVERY).  After this period,
old keys and their corresponding secrets SHOULD be discarded.
Retaining keys allow endpoints to process packets that were sent with
old keys and delayed in the network.  Packets with higher packet
numbers always use the updated keys and MUST NOT be decrypted with
old keys.
Paragraph (version B):
An endpoint SHOULD retain old keys for a period of no more than three
times the Probe Timeout (PTO; see QUIC-RECOVERY).  After this period,
old keys and their corresponding secrets SHOULD be discarded.
Retaining keys allow endpoints to process packets that were sent with
old keys and delayed in the network.  Packets with higher packet
numbers always use the updated keys and MUST NOT be decrypted with
old keys.
Paragraph (version A):
Data sent in CRYPTO frames is not flow controlled in the same way as
stream data.  QUIC relies on the cryptographic protocol
implementation to avoid excessive buffering of data, see QUIC-TLS.
The implementation SHOULD provide an interface to QUIC to tell it
about its buffering limits so that there is not excessive buffering
at multiple layers.
Paragraph (version B):
Data sent in CRYPTO frames is not flow controlled in the same way as
stream data.  QUIC relies on the cryptographic protocol
implementation to avoid excessive buffering of data; see QUIC-TLS.
The implementation SHOULD provide an interface to QUIC to tell it
about its buffering limits so that there is not excessive buffering
at multiple layers.
Paragraph (version A):
Packets with long headers include Source Connection ID and
Destination Connection ID fields.  These fields are used to set the
connection IDs for new connections, see negotiating-connection-ids
for details.
Paragraph (version B):
Packets with long headers include Source Connection ID and
Destination Connection ID fields.  These fields are used to set the
connection IDs for new connections; see negotiating-connection-ids
for details.
Paragraph (version A):
An endpoint can change the connection ID it uses for a peer to
another available one at any time during the connection.  An endpoint
consumes connection IDs in response to a migrating peer, see
migration-linkability for more.
Paragraph (version B):
An endpoint can change the connection ID it uses for a peer to
another available one at any time during the connection.  An endpoint
consumes connection IDs in response to a migrating peer; see
migration-linkability for more.
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 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 A):
The connection ID can change over the lifetime of a connection,
especially in response to connection migration (migration), see
issue-cid for details.
Paragraph (version B):
The connection ID can change over the lifetime of a connection,
especially in response to connection migration (migration); see
issue-cid for details.
Paragraph (version A):
Each endpoint advertises its own idle timeout to its peer.  An
endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully.  The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet, see QUIC-RECOVERY), but only if no other ACK-
eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity.
Paragraph (version B):
Each endpoint advertises its own idle timeout to its peer.  An
endpoint restarts any timer it maintains when a packet from its peer
is received and processed successfully.  The timer is also restarted
when sending a packet containing frames other than ACK or PADDING (an
ACK-eliciting packet; see QUIC-RECOVERY), but only if no other ACK-
eliciting packets have been sent since last receiving a packet.
Restarting when sending packets ensures that connections do not
prematurely time out when initiating new activity.
Paragraph (version A):
The value for an idle timeout can be asymmetric.  The value
advertised by an endpoint is only used to determine whether the
connection is live at that endpoint.  An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the
packets arrive.  If a peer could timeout within an Probe Timeout
(PTO, see Section 6.2.2 of QUIC-RECOVERY), it is advisable to test
for liveness before sending any data that cannot be retried safely.
Note that it is likely that only applications or application
protocols will know what information can be retried.
Paragraph (version B):
The value for an idle timeout can be asymmetric.  The value
advertised by an endpoint is only used to determine whether the
connection is live at that endpoint.  An endpoint that sends packets
near the end of the idle timeout period of a peer risks having those
packets discarded if its peer enters the draining state before the
packets arrive.  If a peer could timeout within an Probe Timeout
(PTO; see Section 6.2.2 of QUIC-RECOVERY), it is advisable to test
for liveness before sending any data that cannot be retried safely.
Note that it is likely that only applications or application
protocols will know what information can be retried.
Paragraph (version A):
The packet might not reach the peer.  If the Destination
Connection ID is critical for routing toward the peer, then this
packet could be incorrectly routed.  This might also trigger
another Stateless Reset in response, see reset-looping.  A
Stateless Reset that is not correctly routed is an ineffective
error detection and recovery mechanism.  In this case, endpoints
will need to rely on other methods - such as timers - to detect
that the connection has failed.
Paragraph (version B):
The packet might not reach the peer.  If the Destination
Connection ID is critical for routing toward the peer, then this
packet could be incorrectly routed.  This might also trigger
another Stateless Reset in response; see reset-looping.  A
Stateless Reset that is not correctly routed is an ineffective
error detection and recovery mechanism.  In this case, endpoints
will need to rely on other methods - such as timers - to detect
that the connection has failed.
Paragraph (version A):
The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet
protection is applied (see QUIC-TLS for details).  The underlying
packet number increases with each packet sent in a given packet
number space, see packet-numbers for details.
Paragraph (version B):
The packet number field contains a packet number, which has
additional confidentiality protection that is applied after packet
protection is applied (see QUIC-TLS for details).  The underlying
packet number increases with each packet sent in a given packet
number space; see packet-numbers for details.
Paragraph (version A):
Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the
stream enters either a "Data Recvd" or "Reset Recvd" state, see
solicited-state-transitions.
Paragraph (version B):
Similarly, a request to cancel stream transmission, as encoded in
a STOP_SENDING frame, is sent until the receiving part of the
stream enters either a "Data Recvd" or "Reset Recvd" state; see
solicited-state-transitions.
Paragraph (version A):
The payload of a UDP datagram carrying the first Initial packet MUST
be expanded to at least 1200 bytes, by adding PADDING frames to the
Initial packet and/or by combining the Initial packet with a 0-RTT
packet (see packet-coalesce).  Sending a UDP datagram of this size
ensures that the network path supports a reasonable Maximum
Transmission Unit (MTU), and helps reduce the amplitude of
amplification attacks caused by server responses toward an unverified
client address, see address-validation.
Paragraph (version B):
The payload of a UDP datagram carrying the first Initial packet MUST
be expanded to at least 1200 bytes, by adding PADDING frames to the
Initial packet and/or by combining the Initial packet with a 0-RTT
packet (see packet-coalesce).  Sending a UDP datagram of this size
ensures that the network path supports a reasonable Maximum
Transmission Unit (MTU), and helps reduce the amplitude of
amplification attacks caused by server responses toward an unverified
client address; see address-validation.
Paragraph (version A):
The server MUST also limit the number of bytes it sends before
validating the address of the client, see address-validation.
Paragraph (version B):
The server MUST also limit the number of bytes it sends before
validating the address of the client; see address-validation.
Paragraph (version A):
A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server.  A client
that sends additional 0-RTT packets without constructing a new
cryptographic handshake message MUST NOT reset the packet number to 0
after a Retry packet, see packet-0rtt.
Paragraph (version B):
A client MAY attempt 0-RTT after receiving a Retry packet by sending
0-RTT packets to the connection ID provided by the server.  A client
that sends additional 0-RTT packets without constructing a new
cryptographic handshake message MUST NOT reset the packet number to 0
after a Retry packet; see packet-0rtt.
Paragraph (version A):
The idle timeout is a value in milliseconds that is encoded as an
integer, see (idle-timeout).  If this parameter is absent or zero
then the idle timeout is disabled.
Paragraph (version A):
A stateless reset token is used in verifying a stateless reset,
see stateless-reset.  This parameter is a sequence of 16 bytes.
This transport parameter is only sent by a server.
Paragraph (version B):
The idle timeout is a value in milliseconds that is encoded as an
integer; see (idle-timeout).  If this parameter is absent or zero
then the idle timeout is disabled.
Paragraph (version B):
A stateless reset token is used in verifying a stateless reset;
see stateless-reset.  This parameter is a sequence of 16 bytes.
This transport parameter is only sent by a server.
Paragraph (version A):
Contains additional ranges of packets which are alternately not
acknowledged (Gap) and acknowledged (ACK Range), see ack-ranges.
Paragraph (version A):
The three ECN Counts, see ack-ecn-counts.
Paragraph (version B):
Contains additional ranges of packets which are alternately not
acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges.
Paragraph (version B):
The three ECN Counts; see ack-ecn-counts.
Paragraph (version A):
An IANA registry is used to manage the assignment of frame types, see
iana-frames.
Paragraph (version B):
An IANA registry is used to manage the assignment of frame types; see
iana-frames.