On Tue, Nov 02, 2010 at 04:09:53PM +0100, Martin Rex wrote: > 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? Maybe. Arguing about counterfactuals is always fun, though a little difficult. But in general, there is more than one way in which a plethora of different standards can affect things. One way -- the one you seem to be (quite reasonably) worried about -- is that you get a bunch of non-interoperating, half-baked things that are later rendered broken by updates to the specification. Note that this method is actually the one we claim potentially to have; the two-maturity-levels draft does not change that. The idea is that you are supposed to try things out as early as reasonable, and if there are significant changes, they'll turn up when an effort is made to move things along the maturity track. Some people have argued in this thread (and the other related ones) that there is a problem from the IETF attempting to prevent the problem you're talking about. That attempt, which is not documented anywhere, amounts to a high bar of difficulty in getting an RFC published at all. I'm not actually sure I have the empirical data to support a claim that it really is harder to get that initial-version RFC published; but people seem to think that it is, anyway. Suppositing that it really is harder, then the current documented standards track, and the two-maturity-levels document, will both be wrong. There will be one effective maturity level. The argument in favour of publish-early, revise-often approaches is that iterations will, or ought to, improve things. Imagine: in some other possible world, they're up to IPv10 now, but it took those intervening versions to discover that you really really needed some clean interoperation layer with the "legacy" IPv4 networks. In that other possible world, the early deployment failures of quickly-produced IPv6 specifications were taken to mean that deployment was too hard, and so a _more_ interoperable system was crafted. (Having come from a community where people talked about "the possible world where I am a mud puddle", the possible world where deployment failure leads protocol designers to think harder about real deployment doesn't seem unrealistic to me.) I should say that personally, I'm not sure where I land on the early-often/forward-compatible continuum; I suspect it differs depending on the protocol. But as others have been pointing out, it sure looks like there's more than one problem here, and we need to be clear on what we think we're solving before we jump in and start doing it. Best regards, A -- Andrew Sullivan ajs@xxxxxxxxxxxx Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf