Original text:
widely deploying a congestion control algorithm over the Internet, but the examples of Cubic and BBR teach us that deployment of new algorithms is not in fact gated by publication of the algorithm as an <del> RFC.  Nevertheless, guidelines are important, if only to remind potential inventors and developers of the multiple facets of the congestion control problem. </del>  The evaluation guidelines in this document are intended to be consistent with the congestion control principles from RFC2914 of

Reviewer comments:
(Contributing text as an individual, chair hat off) Here's some initial proposed text based to Please feel free to tweak my proposal.
Very nice. Looks good to me. Thanks for this!
The Introduction correctly points out the following: The above text says guidelines for specifications are important, but such guidelines only make sense if there is a specification in the first place. So I wonder if it's worth saying a few words here about why it's useful to specify/standardize congestion control algorithms. A few thoughts on the benefits of specifying congestion control algorithms: Help get a shared understanding between implementers, operators, and other interested parties of how the algorithm works and how it is expected to behave (or explicit discussion of parameters and such which can lead to differences in behavior) As a result of the shared understanding: Make it easier for anyone, not just the initial proponents or main implementers, to point out current issues/limitations or suggest improvements of a spec that is still in development, and make it easier to converge such changes to a consensus behavior There may be more benefits. Though I wonder how to best capture the nuance of "Some documentation or artifacts are better than nothing, but an actual spec is better than just a snapshot for documentation or artifacts". Do people think it'll be useful to add something along these lines to the document?
I agree it would be great to add this to the doc, and agree that those two bullet points would be good to integrate. Another more specific benefit that may make sense to add: due to the constraints of open source licenses, some implementors have noted that in some cases they are unable to read open source reference implementations; in such cases it is important to have a detailed spec of the algorithm that is unencumbered by open source license constraints.
I can see this would be of value to someone considering submitting a proposal. It also may help them to justify the effort in writing this down. If we can find words that work, I'd like to consider adding something on this.
Guidelines on what to consider are good for anyone (those who design, those who implement and those who document). The only place where guidelines could be used for enforcing something is where people wish to have congestion control algorithms published through the IETF. But that doesn't make them useless in other parts of the process. (My friend who does CC for realtime media is developing his work through iterations of code, not iterations of documentation. Guidelines would still be useful for him.)

Revised text:
widely deploying a congestion control algorithm over the Internet, but the examples of Cubic and BBR teach us that deployment of new algorithms is not in fact gated by publication of the algorithm as an  <ins> RFC. Nevertheless, specifying congestion control algorithms has a number of advantages: A specification can help implementers, operators, and other interested parties to develop a shared understanding of how the algorithm works and how it is expected to behave in various different scenarios or configurations. A specification can help potential contributors understand the algorithm, which can make it easier for them to suggest improvements and/or identify limitations.  Further, the specification can help multiple contributors align on a consensus change to the algorithm. A specification that is accessible to anyone circumvents the issue that some implementors may be unable to read open source reference implementations due to the constraints of some open source licenses. Beyond helping develop specific algorithm proposals, guidelines can also serve as a reminder to potential inventors and developers of the multiple facets of the congestion control problem. </ins> The evaluation guidelines in this document are intended to be consistent with the congestion control principles from RFC2914 of