Standards

[Keith Moore]

> The entire perfection/refinement phase is happening during
> the PS publication process, before we have actually determined
> that the potential standard has been implemented and found
> to be useful in practice.  In some cases, this is a big waste
> of time, because we expend a lot of effort to "perfect"
> something that never gets used. 

Yes these cases do exist.  But there are also numerous cases where vendors
ship product prior to approval of the document as PS, even though there are
known bugs in the specification.  Often this has been used to pressure
the WG and/or IESG to accept the document as written, bugs and all.

> It would be much healthier and more effective to use a
> lighter weight process for initial publication, and to
> refine and perfect standards _after_ we have the initial
> implementation and deployment experience.

I'd certainly like to encourage prototyping and interop testing earlier in the
process.  However, I haven't figured out how to do this without creating
conditions which encourage even more premature shipping of product.  Maybe
something like the IDN trick, where fundamental protocol parameters are
determined by IANA at the last minute, could be used.

Another way to make the initial publication happen more quickly or easily
might to identify the things that tend to hold up documents at late stages,
and insist that they be dealt with earlier.  For instance, failure to consider
security in protocol design has held up dozens of documents.  (I'll note that
the recently-approved IAB on security considerations is titled "Guidelines for
Writing RFC Text on Security Considerations" not "How to Consider Security in
Protocol Design", which I think is a good illustration of the problem.)
Failure to get early review and feedback from parties external to a working
group that are affected by the group's choices, has held up many more.

Keith