Original text:
should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise. <del> 6. </del>  This document has no IANA actions.

Reviewer comments:
I resisted the urge to resolve other issues with this, so there are a bunch of TODOs in the text. Most of the big blocks of text are moved from elsewhere in the document.
The guidelines overlap in odd ways. The first one is essentially TCP-friendliness, and I guess it's implied to be talking about "normal" wired networks. Then different guidelines say the algorithm should be evaluated with all sorts of environments and/or link parameters, presumably for friendliness. Then, in "Minimum Requirements" some of these are listed as mandatory to satisfy, and the rest as something the submitter has to report on, but the community may decide to accept even if it's bad. There are several different concepts that are being muddled here. Alternatively, we can structure it as follows: (A) Metrics to evaluate Does the new algorithm match its share of the existing bottleneck bandwith better than existing algorithms? (not underutilizing, not bufferbloating or congestion collapsing) in isolation or with multiple flows? Are flows using widely deployed algorithms not severely degraded by the introduction of the new algorithm? Is there a plausible incremental deployment plan? Something about short flows? (B) Mandatory Domains: must answer positively to (A) Wired networks, "normal" range of BDPs Wireless networks, "normal" range of BDPs (loss & jitter) Internet-scale deployment is sufficient for this? (C) Optional Domains: must evaluate (A) & report IoT Satellite Misbehaving nodes Response to sudden & transient events Tunnels for explicit-signal protocols Extreme packet reordering
I agree we need to restructure, I like the idea of A. I think defining heterogeneity in B is likely helpful - although we really ought to stop using "bandwidth" when we mean "capacity" - because it really confuses SDOs that actually do cap[acity v bandwidth tradeoffs:-) I'll fight that Internet-Scale deployment is sufficient;-). That plays to the big operators, and I do not like that. It worries me quite a lot that we target "normal BDPs" - that's not something I would welcome. It places all satellite outside normal, which again, I don't like - some satellite is definitely odd, but I'd really like to see broadband services as "normal", if nothing else, to include those people who can only use this technology. So, main question first: can we factor the last section as different in a particular perspective, rather than "labelling" networks as optional to support? i.e. XXXX is a property, and IoT is an example, transients and abrupt capacity variation is an example of radio networks; etc.?
I agree that we need a better structure. Including having actual subsections per issue, rather than the current list format. Two points: short flows, and transient events. Short flows are pretty much the norm, with reports of 90% of connections never going out of slow start. There is an associated problem: capacity discovery algorithm like slow start will rapidly increase the amount of data sent on a path, with a high potential for disrupting current users of that path. That's not good. There are potentials solutions such as quickly evaluating the capacity (e.g., packet pair, squirting, variants), remembering past connections (careful resume), or potentially getting input from the network (maybe something like Prague/ECN). These solutions have been explored for "special" links (satellite, deep space), but the problem is not just special links. I would like to see that discussed in the "main" section (A). Transients are also the norm. Congestion control is a form of control algorithm, and control algorithms must absolutely deal with transients. For example, if we deal with wireless, we need to deal with "entering a tunnel" -- and exiting. We may want to deal with . That should belong to the core (A), not the "weird configuration" (C).
Wait to land PRs, then do this with no substantive change, then do other PRs -- this change will be editorially disruptive.
I like the flow after this refactoring!Good to merge, the text here looks good to me. There are still things to think about, but these are probably best down on the basis of the entire document.

Revised text:
should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise.  <ins> 7. </ins> This document has no IANA actions.