On Tue, Sep 13, 2005 at 02:31:54PM -0400, Sam Hartman wrote: > >>>>> "David" == David B Harrington <ietfdbh@xxxxxxxxxxx> writes: > > David> Hi, Personally, I'd rather see the issue of working through > David> NATs and firewalls solved at the SSH level, and then SNMP > David> and other SSH-using applications, such as Netconf and CLI, > David> could use the solution in a consistent manner. > > I think that the ssh connection application already has a fairly > reasonable story for NATs and firewalls, so I don't see much of a need > for ssh itself to advance in this area. > > For the most part people who block port 22 really do intend to block > ssh and so having standard facilities to get around that would not be > appropriate. The port forwarding support in ssh seems to be an > adequate solution for NATs. Sam, this is not about blocking port 22 as far as I understand things. I think the issue here is that TCP connection establishment determines ssh client/server roles. If there would be a way to initiate the connection but subsequently taking over the server role, protocols like netconf and presumably isms would find it much easier to provide CH functionality. /js -- Juergen Schoenwaelder International University Bremen <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf