Margaret, > The call home solution doesn't help with the problem of the _manager_ > being behind a NAT. It only applies to situations where the manager is > at a fixed location on a globally-addressable network and the managed > device is behind a NAT or firewall. Actually, depending on how the solution is developed it certainly CAN help the problem with the manager being outside a NAT. But we are now being somewhat loose with terms, so let me be more specific. Consider the case where a manager is behind a firewall or NAT and the device sits out in the open. This could easily be an enterprise where the network management station itself sits behind a firewall in order to prevent/detect/respond to control attacks. Now consider notifications. The device will have no means to get a notification to a manager unless a hole is specifically poked for the purpose and the management station is in the same address space as the managed device. If the management station has initiated an SSH connection to the agent, the agent can then initiate notifications over the SSH connection, either by using the "snmp" application as a simple two way stream as Harald suggests, or as a "turned" connection as I had suggested in the first message on this thread (I think both approaches should be debated). > BTW, the solution where you configure the NAT/firewall to admit the > appropriate traffic could also be set-up to work properly when the > manager is mobile and/or when the manager is gaining Internet access > through a NAT. "Call home" would not work in these situations. And so your premise above not holding, the remainder of your argument also does not hold. Eliot _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf