Two document stages: Proposed and Full

[Brian E Carpenter]

Having documents sitting at PS that either need revision or
need to become Historic is certainly a problem. My view is that
by having a high barrier to going "up" from PS causes most
authors to simply not bother about this problem. (That is 
certainly true of myself, so I am guilty of some sleeping
PS's.)

   Brian

Marcus Brunner wrote:
> 
> Brian,
> 
> If we accept that the core value is ".. and running code" the document and
> how it is written does not really matter. Peer review is naturally very
> useful for the final spec, but do we need it before we have implementation
> experience? The problem is the crap sitting in PS and being happy with
> this. (Which from a marketing perspective is enough, getting and market
> products with RFC numbers)
> 
> Marcus
> 
> --On Mittwoch, 11. Juni 2003 11:07 +0200 Brian E Carpenter
> <brian at hursley.ibm.com> wrote:
> 
> > Problem related comment:
> >
> > We have ample evidence that WGs don't consistently produce
> > documents that meet even today's criteria for PS. I am strongly
> > against giving WGs the ability to approve PSs without enforced peer
> > review that is specifically independent of the WG and specifically
> > consider IETF-wide and Internet-wide issues. This proposal would
> > only make the problem worse than today, by allowing WGs to ignore
> > peer review.
> >
> >     Brian
> >
> > "Charles E. Perkins" wrote:
> >>
> >> Hello folks,
> >>
> >> I think this has been suggested before.  I'd like to
> >> suggest it again.  Maybe we can get some mileage out of
> >> having two stages of standardization:
> >>
> >> Proposed Standard: requires working group approval.  IESG comments
> >>         taken into account, but full IESG approval not needed before
> >>         publication.  Interoperability testing completed, no known
> >>         flaws that present danger to the Internet.  Component protocols
> >>         are O.K., as long as applicability (usefulness) is documented.
> >>
> >> Full Standard: Full IESG approval required, according to current
> >>         procedures.  Component protocols published as part of
> >>         document suites, or separately, according to IESG discretion.
> >>
> >> Since the IESG still controls charters and chair selection, one may
> >> presume that generally sensible people will be involved.  In this
> >> model, for instance, a working group might publish a component
> >> protocol, and another working group with more relevant expertise
> >> might publish another associated component protocol that could fit
> >> together into a larger system.
> >>
> >> Maybe this is too much "solution space" -- if so, I'll try to
> >> bring it up whenever I can find that forum.  It's gotta be
> >> around here somewhere.
> >>
> >> Regards,
> >> Charlie P.