Re: Last Call: <draft-housley-two-maturity-levels-06.txt> (Reducing the Standards Track to Two Maturity Levels) to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]