The original idea seems to have been that IPSEC would be a big enough incentive to upgrade.
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 <[email protected]>wrote: > > From: Dave CROCKER <[email protected]> > > > 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 <[email protected]> > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
