Draft: draft-ietf-quic-manageability

Commentary: I set the ready to merge label but there are merge conflict , so please do n't merge before accepting my suggestions ... 
 [ Ding2015 ] and [ IPIM ] are in the references of the manageability draft , but are n't actually ... referenced anywhere . That suggests either some text is missing or these entries are spurious . 
 Yes this has been already flagged by and is fixed in ( which we will all merge on Monday when Brain is back ) . Thanks anyway ! 
 Unused Reference : ' Ding2015 ' is defined on line 1272 , but no explicit reference was found in the text Unused Reference : ' IPIM ' is defined on line 1293 , but no explicit reference was found in the text 
 Duplicate reference : draft - ietf - quic - applicability , mentioned in ' QUIC - APPLICABILITY ' , was also mentioned in ' I - D.ietf - quic - applicability ' . 
 There are two paragraphs that include 2119 - language : RFC 2119 keyword , line 578 : ' ... RECOMMENDED . First , it only provid ... ' RFC 2119 keyword , line 969 : ' ... NOT RECOMMENDED .... ' Should these be made lowercase or is a 2119 paragraph needed ? 
 I see what was done . Looks ready to go .
Paragraph (version A):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing pure ACK
packets is easy in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Paragraph (version B):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing pure ACK
packets is easy in TCP, but not supported by QUIC, since
acknowledgment signaling is carried inside QUIC's encrypted payload,
and ACK manipulation is impossible.  Specifically, heuristics
attempting to distinguish ACK-only packets from payload-carrying
packets based on packet size are very likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Paragraph (version A):
QUIC is deliberately designed to fail rather than persist when the
network cannot support its operation.  For HTTP/3, this extends to
recommending a fallback to TCP-based versions of HTTP rather than
persisting with a QUIC connection that might be unstable.  And I-
D.ietf-quic-applicability recommends TCP fallback for other protocols
on the basis that this is preferable to sudden connection errors and
time outs.  Furthermore, wide deployment of NATs with this behavior
hinders the use of QUIC's migration function, which relies on the
ability to change the connection ID any time during the lifetime of a
QUIC connection.
Paragraph (version B):
QUIC is deliberately designed to fail rather than persist when the
network cannot support its operation.  For HTTP/3, this extends to
recommending a fallback to TCP-based versions of HTTP rather than
persisting with a QUIC connection that might be unstable.  And QUIC-
APPLICABILITY recommends TCP fallback for other protocols on the
basis that this is preferable to sudden connection errors and time
outs.  Furthermore, wide deployment of NATs with this behavior
hinders the use of QUIC's migration function, which relies on the
ability to change the connection ID any time during the lifetime of a
QUIC connection.