I agree with much of this discussion but I have come to a very different perspective:
* Internet Standard status means nothing more than the fact that the legacy deployment is sufficiently large that further development of the specification is no longer feasible.
* Internet Standard status is not necessarily a desirable condition.
* Internet Standard status will be reached regardless of whether the documents are good or not.
One of the sad parts of the development of the Web is that HTTP became a standard in early 1993. By the time we had a team able to start getting the protocols into shape, legacy deployment was already constraining development. If people recall, Simon Spero proposed an HTTP-NG that is remarkably close to QUIC given that over twenty years separate them. We couldn't deploy because there was too much legacy.
We need to stop being so dogmatic about IETF process. It is not like it is working for us now or has worked well in the past. I propose a different approach
1) Keep the two standards process levels but drop the notion that Internet Standard means the work is finished and will never change. Specifications that are being used by real people will always need some level of maintenance. Maybe not a great deal but some. Add an additional status LEGACY to describe the specs that are in widespread use, have been superseded but are not going to go away for decades if ever. IPv4 would be a good candidate for LEGACY as it will always be with us just as the 6502 microprocessor will always be with us in standard cell. Even if that is after 0.0.0.0/0 has been declared (reserved for private use).
2) Recognize the fact that HTTP/1.1, TLS/1.2, PKIX etc are now Internet Standards. They may not be perfect, the implementations may not be fully interoperable but anyone who wants to make a Web browser (for example) is going to have to support those specs for a considerable time to come. Declaring TLS/1.2 an Internet Standard does not mean ending development of TLS/1.3, it is merely recognizing the situation.
3) Establish a maintenance WG in each area that is the place for continuing incremental development of standards. The Security area has LAMPS. I think that instead of the 'do the work, shut the WG' model applying to every WG in IETF, the maintenance groups should act as standing committees for very limited updates.
I fully sympathize with John Klensin's point about making changes to a spec after deployment. One of the reasons I have not been looking to get people using the Mesh until now is that I knew that the minute I started attracting users, that would eliminate my scope to make fundamental changes.
