Re: [Isms] Transport protocol discussion

[Juergen Schoenwaelder <j.schoenwaelder at iu-bremen.de>]

On Tue, Aug 02, 2005 at 02:34:25AM -0700, Wes Hardaker wrote:

[...]

> My worry is that coding that human decision process about when to
> restart a broken TCP session because recovery will be faster by
> restarting than waiting for the TCP stack to fix the session will be
> impossible.  I'm not at all convinced that TCP sessions are stable,
> based on my experience over the last few years.  I do think they've
> gotten better, but I'm not willing to bet the management of my network
> on it.

SNMP stacks usually come with a default retry/timeout strategy and
they report some 'noResponse' error once you have had your retries.
What happens next is either left to a human or some magic - I am not
sure there is at the end that much difference in the magic here.

[Yes, there are several technical differences I am ignoring here,
 but the point is that even with SNMPv1 you have to have some logic
 do deal with situations where your network is in trouble.]

We simply have to give up the idea of a "one size fits all" security
model. There are several trade offs to be made and operational
requirements differ between environments.

Personally, I see practical value in SNMP/SSH because it would enable
me to transition to a secure version of SNMP with close to zero
deployment costs. Eric Fleischman lives in a different environment and
he surely likes to have SNMP/Kerberos because it allows him to
transition to a secure version of SNMP with close to zero deployment
costs.

The question for me is whether we want to enable people to make such
"close to zero deployment costs" transitions to secure SNMP or whether
we continue to work on the "one size fits all" security approach,
something we have been doing not too successful for more than a dozent
years now.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms