Hi Mike,
At 8:41 AM -0700 9/7/05, Michael Thomas wrote:
In answer to Margaret's question about how it would know
where to "call home", it seems to me to be about the same
problem as with traps/informs. I haven't had anything to do
with this wg, but it seems pretty plausible that you'd
initiate the session from the agent using a trap/inform
over tcp/ssh/whatever and then just reuse the connection
for subsequent pdu's sort of akin to http 1.1 reuse. It
would just all sort of fall out of the overall snmp
architecture.
So, every time a notification sender sends a trap or notification it
would set-up a TCP connection to each of the notification receivers
in its list and keep that connection up indefinitely? Would it
reestablish ithose connections when they fail? How long would it
keep a connections up if it never receives a command request on that
particular connection? Please remember that not all notification
receivers _are_ command requestors, and not all command requestors
are notification receivers.
I do think that if you built a mechanism for a command responder to
open a connection to a command requestor, the MIB for configuring the
new mechanism might resemble the MIB that is used to determine
notifications should be sent, but I don't think that it will be
identical and I do not think that the current MIB should be
overloaded in this way.
BTW, nothing about your note explains to me why you think that this
mechanism should be defined in a Security area WG that is working on
a completely separable problem. If you really think that defining
call home for SNMP is something that the IETF should do, I would
encourage you to get together with Eliot and request a BOF in the OPS
area.
Margaret
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf