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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf