Two document stages: Proposed and Full

[Marcus Brunner]

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.