That's why I think we need a different set of labels, e.g.
Protocol-Quality. We need a statement about the perceived quality of the protocol described in the document. (Is this protocol well-designed for the anticipated use cases, or does it have significant flaws (including security flaws)?)
Applicability. We need a statement about the current applicability of the protocol described in the document. (Is this protocol recommended for general use, not recommended except in specific corner cases, not recommended at all, or strongly discouraged?)
Document-Quality. We need a statement about the perceived quality of the document itself and whether the protocol description seems to be sufficiently precise to permit implementations to interoperate. (along with a pointer to errata.)
Maturity. We need a statement about the amount of actual implementation and deployment experience that the protocol enjoys.
Completeness. We need a statement about how accurately the document reflects what is currently believed to be good practice for implementation/use of that protocol, or whether effective implementation requires information not included or referenced in the document. (e.g. effective implementation of SMTP generally requires some expertise in dealing with heavy loads caused by spam, looping, and denial-of-service attacks which aren't really dealt with in any of the relevant RFCs).
Last-Review-Date. Date of the last review of these labels for this document.
These would go alongside the existing Updates and Obsoletes labels. An Applicability-Statement could also be included.