t.petch wrote:
From: "Andrew Sullivan" <ajs(_at_)shinkuro(_dot_)com>
Supppse we actually have the following problems:
1. People think that it's too hard to get to PS. (Never mind the
competing anecdotes. Let's just suppose this is true.)
2. People think that PS actually ought to mean "Proposed" and not
"Permanent". (i.e. people want a sort of immature-ish level for
standards so that it's possible to build and deploy something
interoperable without first proving that it will never need to
change.)
3. We want things to move along and be Internet STANDARDs.
4. Most of the world thinks "RFC" == "Internet Standard".
I think that this point is crucial and much underrated. I would express
slightly differently, That, for most of the world, an RFC is a Standard
produced by the IETF, and that the number of organisations that know
differently are so few in number, even if some are politically
significant, that they can be ignored.
The underlying question is acutally more fundamental:
do we want to dillute specification so much that there will be
multiple incompatible / non-interoperable versions of a specification
for the sake of having a document earlier that looks like the
real thing?
There have been incompatible versions of C++ drafts (and compilers
implementing it) over many years. HD television went through
incompatible standards. WiFi 802.11 saw numerous of "draft-N"
and "802.11g+" products. ASN.1 went through backwards incompatible
revisions. Java/J2EE went through backwards-incompatible revisions.
Publishing a specification earlier, with the provision "subject to change"
appears somewhat unrealistic and counterproductive to me. It happens
regularly that some vendor(s) create an installed base that is simply
to large to ignore, based on early proposals of a spec, and not
necessarily a correct implementation of the early spec -- which is
realized after having created an installed base of several millions
or more...
Would the world be better off if the IETF had more variants of
IP-Protocols (IPv7, IPv8, IPv9 besides IPv4 and IPv6)? Or if
we had SNMP v4+v5+v6 in addition to v3 (and historic v2)?
Or if we had HTTP v1.2 + v1.3 + v1.4 in addition to HTTPv1.0 & v1.1?
I do not believe that having more incompatible variants of a protocol
is going to improve the situation in the long run, and neither do
I believe in getting entirely rid of cross-pollination by issuing
WG-only documents as "proposed standards".
What other motivation could there be to publishing documents earlier
than vendors implementing and shipping it earlier? And if they do
that, there is hardly any room for any substantial or backwards-
incompatible changes. And the size of the installed base created
by the early adopters significantly limits usefulness of any features
or backwards-compatible changes that are incorporated into later
revisions of the document.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf