ietf
[Top] [All Lists]

Re: Alternate entry document model (was: Re: IETF processes (wasRe:

2010-11-02 10:46:24
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(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf