Code change:
at the time 5033 was written, only TCP, DCCP and SCTP were around, using CC; nowadays, many more protocols use CC - with QUIC standing out as a here, probably warranting it's explicit mentioning.
Yes. Note that there is a bit of sadness here, because QUIC was forced to describe use of Reno in RFC 9002, while most deployments use Cubic or BBR. But the WG could not go beyond Reno... because of RFC 5033!
This one seems simple, but is not. The introduction text says: This formulation, "Impact on standard TCP", assumes that the congestion control algorithm is an integral part of the TCP specification. The situation has changed, and I think this part should be rewritten as: The reference here should be RFC9000, the specification of the transport protocol, rather than RFC9002, the specification of default loss recovery and congestion control algorithms. And the text should then be modified to mention that our goal is to not wantonly disrupt existing deployments -- whether they use Reno, Cubic or BBR. The point is "don't disrupt the Internet", not "don't offend the pride of the IETF".
Looks good.

Related discussion:
text: Proposed congestion control mechanisms should include a clear explanation of the deviations from RFC2914. <del> Impact on Standard TCP, SCTP RFC2960, and DCCP RFC4340. </del> <ins> Impact on existing deployments of TCP RFC9293, SCTP RFC9260, DCCP RFC4340, and QUIC RFC9000. </ins> Proposed congestion control mechanisms should be evaluated when <del> competing with standard IETF congestion control RFC2581, RFC2960, RFC4340.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism. We note that this bullet is not a requirement for strict TCP- friendliness as a prerequisite for an alternate congestion control mechanism to advance to Experimental.  As an example, HighSpeed TCP is a congestion control mechanism that is Experimental, but that is not TCP-friendly in all environments.  We also note that this guideline does not constrain the fairness offered for non- best-effort traffic. </del> <ins> competing with standard IETF congestion control RFC5681, RFC9260, RFC4340, RFC9002, RFC9438.  Alternate congestion controllers that have a significantly negative impact on traffic using standard congestion control may be suspect and this aspect should be part of the community's decision making with regards to the suitability of the alternate congestion control mechanism.  The community should also consider other non-standard congestion controls known to be widely deployed, We note that this bullet is not a requirement for strict Reno- or Cubic- friendliness as a prerequisite for an alternate congestion control mechanism to advance to Experimental.  As an example, HighSpeed TCP is a congestion control mechanism that is Experimental, but that is not TCP-friendly in all environments. When a new algorithm is deployed, the existing major deployments need to be considered to avoid severe performance degradation.  We also note that this guideline does not constrain the interaction with non-best-effort traffic. </ins> As an example from an Experimental RFC, fairness with standard TCP is discussed in Sections 4 and 6 of RFC3649 (HighSpeed TCP) and using spare capacity is discussed in Sections 6, 11.1, and 12 of RFC3649. <ins> Wireless links While the early Internet was dominated by wired links, the properties of wireless links have become extremely important to Internet performance.  In particular, congestion controllers should be evaluated in situations where some packet losses are due to radio effects, rather than router queue drops; the link capacity varies over time due to changing link conditions; and media access delays and link-layer retransmission lead to increased jitter in round-trip times.  See RFC3819 and Section 16 of Tools for further discussion of wireless properties. </ins> Difficult Environments. The proposed algorithms should be assessed in difficult <del> environments such as paths containing wireless links. Characteristics of wireless environments are discussed in RFC3819 and in Section 16 of Tools.  Other difficult environments can include those with multipath routing within a connection.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </del> <ins> environments.  We note that there is still much to be desired in terms of the performance of TCP in some of these difficult environments.  For congestion control mechanisms with explicit feedback from routers, difficult environments can include paths with non-IP queues at layer-two, IP tunnels, and the like.  A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments. </ins> While it is impossible to enumerate all the possible "difficult environments", we note that the IETF has previously grappled with