[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: survivability, rewriting
Ummm, exactly.
While I would *never* utter the word "r_quirement" on the multi6
mailing list, it might be useful to think about success criteria.
It's blindingly obvious to me that multi6 can't meet the needs of
every application (for the same reason general-purpose security
mechanisms might not meet the needs of the most extremely paranoid),
and it's blindingly obvious to Pekka that multi6 has to meet the needs
of at least some applications (and I agree). Neither of these are
controversial positions. What's the success criteria, really, between
these two extremes?
Spencer
----- Original Message -----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Brian E Carpenter" <brc@zurich.ibm.com>
Cc: "Multi6 Mailing List" <multi6@ops.ietf.org>
Sent: Friday, October 31, 2003 5:16 AM
Subject: Re: survivability, rewriting
> On Fri, 31 Oct 2003, Brian E Carpenter wrote:
> > I agree with this, and I'd add that many applications can survive
much
> > longer glitches than 5 seconds, and even TCP resets, by putting
some fairly
> > trivial retry logic in the right place. [...]
>
> (I'm pretty sure you agree here, but playing the devil's advocate to
bring
> up an important point here..)
>
> Is it the business of the applications to put in this retry logic?
>
> No.
>
> If *every* application has to do this, we've failed. If such adding
such
> logic is deemed the best approach, it needs to be put somewhere
else.
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>