Change:
NAME had some useful feedback in . This doesn't address the following items as numbered in the issue: (2) Because the fix to (1) seems adequate by my reckoning. That addresses the question of considering the impact on other network users. (6) This doesn't appear to be a problem. It might be a formatting issue, with the URL not appearing. (7) This is addressed in the recent draft by adding Section  (9) and (11) I can't find the rendering glitch mentioned. The rest of these are good.
Fine and thanks for looking to these. I do think something more needs to be said about the need to avoid collateral impact on the forward traffic of this and other traffic sharing a path. To me this really important in an IETF Transport specification, especially one that might displace TCP. /It can also improve connection throughput on severely asymmetric links; see Section 3 of {{?RFC3449}}./ To me, a note to make sure this isn't ignored would seem enough, but I'd be happy to take this up as a separate WGLC comment if that seems better.
Let's take that up separately. I don't object to the language, but I just didn't know what to say.
I think there are NiTs in the second half the ID also, and while I suspectthese don't change the intended meaning, they nevertheless should be examined by the editors: (1) Concerning ACKS: I thought the following text was heading in the correct direction, but I remain concerned that this could be read to suggest that performance of the flow should drive the changes. /However, an implementer should only deviate from these requirements after careful consideration of the performance implications of doing so./ I’d love this to actually say something about congestion. Decisions made in the generation of ACKs can impact the congestion to the network and therefore also the performance of other flows that share a path. I really think we should say this. (2) And collateral impact on other traffic: /It can also improve connection throughput on severely asymmetric links; see Section 3 of {{?RFC3449}}./ It also can have important congestion impacts on other traffic that shares an asymmetric bottleneck, besides the self-harm of reducing the application’s own throughput. (3) Justify? This text seems a good recommendation, but there isn’t a hint at why this is a strong requirement, could the editors add one line of text explaining? /Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram./ (4) The size and frequency of ACKs can impact the performance of QUIC, so there are also congestion control reasons to not overly report ACK ranges. /This is necessary if an ACK frame would be too large to fit in a packet, however receivers MAY also limit ACK frame size further to preserve space for other frames./ (5) This seems an awkward sentence and I could not understand what was intended: /A receiver MUST NOT bundle an ack-eliciting frame with all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements./ Perhaps /all/ in this is part of my confusion? (6) In Section: Versions (missing words) /Implementors are encouraged to register version numbers of QUIC that they are using for private experimentation on the GitHub wiki at ./ either way, it may be better to complete the sentence? (7) In Section: PING Frame: (NiT) This seems good advice, but I’d love the sentence to include “to keep a connection alive”, since at the moment reading this alone, could be seen as rather general guidance. Whereas there are other uses of PINGs, such as PLPMTUD, and for this use can generate pings by clients and servers: /An application protocol SHOULD provide guidance about the conditions under which generating a PING is recommended. / e.g. /An application protocol SHOULD provide guidance about the conditions under which it recommends generating a PING to keep a connection alive./ (8) In ACKs: (NiT) /This is unlike TCP SACKs ({{?RFC2018}})./This is unlike reneging for TCP SACKs ({{?RFC2018}})./ can we be slightly more explicit about the important difference by adding a couple of words? (9) In Section: STREAM Frames (line break:) /Offset:/ The first sentence in /Offset/ appears to have an odd line-break mid sentence. (10) In Section: Extension Frames /which/that/? /other extensions which modify or replace the same functionality unless the behavior of the combination is explicitly defined./ (11) In Section: Transport Error Codes (line break:) INVALID_TOKEN (0xB): :/ The first sentence needs a line-break mid sentence. (12) In Section: Version Negotiation Is this only a recommendation? “Clients that support multiple QUIC versions SHOULD pad the first packet they send to the largest of the minimum packet sizes across all versions they support.” Whereas in Section: Packet Size /A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least 1200 bytes, by adding PADDING frames to the Initial packet or by coalescing the Initial packet; see {{packet-coalesce}}./ I think the latter is true, and suspect that version negotiation section shouldn’t include this text, but instead refer to the text norm initial packet size. (13) In Section: Cryptographic and Transport Handshake Is this intended as optional, I think it is required when ECN is to be used? “An endpoint can verify support for Explicit Congestion Notification (ECN) in the first packets it sends, as described in {{ecn-validation}}.” seems to suggest this is optional, whereas, I think actually this is describing a needed mechanism, so is it better to say “An endpoint verifies” as is done in the section: Initiating Connection Migration. which says: “The new path might not have the same ECN capability. Therefore, the endpoint verifies ECN capability as described in {{ecn}}.”
Let's get these in and deal with more specific issues separately.

