OPEN ISSUE: Standards Track

[Spencer Dawkins]

Dear Pekka,

My read of the Draft Standard concept was to say "we now have
two distinct interoperable implementations, so the specs must be
readable, but we haven't seen large-scale interoperation yet, because
we haven't seen large-scale deployment yet. Come back in a short
period of time, when we have large-scale deployment, and we'll
tell you if we killed the Internet".

Your note points up a problem we all know about but we haven't
written down in the Problem Statement draft - reduced genetic
diversity also means that the distinction between Draft Standard and
Standard may mean less than previously. I'm thinking of cases like

- OSPF
- HTTP
- closed-system IM, where the same people provide clients and servers

as examples where there may not be a lot of additional impact on the
Internet
after one or two implementations are deployed  :-{ ... because some large
percentage of the affected systems already run that code.

And if these examples aren't the right ones, I bet you can think of a couple
more!

Spencer

----- Original Message -----
From: "Pekka Savola" <pekkas at netcore.fi>
To: "Spencer Dawkins" <spencer at mcsr-labs.org>
Cc: <problem-statement at alvestrand.no>
Sent: Tuesday, May 20, 2003 7:04 AM
Subject: Re: OPEN ISSUE: Standards Track


> On Tue, 20 May 2003, Spencer Dawkins wrote:
> > (1) agree that moving from PS to full Standard is more
> > likely interesting than moving from PS to Draft Standard,
>
> Moving from PS to Draft typically seems to include a lot of tuning of the
> spec, including removal of features and adding a few new ones (to
> replace/enhance/augment the ones killed for instance), or clarifying ones
> (in such a manner that all the old implementation are not compliant).
>
> If we went from PS to Full, the documents certainly would have to recycled
> at the PS stage far, far longer to ensure there are no glitches left.  In
> addition, requiring more than 2 interop implementations of each feature
> should be required if we're to call something a Standard (unless we
> redefined the way it is, and engrave the "good old standards" in a
> golden plaque).
>
> > (2) agree that Draft Standard does NOT seem like a more
> > impressive name than PS to anyone outside IETF (and
> > it's been a while since someone has been confused about
> > the difference between "draft standard" and "internet draft
> > on the standards track" in my presence, but it has happened).
>
> True.
>
> > ----- Original Message -----
> > From: "Brian E Carpenter" <brian at hursley.ibm.com>
> > Cc: <problem-statement at alvestrand.no>
> > Sent: Sunday, May 18, 2003 9:53 AM
> > Subject: Re: OPEN ISSUE: Standards Track
> >
> >
> > > Eric Rosen wrote:
> > > >
> > > > Brian> Secondly, this is a case where I think a simple first step
may
> > > > Brian> help quite a bit: simply merge Draft Standard and Standard
> > > > Brian> into a single class, called Standard,  but with the criteria
> > > > Brian> now used for Draft Standard.
> > > >
> > > > Brian> Arguments: remove a process step that we basically never use,
> > > > Brian> and make the step up from Proposed Standard worth the
trouble.
> > > >
> > > > Could you explain how this makes the step up from PS worth the
trouble?
> > >
> > > Because you know that the effort of documenting the interoperable
> > > implementations will be rewarded by immediately getting to the final
> > > status, rather than just getting to an intermediate plateau (and one
with
> > > a very confusing name, since to outsiders it sounds like a step
> > backwards).
> > >
> > >   Brian
> > >
> >
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>