Since then IPSEC has been separated out and we have discovered that packet layer security is not nearly so useful as transport layer.
Back in PARC there was a think called error 33: building research on research. Tying deployment of necessary functionality to unrelated infrastructure projects has not had a good success record.
On Tue, Oct 12, 2010 at 4:08 PM, Noel Chiappa <jnc@xxxxxxxxxxxxxxxxxxx> wrote:
> From: Dave CROCKER <dhc2@xxxxxxxxxxxx>
> On 10/10/2010 2:51 PM, Steve Crocker wrote:
>> A compatible solution would have been better
> The community got ambitious
It's interesting that you should say this, because I've always been critical
of IPv6 because, IMO, it wasn't _ambitious enough_ - in fact, I think that
was a big factor in something you raised in a later message:
>>> Quite simply, we did not pay attention to larger issues such as market
>>> incentives and adoption barriers.
The lack of market incentives is, IMO, intimately connected to the lack of new
functionality - functionality which would have meant a more ambitious design.
However, on thinking about this, I think there is a way to reconcile your
'too ambitious' and my 'not ambitious enough' - and it's a way that provides
what I think is an important insight.
I think you're right in a way about the 'too ambitious', in the sense that
the plan supposed not an incremental, interoperable evolvement of IPv4 (such
as the ones you mentioned with "all this transition stuff is fine, but when
it's done, what we'll be left with will be ugly"), but spent most of its
technical energy thinking about a 'clean slate' design; in a way, one could
say it was too ambitious in the 'engineering details', as it were.
At the same time, I think I'm right in a way about the 'not ambitious
enough', in the sense that the plan supposed pretty much the same
architecture as IPv4; in short, one could say it was not ambitious enough in
the 'architectural big picture'.
So, if people will forgive me, I think one can play on one of Jon's favourite
quotations, and say that when contemplating the evolution of a
very-large-scale communication network, one should 'be conservative in ones
engineering details, and liberal in one's architectural vision'.
The 'conservative in the engineering details' means that interoperability and
evolution will be maximized, which will minimize adoption barriers; and the
'liberal in architectural vision' will maximize incentives - thereby giving
one the best possible change of overcoming the adoption barriers which have so
hampered deployment of the stuff currently being discussed.
> smacked of the overreaching that is often called second system syndrome
> From: Marshall Eubanks <tme@xxxxxxxxxxxxxx>
> Was it second system syndrome
I think it's useful to remember that if one looks at the original source of
the 'second system syndrome', "Mythical Man Month" by Brooks, it ends the
discussion of 'second system syndrome' with the following observation:
"The second-system effect has another manifestation somewhat different
from pure functional embellishment. That is a tendency to refine
techniques whose very existence has been made obsolete by changes in
basic system assumptions."
I will leave it to readers to gauge if, and how much, this applies to our
current situation.
Noel
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf