Strange. I look at the same facts, and reach the opposite conclusions. The fact that there were many implementations based on drafts of standards shows that industry (not just us, but others as well) does not wait for SDOs to be "quite done". They are going to implement something even we label them "danger - still a draft pretty please don't implement" Everybody in our industry has heard of Internet Drafts. They know that these are the things that end up being RFCs, which are, as others have said, synonymous with standards. If we don't get the drafts reviewed well enough to be considered "good enough to implement" fast enough, industry is just going to ignore us and implement the draft. My conclusion is that we can't just ignore industry and keep polishing away, but that we have to do things in a timely manner. One thing we've learned from the TLS renegotiation thing was that it is possible to get a document from concept to RFC in 3 months. Yes, you need commitment from ADs and IETFers in general (IIRC you and I were among those pushing to delay a little), but it can be done. It's a shame that we can't summon that energy to regular documents, and that's how we get the SCEP draft which has been "in process" for nearly 11 years, and it's still changing. But that is partially because we (IETFers) all have day jobs, and our employers (or customers) severely limit the amount of time we can devote to the IETF. But that's a subject for another thread. Time to get back to that bug now... Yoav On Nov 2, 2010, at 5:09 PM, Martin Rex wrote: > t.petch wrote: >> >> From: "Andrew Sullivan" <ajs@xxxxxxxxxxxx> >>> >>> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > > Scanned by Check Point Total Security Gateway. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf