Standards Classification and Reality Problem Statement

[Fred Baker]

At 08:35 AM 12/16/2002 -0800, James Kempf wrote:
> > At 02:45 PM 12/13/2002 -0800, James Kempf wrote:
> > >The issue here isn't the perception
> > >that Informational documents are Standards, but rather that a WG ID will
> > >inevitably become the standard, without substantial modification in any
> > >form of
> > >its basic design and contents.
> >
> > Is this a matter of frustration/concern? I thought that the reason we met
> > in working groups was to develop consensus documents that would support
> > interoperable implementation, which is to say "to become the standard".
> >
> > If that's not the expectation, what in the world are we spending all this
> > time and aggravation trying to do?
> >
> >
>
>Let's back up a little.
>
>The original issue was the relevance of the current PS/DS/S 
>classifications. Someone noted that there are very few DSs and even fewer 
>Ss. Why? And what relevance do these classifications have for the needs of 
>IETF's customers today, as opposed to when they were originally proposed?

Well, before we back up, please note that I was replying to your exact 
comment. The reason we work on WG IDs is to create the standard which we 
will all implement. If that is not intended to become a standard, we have a 
very fundamental problem.

>What I was trying to point out is that WG ID has taken on much the same 
>function as PS when it was originally proposed.

I disagree. To name one case, RFC 1246 reports that prior to the 
publication of OSPF V2 (RFC 1247), there were five proven interoperable (at 
three different interoperability testing events) implementations, one of 
which (UMd) had been ported to some twenty-three companies, which were 
involved in the test although they chose not to publish their names due to 
market issues. It reports that OSPF V2 was in operational deployment in a 
variety of ISP and Enterprise networks, some of which it goes on to detail. 
In the Apps area, I am told, people don't deploy until they see a Draft 
Standard, and for MIBs one generally doesn't deploy before Proposed 
Standard, but it is and always has been pretty common to at least have 
trial implementations of Internet Drafts in the other areas. I, personally, 
would support a move to deny Proposed Standard status to a protocol that 
didn't have at least one trial implementation.

Proposed Standard was never the place where one played with a protocol; it 
was where the specification was frozen and one could do initial trial 
deployments.

>Once a document becomes a WG ID, there is
>little or no change in the basic design, it is essentially impossible to 
>get it
>removed, and for all intents and purposes it has become a de facto standard,
>regardless of what the template text says and regardless of what the IETF 
>rules
>are.

Goodness, I wish someone had told me that. Do you know how many documents I 
have pitched and completely rewritten after they became a WG ID? This new 
news should simplify my life immensely. What working groups is this the 
state in? It is not the case in any that I am working in...

>There is no requirement for interoperability when something becomes PS. 
>And very
>few standards become DS. So we are left without any formal requirement for
>interoperability when making something a standard by the criteria that 
>most IETF
>customers believe that it should be.
>
>The overall problem is that the world has changed since the original
>classifications were done, and, at the risk of once again getting told 
>that this
>is a problem statement list and not for solutions,  I think we ought to
>recognize the role that a WG ID has as, in effect, a de facto standard, and
>require interoperable implementations for PS. Whether we keep DS and S is
>unimportant, but we need to recognize reality.

Personally, I have never been convinced of the utility of the "Full 
Standard" step; it has always looked like a fair counterpart to the "Draft 
Proposal"/"Draft Standard"/"International Standard" process, in which BTW 
nobody implements before the DS step and few before the IS step. I'm glad 
we implement earlier and call it a trial implementation.

We need to be able to freeze a document so that people can build 
implementations and networks can buy implementations that at least *claim* 
to be implementations of the same thing, which is my understanding of PS, 
and we need to be able to say "this document actually has demonstrated 
interoperable implementability".

The question I have had working group participants ask is "so, if I go 
through the extra effort to get a document to DS, will I make more money or 
will it be more marketable?" I don't have a good answer to that; yes, I 
believe that the protocol will have been proven to be of better quality, 
and this will help, but I'm not a market-droid, and I don't have the actual 
numbers to show it.

I do believe that there is a place for a "good enough" status, one that 
says "gee, it sure seems to work in practice and nobody seems to want it 
changed". That is different than DS as currently described (unused features 
removed, big testing effort, etc), but as you note is essentially reality.

Maybe (warning: potential solution coming up, if you only want to talk 
about problems this is a rathole) what we need is a process by which 
someone can document the present utility of a protocol, the features that 
folks are using interoperably successfully, the features that people seem 
to not be using or using in a non-interoperable fashion, and so on, and let 
that be the vehicle for the "good enough" status.