Folks,
On 5/5/2011 11:33 AM, Scott O. Bradner wrote:
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.
We currently have a standards process that largely ignores two of its stages.
At the least, our community should be embarrassed about this cruft and should
want to streamline things and make them more likely to be fully exercised.
I happen to be skeptical abut the one motivation offered in the document, that
that the proposed changes will affect how working groups or the IESG handle
criteria for achieving Proposed (modulo the downref change.) There are folks
who have some faith that this change will make it easier to get to Proposed. I
don't understand their logic, but what the heck, it's a substantial constituency
that believes it.
I lobbied with Russ to expand the list of benefits so that the evaluation of the
proposed change would not rely /only/ on that one issue.
I think there is an array of benefits that plausibly can accrue from this change
and that we need not rely on only one:
1. The criteria for the second stage are significantly clarified and rely
exclusively on actual adoption and use (again, modulo some important nuances.)
Whatever happens with the practice of getting to Proposed, this should make it
more predictable and easier to get to (Full) Internet Standard, based solely on
actual success of the specification.
2. The model is cleaned up, in my opinion significantly. This improves
transparency of the process a bit. Also, I think Draft made sense when our
whole endeavor was less mature and we needed to help the community understand
what is needed for achieving interoperable deployments. Today we need the
/practice/ of interop efforts, but we do not need it in the formal process, as
demonstrated by how few specs get to Draft in spite of becoming entirely
successful community services.[1]
3. The changes are likely to remove bits of community confusion about the
IETF standards labels. Not entirely of course, because people are creative.
But the proposed changes make a very clean distinction between the initial
technical work and the later adoption/deployment/use work.
We should be careful not to latch onto a non-normative detail in the doc as the
basis for accepting or rejecting it. What should matter is whether the changes
make sense.
d/
[1] There is an argument that doing the work of getting to Draft makes for
better specs. I have no trouble believing that. Were it widely practiced, we'd
probably have a better Internet. But the fact that there is a majority practice
of staying at Proposed renders the minority practice of diligently qualifying
for Draft irrelevant, IMO.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf