Standards

[John C Klensin]

Margaret,

I think you note explains what I was trying to say, but you 
explained it much better than I did.

We are in complete agreement.
thanks,
   john

--On Wednesday, 19 February, 2003 09:30 -0500 Margaret Wasserman 
<mrw at windriver.com> wrote:

> Another thought on this point...
>
> If it were easier to get documents to PS faster, we might
> actually be able to improve them on the road to DS.  Right
> now, it can be very difficult to get a WG to change a
> document between PS and DS (based on implementation experience,
> etc.) because it has usually been several years before the
> document reaches this point, and there may be many, widely
> deployed implementations that have the force of law in the
> market.
>
> What we need is a way to:
>
>          (1) Quickly create a stable document for a potentially
>                  useful standard (this is what PS should be).
>          (2) Refine that standard based on early implementation
>                  and deployment experience (While it is still
>                  early in the implementation and deployment!)
>                  into a mature standard that is ready to be
>                  widely deployed (DS).
>          (3) Acknowledge that a standard is working well in
>                  wide-scale deployment (FS or STD).
>
> By creating a higher hurdle for the first step (PS) we are
> actually breaking the whole process...
>
> 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.  In other cases, it is even
> more damaging, because we diddle endlessly with a useful
> standard, driving up the costs of its initial implementation
> and deployment, and creating resistance to later changes.
>
> 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.
>
> At this point, though, the current terminology has acquired
> a great deal of baggage.  So, it might be necessary to
> re-name the phases in order to change their meaning.
>
> Margaret