Discussion:
The size of the first packet sent by a client will determine whether a server sends a Version Negotiation packet.  Clients that support <del> multiple QUIC versions SHOULD pad the first packet they send to the largest of the minimum packet sizes across all versions they support. This ensures that the server responds if there is a mutually supported version. </del> <ins> multiple QUIC versions SHOULD pad the first UDP datagram they send to the largest of the minimum datagram sizes from all versions they support.  This ensures that the server responds if there is a mutually supported version. </ins> 6.1.

authenticated negotiation of an application protocol (TLS uses ALPN RFC7301 for this purpose) <del> An endpoint can verify support for Explicit Congestion Notification </del> <ins> An endpoint verifies support for Explicit Congestion Notification </ins> (ECN) in the first packets it sends, as described in ecn-validation. The CRYPTO frame can be sent in different packet number spaces

endpoint SHOULD NOT coalesce multiple packets at the same encryption level. <del> Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram.  Receivers SHOULD ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram. </del> <ins> Receivers MAY route based on the information in the first packet contained in a UDP datagram.  Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram.  Receivers SHOULD ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram. </ins> Every QUIC packet that is coalesced into a single UDP datagram is separate and complete.  The receiver of coalesced QUIC packets MUST

The algorithms in QUIC-RECOVERY are expected to be resilient to receivers that do not follow guidance offered above.  However, an <del> implementer should only deviate from these requirements after careful consideration of the performance implications of doing so. </del> <ins> 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. </ins> An endpoint that is only sending ACK frames will not receive acknowledgments from its peer unless those acknowledgements are

frame to become too large.  A receiver can discard unacknowledged ACK Ranges to limit ACK frame size, at the cost of increased retransmissions from the sender.  This is necessary if an ACK frame <del> would be too large to fit in a packet, however receivers MAY also limit ACK frame size further to preserve space for other frames. </del> <ins> would be too large to fit in a packet.  Receivers MAY also limit ACK frame size further to preserve space for other frames or to limit the capacity that acknowledgments consume. </ins> A receiver MUST retain an ACK Range unless it can ensure that it will not subsequently accept packets with numbers in that range.

bundle a PING or other small ack-eliciting frame occasionally, such as once per round trip, to elicit an ACK from the peer. <del> A receiver MUST NOT bundle an ack-eliciting frame with all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </del> <ins> A receiver MUST NOT bundle an ack-eliciting frame with packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements. </ins> 13.2.6.

QUIC acknowledgements are irrevocable.  Once acknowledged, a packet remains acknowledged, even if it does not appear in a future ACK <del> frame.  This is unlike TCP SACKs (RFC2018). </del> <ins> frame.  This is unlike reneging for TCP SACKs (RFC2018). </ins> Packets from different packet number spaces can be identified using the same numeric value.  An acknowledgment for a packet needs to

Extensions that modify or replace core protocol functionality (including frame types) will be difficult to combine with other <del> extensions which modify or replace the same functionality unless the </del> <ins> extensions that modify or replace the same functionality unless the </ins> behavior of the combination is explicitly defined.  Such extensions SHOULD define their interaction with previously-defined extensions modifying the same protocol components.

An endpoint detected an error with protocol compliance that was not covered by more specific error codes. <del> A server received a Retry Token in a client Initial that is invalid. </del> <ins> A server received a client Initial that contained an invalid Token field. </ins> The application or application protocol caused the connection to be closed.