Code change:
Sec 2 leans heavy on the dated example of Highspeed TCP and drives pretty much everything to Experimental "until such time that the community better understands the solution space." It says that experimental RFCs can either be those judged to be safe on the internet, or those intended for testbeds. At this point, we probably understand enough to allow proposals to go for Proposed Standard. The safe/testbed distinction also doesn't make sense -- we might want to standardize CCs for controlled environments, like DCTCP. This needs a complete rewrite. It wouldn't hurt for that rewrite to also note that the IRTF is another venue, non-normatively.
I think a rewrite would help, but I'm think that could be too radical - we still do have proposals that ought ton be EXP either until deployment experience; or until we can agree they are "safe" for more general use. That doesn't seem to be a problem to me, but we ought to allow PS also. I agree we ought to mention IRTF.

Related discussion:
text: 2. <del> Following the lead of HighSpeed TCP RFC3649, alternate congestion control algorithms are expected to be published as "Experimental" RFCs, until such time that the community better understands the solution space.  Traditionally, the meaning of "Experimental" status has varied in its use and interpretation. As part of this document we define two classes of congestion control proposals that can be published with the "Experimental" status.  The first class includes algorithms that are judged to be safe to deploy for best-effort traffic in the global Internet and further investigated in that environment.  The second class includes algorithms that, while promising, are not yet deemed safe enough for widespread deployment as best-effort traffic on the Internet, but are being specified to facilitate investigations in simulation, testbeds, or controlled environments.  The second class can also include algorithms where the IETF does not yet have sufficient understanding to decide whether the algorithm is or is not safe for deployment on the Internet. Each alternate congestion control algorithm published is required to include a statement in the abstract indicating whether or not the proposal is considered safe for use on the Internet.  Each alternate congestion control algorithm published is also required to include a statement in the abstract describing environments where the protocol is not recommended for deployment.  There can be environments where the protocol is deemed _safe_ for use, but it is still is not _recommended_ for use because it does not perform well for the user. </del> <ins> This document applies to congestion controllers that seek Experimental or Standards Track status.  Evaluation of both cases involves the same questions, but with different expectations for both the answers and the degree of certainty it the answers. Congestion controllers without experience of internet-scale deployment SHOULD seek Experimental status until real-world data is able to answer the questions in general-use.  Congestion controllers with a record of measured internet- scale deployment MAY directly seek the standards track if the community believes it is safe, and the design is stable, guided by the considerations in general-use. The existence of this data does not waive the other considerations in this document. Algorithms that are designed for special environments (e.g., data centers) and forbidden from use in the general internet would, of course, seek real-world data for those environments instead. Experimental specifications SHOULD NOT be deployed as a default. They SHOULD only be deployed in situations where they are being actively measured, and where it is possible to deactivate if there are signs of pathological behavior. Each alternate congestion controller published is required to include a statement in the abstract indicating whether or not there is IETF consensus that the proposal is considered safe for use on the Internet.  Each alternate congestion controller published is also required to include a statement in the abstract describing environments where the protocol is not recommended for deployment. There can be environments where the controller is deemed _safe_ for use, but it is still is not _recommended_ for use because it does not perform well for the user. </ins> As examples of such statements, RFC3649 specifying HighSpeed TCP includes a statement in the abstract stating that the proposal is