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

[Dave Cridland <[e-mail]>]

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:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade