Running code (Was: RFC 2047 and gatewaying)

On 1/7/03 at 7:35 AM -0500, Keith Moore wrote:

> On Mon, 6 Jan 2003 23:31:20 -0600 Pete Resnick 
> <presnick(_at_)qualcomm(_dot_)com> wrote:
>
> > Just to make sure this doesn't get by without comment:
> >
> > On 1/4/03 at 2:06 AM -0500, Leo Bicknell wrote:
> >
> > > Change the RFC, then complain about the program.
> > Sorry, we don't do that in the IETF. The IETF standards process 
> > doesn't make up rules and then make everybody fix their code. In 
> > the IETF, standards simply document the current state of affairs of 
> > interoperable running code.
> I realize I'm taking this out of context, but...
> the criteria for standardization levels are documented in RFC 2026.
> words like "no known technical omissions" are used.  it doesn't say anything
> about standards documenting the state of running code.
2026 does say things about requiring interoperable implementations. 
And let's be very clear about what 2026 actually says: As far as "no 
known technical omissions" goes, 2026 says that this requirement can 
be waived under certain conditions. "Interoperable implementations" 
and "operational experience" (which, of course, don't kick in as 
requirements until Draft Standard) have no exceptions whatsoever 
mentioned in 2026. Moreover, those requirements are *precursors* to 
standardization: You don't get to move along the standards track 
unless in the standard you are documenting actual running code.
> in my experience, trying to document running code is often a good 
> idea, and trying to define a standard is often a good idea, but 
> trying to do both in the same exercise leads to disaster - there is 
> inevitably a conflict between what meets IETF criteria for 
> standardization and what is actually done in running code.  the 
> result is usually that people are tempted to lie about either what 
> the running code does, or worse, to  lie about whether the running 
> code meets standardization criteria.
My experience is that more often, people fudge in the opposite 
direction: They write the standard for the way they *want* the 
running code to be, rather than having the standard represent what 
the actual interoperable implementations are doing.
> > When we work on Proposed Standards where there is no running code, 
> > we sometimes propose ways of doing things and ask people to make 
> > their implementations a certain way, but we don't tell people who 
> > are following a current standard that they are hereafter wrong 
> > without pretty impressive reasons. We do "de facto" standards, not 
> > "de jure" ones.
> it's true that we don't often tell people it's wrong to follow a 
> current standard - at least, not without a good reason, and 
> especially not when it's one of *our* standards.  but our standards 
> are closer to de jure standards than de facto ones.  documenting 
> running code is NOT what we
> do in our standards process, at least, not when we're following our rules.
I disagree. Most other standards bodies create de jure standards: Not 
a lick of code is written before standardization, and no operational 
experience is required for standardization. What we do (in comparison 
to others) is *much* more like de facto standards: We require, as 
part of standardization, interoperability and operational experience.
None of this is meant to say that the what the IETF does is purely 
documentation; certainly we do original work all of the time. But 
what we put in standards track RFCs better be, for the most part, a 
description of running code, not just rules for how we think running 
code should go. The latter are called "Experimental RFCs". They're 
different.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102