It is very clear that at least part of this discussion is due to your unfamiliarity with English. Looking at past failures is a very good way to predict the possibility of similar failures in the future. History is a very good guide to setting a lower bound on risk. History is a very poor guide to setting a lower bound on risk, not least because people have a habit of only looking at the past events that give them good news. Most of us know that the typical business cycle lasts 7-10 years. However the geniuses behind 'Long Term Capital Management' only reviewed six years of the business cycle ending entirely. When one of the principals behind LTM is interviewed on TVfor his opinions on the bailout he is invariably tagged as 'Nobel Laureate', and never 'The fool who caused the last major fiscal crisis'. I have fifteen years experience in this business area. I am the only participant in this debate so far who can claim any direct knowledge of the business of embedding roots. It is on that basis and on the basis of direct conversations with my peers in the industry that I believe that the current DNSSEC specs do not meet the needs of deployment. Given that DNSSEC has not achieved deployment in fifteen years and given that the only deployment momentum that can be seen at the moment is in the form of 'top-down' edicts from ICANN, Vint Cerf and co, I think that the onus of proof falls on those who assure us that DNSSEC does in fact meet deployment requirements. On Sat, Jun 13, 2009 at 5:25 AM, Masataka Ohta<mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Phillip Hallam-Baker wrote: > >> Past history is a very bad guarantee that problems will not arise in the future. > > So, you mean your statement: > > : Trust roots have to be valid for at least a decade to be acceptable to > : the application vendor community. > > hardly guarantee anything. > >> Be liberal in anticipating repeat of past problems, > > Indeed. > > Unnoticeable cache poisoning by glues is repeated even with > bailiwick and once again with DNSSEC. > >> be conservative in >> your expectation that new problems will not arise. > > The protection is to make protocols as simple as possible. > > The following paper discusses about it to some extent. > > http://ftp.csci.csusb.edu/ykarant/courses/f2007/csci530/papers/counterpane-ipsec.pdf > > Masataka Ohta > > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf