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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf