On Thu May 5 23:47:50 2011, Dave CROCKER wrote:
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.
That's part of the story. It's not a complete observation, though.
We have a standards process that is four stage, not three, and a
first step should be to document what we're doing. That's how we work
- we document running code.
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.
No. The minimum is that we should be embarrassed about the cruft.
It is a trivial observation that we do not follow RFC 2026, and we
should ensure that we have a standards process we actually follow.
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.
More predictable is good. Easier? I'm not sure.
But the real problem I have is the phrase hidden away in the above -
"Whatever happens with the practise of getting to Proposed". You're
not seriously intending to put forward another document which
"defines" our standards process yet not expecting anyone to follow
it, are you?
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]
I'll go along with this one.
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.
This one is hysterically funny.
To quote from draft-bradner-ietf-stds-trk-00 (paraphrasing newtrk).
4/ there seems to be a reinforcing feedback loop involved: vendors
implement and deploy PS documents so the IESG tries to make the
PS
documents better
This is the core issue, which far from addressing, the proposal tries
to discard the feedback loop, stick its fingers in its ears, and sing
la-la-la-I'm-not-listening.
The fact remains that vendors treat PS maturity RFCs as "standards".
By reverting to the letter of RFC 2026, this will undoubtedly
increase confusion - indeed, it's apparent that much of the deviation
from RFC 2026 has been related to this very confusion.
Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf