|
Speaking for myself only, I believe that this proposal does attempt to address some issues relating to advancement, so that it is not entirely "window dressing". For example, I believe that the changes with respect to "down references" (Section 4) and "annual review" (Section 3) are constructive, and long overdue. Implementation reports are a more difficult topic since they constitute both an obstacle to advancement as well as an important step on the road to development of interoperable standards. In particular, the development of implementation reports, while cumbersome, provides objective evidence of progress. It is difficult to simultaneously lower the barriers to advancement while keeping most of the value (and objectivity) that implementation reports provide. I am not sure that the document currently has this balance quite right. Section 2.2 states: Note that the distinct requirement from RFC 2026 [1] for reports of interoperability testing among two or more independent implementations is intentionally subsumed by the requirement for actual deployment and use of independent and interoperable implementations. The Last Call is intended to identify unused portions of the specification that greatly increase implementation complexity without burdensome implementation testing and documentation. Today it is quite common within WGs to see conflicting claims about protocol implementations and interoperability. IMHO one of the critical purposes served by implementation reports is to require proponents to "produce the evidence" backing their claims. The above paragraph left me wondering what the "burden of proof" would be in practice. For example, I would not want to see the IESG put in the position of adjudicating "he said, she said" arguments made during Last Call. As a result, I cannot endorse the approval of this ID as it exists today, but could see it being changed to address these concerns. > To: ietf@xxxxxxxx > Subject: Re: Last Call: <draft-housley-two-maturity-levels-06.txt> (Reducing the Standards Track to Two Maturity Levels) to BCP > Date: Thu, 5 May 2011 14:33:51 -0400 > From: sob@xxxxxxxxxxx > CC: iesg@xxxxxxxx > > As I have stated before, I do not think that this proposal will achieve > anything useful since it will not change anything related to the > underlying causes of few Proposed Standards advancing on the standards > track. I see it as window dressing and, thus, a diversion from the > technical work the IETF should focus on. > > If it were up to me, I would not approve this ID for publication as a > RFC (of any type) > > Scott > |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf