These days, for a protocol specification to be of "reasonable use" on a wide scale it needs to avoid causing harm.
First, something can be of reasonable use while still causing harm. Fossil based fuels prove that. And while I agree that there are certain areas where causing harm to others needs to be considered (such as UDP-based protocols that lack well known congestion avoidance algorithms), we as a community cannot be so risk averse that we drive development elsewhere.
Consider the case where someone *DID* invent a UDP-based file transfer protocol (FSP). The work was done completely outside the IETF and satisfied a demand. When that demand subsided use of that protocol diminished. And yet does not have a specification for this Historic protocol.
Similarly, SOCKS went quite far before the IETF ever got a look at it. Why? Because we are no longer viewed as a place where development can seriously take place. Risk averse. You know that thing about running code? Taken too far we fail what I think part of our mission is, which is to be a place to collaborate, because everyone will have shown up with their respective running code, only to fight over whose running code (if anybody's) will become the standard. See, for instance, the XMPP/IMPP wars.
There have been too many exploits of security holes and privacy holes in poorly-designed protocols. While it might be useful to publish an informational specification of a widely-deployed protocol on the theory that publishing it will make the public more aware of its limitations and help them migrate to better protocols, publishing a specification of a hazardous protocol that is not widely deployed can encourage wider deployment and increase the risk of harm.
Keith is trying to raise the bar. I prefer to keep the bar low. I, frankly, don't see a problem with there being more
crap published as RFCs, whether produced by WGs or produced by individuals.
Publishing crap dilutes the value of the RFC series, and makes it more difficult for the public to recognize the good work that IETF does. It also costs money which could be better put to other uses.
This was never the series' intent. We've attempted to warp it into this, and the result has been The Official Dogma, with a corresponding lack of development within the IETF. If we want to allow for REAL innovation WITHIN the IETF, then you have to let some crap through, and you have to trust the RFC Editor and others to hold the bar at some level.
Eliot