Date: Thu, 16 Oct 1997 11:22:50 -0400
From: "vinton g. cerf" <vcerf@MCI.NET>
To: Dave Crocker <dcrocker@brandenburg.com>,
"David R. Conrad" <davidc@apnic.net>
cc: Ned Freed <Ned.Freed@innosoft.com>, Harald.T.Alvestrand@uninett.no,
Bruce Greenblatt <bgg@sjf.novell.com>, iesg@ietf.org, ietf@ietf.org
Subject: Re: "running code..."
folks,
I have the impression that the processes at ISO and ITU have
also been materially changing with time. In the 1970s and through
most of the 1980s, the "heavy lifting" at those organizations
seemed to be, as Dave says, focused on specifications. In the
last several years, however, I am under the impression that
more concurrent engineering has been going one, informally.
The ISO and ITU don't have implementation built into their
process in quite the explicit way the IETF does, but anecdotal
reports suggest that they've become more pragmatic about
trying things out as they go along.=20
I think we can all agree that the practical aspects of
realizing a spec by working on reference implementations
and testing of independent implementations has been a
superb strategy and one which we can, should and no doubt
will continue to practice.
vint
At 08:46 AM 10/16/97 +0200, Dave Crocker wrote:
>At 12:22 PM, David R. Conrad wrote:
>>.... =A0My impression was that
>>lack of implementation was considered sub-optimal, even for proposed
>>standards and more in line with what OSI protocols were always accused =
of
>>(again, rightly or wrongly). =A0Thus my question.
>
> Well, it's certainly a danger we always need to attend to, and mostly t
=
he
>IETF is pretty good at worrying about it.
>
> The way I relate to the difference between the ITU and ISO processes,
>versus the IETF process is that the end of their process is the beginnin=
g
>of ours. That is, they make a specification a full and final standard a=
t
>about the same point as we put a document onto the standards track for t=
he
>first time. Their approach uses multiple cycles of the standards proces=
s
>to get something that actually works, but each turn of the crank, for th=
em,
>is a new standards process. This leaves them open to adding and revising
>specifications in ways tht lead to having one revision be non-interopera=
ble
>with the previous. (Yes, this does happen.) Our revision rules within =
the
>proposed/draft/full sequence are much more strict.
>
>>In any event, it might be interesting to figure out for the "succesful"
>>protocols which came first, deployment or standardization, but that'd
>>probably be for someone with more time on their hands.
>
> While you might find a strong correlation I suspect a MUCH stronger
>correlation will result by adding some subjective factors to the analysi=
s,
>namely the degree of technical risk, the degree to which the spec affect=
s
>the operational infrastructure, and the degree of market pressure to
>produce the new capability.
>
>d/
>--------------------
>Dave Crocker +1 408 246 8253
>Brandenburg Consulting fax: +1 408 249 6205 =20
>675 Spruce Dr. dcrocker@brandenburg.com
>Sunnyvale, CA 94086 USA http://www.brandenburg.com
>
>Internet Mail Consortium info@imc.org, http://www.imc.org
>
>
------- End of Forwarded Message