I am opposed to approving this document as BCP. It is trying to solve the wrong problem; or to put it another way, it is trying to solve a relatively minor problem in a way that distracts attention away from more important problems. Approval of this document will exacerbate an already bad situation, and further dilute the value of IETF standardization. 1. I strongly disagree with the stated goal to publish Proposed Standards as soon as rough consensus is achieved. This goal is consistent with the original intended meaning of "proposed standard". But the reality is that the public has long associated "proposed standard" with "suitable for widespread deployment", and is likely to continue to do so no matter how IETF changes its process. Rough consensus is not, and never will be, sufficient to indicate that a standard is suitable for widespread deployment. Instead, I would suggest introducing one or more stages to the process, with clear and unambiguous labels, prior to advancement to Proposed Standard. e.g. "recommended for prototype implementations" or "recommended for isolated interoperability testing" or "recommended for limited deployment only" or "candidate for Proposed Standard". These stages shouldn't require full IESG review or publication as RFCs - merely naming the Internet-Draft (with version number) should be sufficient. There should be clear and simple criteria for these labels, and WG consensus + approval of the responsible AD should be sufficient. There should also be defined mechanisms for reporting defects in these documents, and for responding to defect reports. 2. It is arguable that there is little value added by the current transition from Draft Standard to Full Standard, and that the process is too cumbersome in relation to the value provided to the Internet community. But there is still a need to provide incentives to update standards in light of interoperability problems that are observed in the field, and/or changing conditions on the network. There is still a need to inform the Internet community about the current applicability of old standards. Rather than simply drop the last state transition from the current process, we should be examining how to better tailor the process to meet actual community needs. 3. Six months is not sufficient time between approval of Proposed Standard and approval for the final standards maturity level. 4. The increased requirements that have been imposed in practice for Proposed Standard status exist mostly for valid reasons that benefit the community. It is possible that these are indications of flaws in the original 2026 process, but merely relaxing the requirements without addressing the need for those requirements in other ways, will do great harm to the value of IETF documents and to IETF's ability to benefit the Internet community. I strongly disagree with that provision. 5. I strongly object to the idea that IETF should endorse widespread deployment and use of a Proposed Standard prior to any reports of interoperability testing. 6. I support the removal of requirement for annual review of Proposed and Draft Standards, but I think that other mechanisms are needed to ensure that the community is informed about current document applicability. For example, a document's label as standard or its applicability label could automatically expire if not updated within two years' time. 7. I agree that downward references are a significant cause of delay in document approval, but I disagree with the provision to permit downward references to Proposed Standards if the requirements for Proposed Standards are relaxed from what they currently are in practice. I'd feel better about downward references if the current set of requirements were largely kept intact and more formally codified. 8. I think STD numbers have not been beneficial to the community and should probably be abandoned. Keith _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf