Re: draft-housley-two-maturity-levels

The known problem is it takes well over four years to get anything published.

I am experiencing in one never-ending saga the logical conclusion of the logic: 
since Proposed Standard is the new Draft Standard, and since the IESG has to 
make sure any proposal is beyond bullet-proof, the industry has long since 
implemented draft-mumble-21, which has not changed for over a year, and few in 
industry cares if the document publishes as an RFC, because from their point of 
view, if something has been working in the field for three years, has 18 
independent implementations, and has not yet crashed the Internet, it is 
probably ready, whether the IETF formally says so or not. That is the fast 
track to making the IETF irrelevant.

The very real danger here is while that attitude may be OK for a small media 
application, that attitude could be a disaster in, for example, the routing 
area. Something really has to be done.

Now, I do agree with Scott here there is absolutely no incentive for anyone to 
bring a protocol to Draft/Internet Standard level.

What I *am* hoping is that with two, clearly defined maturity levels, we can go 
back to publishing Proposed Standards in about a year, and have Internet 
Standard mean something. Otherwise, we will be perpetually running the Internet 
on Internet Drafts, which is something I do not think anyone really can say is 
a good thing.

On Oct 25, 2010, at 10:48 PM, Scott O. Bradner wrote:

> > I'd like to hear from the community about pushing forward with this
> > proposal or dropping it
> I do not think this proposal fixes any known problems
>
> the major reason (imo) that technology is not advanced along the
> standards track is because there is no need to do so.  
>
> someone labors for a while to get a proposed standard published and
> people start to use it (if they did not start at the Internet Draft stage)
> soon about anyone that has a need for the technology has implemented it and 
> it is being used by customers all over the globe
>
> just what is the reason that someone would take time from working on new 
> technology to do the work to advance the proposed standard?  it is unlikely 
> that all that many more people will implement or use the technology
> so what is the point?
>
> in addition, the IESG acts as if the proposed standard will be the last step
> in the publication process (or at least reviews IDs as if this were the case)
> so we have all the benefits of the cross area review (this making the 
> proposed standards 
> about as good as one could without requiring interoperable implementations at 
> the
> first stage (i.e. bringing back running code))
>
> so I say drop it and live with the fact that rfc 2026 does not paint an 
> accurate
> picture of the current one step standard process
>
> Scott
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf