The large difference being that I can't just deploy TCP-AO on 3rd party machines. I have to wait for the vendors these 3rd parties use to do it (e.g. the OS vendor), accept patches for it and deploy it, etc. I have zero control over that, and zero control over the timeframe. That means I can't plan for it or hurry it along. Unfortunately, much of the time, my only options are either to complain about it, or attempt to replace it. -=R On Wed, Sep 4, 2013 at 3:50 PM, Joe Touch <touch@isi.edu> wrote: > > > On 9/4/2013 3:20 PM, William Chan (陈智昌) wrote: > >> On Wed, Sep 4, 2013 at 2:58 PM, Michael Tuexen >> <Michael.Tuexen@lurchi.**franken.de <Michael.Tuexen@lurchi.franken.de> >> <mailto:Michael.Tuexen@lurchi.**franken.de<Michael.Tuexen@lurchi.franken.de>>> >> wrote: >> >> On Sep 4, 2013, at 9:43 PM, Roberto Peon <grmocg@gmail.com >> <mailto:grmocg@gmail.com>> wrote: >> >> > I suspect that Yuchung meant 'widely deployed and available', >> when he says 'always'. That should certainly be true for TCP. >> That is definitely true for TCP. >> However, why do you need an alternate solution to be "widely >> deployed". Can't it >> be deployed within the browser? >> >> >> I think people are being too imprecise which leads to confusion. UDP is >> widely deployed. A UDP based solution can be deployed within the >> browser. TCP-AO is not widely deployed. It cannot be deployed within the >> browser. >> > > Although that's correct, there's no way to protect UDP. TCP-AO is for > protecting individual TCP connections; if that's what you want, you need to > update TCP. > > My point about TCP-AO is that it's not useful to continue to complain that > something isn't widely deployed. If you need what it has, then why not > start by helping deploy it? Then at least there's one less thing to > complain about being missing in a few years. > > Joe >
Received on Thursday, 5 September 2013 00:59:28 UTC