Change:
7. <del> This document specifies a congestion controller for QUIC similar to TCP NewReno (RFC6582). </del> <ins> This document specifies a sender-side congestion controller for QUIC similar to TCP NewReno (RFC6582). </ins> The signals QUIC provides for congestion control are generic and are <del> designed to support different algorithms.  Endpoints can unilaterally choose a different algorithm to use, such as Cubic (RFC8312). </del> <ins> designed to support different sender-side algorithms.  A sender can unilaterally choose a different algorithm to use, such as Cubic (RFC8312). </ins> <del> If an endpoint uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion </del> <ins> If a sender uses a different controller than that specified in this document, the chosen controller MUST conform to the congestion </ins> control guidelines specified in Section 3.1 of RFC8085. Similar to TCP, packets containing only ACK frames do not count

Discussion:
Addresses .
This issue will list a number of minor editorial things that should be checked and likely addressed with some editorial fixes: Section 5.3: "These delays are computed using the ACK Delay field of the ACK frame as described in Section 19.3 of [QUIC-TRANSPORT]." This text implies that the computation of the delay is described in Section 19.3 of QUIC-TRANSPORT. However, I don't think it is described the calculation, only the definition of the field. Please reformulate to imply only field definition not calculation. Section 5.3: "On the first RTT sample for the network path, that sample is used as rttsample. This ensures that the first measurement erases the history of any persisted or default values." I think this intended to cover cases where path changes are detected. But it is not well expressed. Does this need a reformulation and a reference into QUIC-TRANSPORT where it states when such a reset should occur? Section 6.1: "Either its packet number is kPacketThreshold smaller than an acknowledged packet" Nitpicking, assuming no PN gaps in transmission. Does that need a note? Section 6.2.4: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram or transmit data from multiple packet number spaces." This last part, I assume intended to generate additional datagrams to prevent single loss to impact. However, due to coalescing this is unclear in this context. Section 7: "Endpoints can unilaterally choose a different algorithm to use, such as Cubic ([RFC8312])." I think this sentence should be explicit that in needs to be sender-based algorithms. I think we need to have the requirement on performing congestion control on the sender unless there has been explicit agreement with the receiver that they will do it. Section 7.2: "Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (maxdatagramsize), limited to the larger of 14720 bytes or twice the maximum datagram size." "maximum datagram size" is not used in Transport there need to be alignment here of what name to use.

Transport has Maximum Packet Size, which appears to match the definition in the appendix of maxdatagram_size.
Thanks for your careful review, NAME -- these are good finds! I've addressed your comments below and in . I'll address point 6 in a separate PR. Section 19.3 has the following text, which does tell how to compute acknowledgement delay from the ACK Delay field: I've replaced "computed" with "decoded" in the recovery document to make it clearer. Coalescing applies to packets, not to datagrams. We've explicitly stated that a sender could send 2 datagrams to avoid any effects of coalescing. I think the text is pretty clear on this: "An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets". I've added "sender-side" to make the controller more explicit. To your point about making this a sender requirement, that is covered in the transport doc (end of ):
Based on and , labeling this as "editorial"
I think these issues are resolved once the two PRs are completely ready.
In Section 5.3: "When there are no samples for a network path, and on the first RTT sample for the network path: smoothedrtt = rttsample rttvar = rttsample / 2 Before any RTT samples are available, the initial RTT is used as rttsample. On the first RTT sample for the network path, that sample is used as rttsample. This ensures that the first measurement erases the history of any persisted or default values." First of all this text uses "rttsample" while other places with the exception of the pseudo code uses latestrtt variable. There are two issues with that. First that the value of rttsample is state dependent. If there exist an latestrtt then that is used, if not the initial rtt. As the initial RTT is defined in Section 6.2.2 I think a forward reference is in place. Finally, should this calculation in cases where latestrtt exists be using minackdelay?
I like to add that there are some structural issues in Section 6.2.1 and 6.2.2 where the initial value depends on both section.
Based on , labeling this as "editorial"
The PR resolves this issue.

OK, thanks GitHub for saving and duplicating my comments...Looks good and appear to resolve the uncertainties I had.