On Mon, Sep 12, 2005 at 09:24:51AM +0200, Eliot Lear wrote:
Juergen,
1) I see lots of people using tools like MIB browsers, snmp command line
tools called from fancy scripts, monitoring packages such as cacti
and nagios (these were even used on the IETF network in Paris if I
recall correctly) and all these packages share the feature that the
"manager" does not have a fixed transport address but takes the
initiative to talk to an "agent" when there is need to do so. In
other words, all these existing and deployed applications simply
won't work with call home easily since they would require to
implement some rather magic logic to dispatch SNMP traffic via
a locally centralized connection manager.
Indeed I do not advocate deleting the existing model where the manager
contacts the agent. But the tools you mention will almost assuredly
need to be modified no matter the outcome of this debate, because they
will need to incorporate SSH.
Sure, tools need to be modified, no doubt about that. I just wanted
to point out with my message that for a certain percentage of the
tools out there, CH will be cumbersome to implement and use since
these tools tend to come and go and it is rather unlikely that they
will go through a local centralized connection manager which can
provide a static transport endpoint to call home. Since in the
environments I am most familiar with these tools heavily dominate, I
once wrote that CH is OK for me as long as we can make it work without
making the traditional model more difficult.
I agree with those who said that CH is an architectural change and I
have yet to see a concrete proposal how CH via ssh can be achieved.
Funny you should mention this. I've mentioned several approaches on
this list and others several times, while the group converged on using
SSH without having a single draft available at the time. It was indeed
impressive that the group had gone from (at least) four separate viable
drafts down to zero by the end of IETF-63.
As I said during the meeting: I do not subscribe to this "no single
draft" argument. Some people have done a fair amount of work to think
about the architectural extensions needed for transport mapping
security which you happily refer to in the BEEP document. The option
of SSH is mentioned in the architectural document, even though we did
not went to the glory details of all the options that were on the
table back then (TLS, SASL, DTLS, SSH). In fact, I fail to see how you
get the conclusion that we went down to zero drafts by the end of
IETF-63.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf