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