[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ever onward


Hi Juergen,

At 10:11 PM 2/5/2004 +0100, Juergen Schoenwaelder wrote: 
In my view, however, netconf after all is a programmatic interface and
so you will have special programs (perhaps just scripts) to talk
netconf.  And then using a special netconf port is more a feature and
has virtually no costs since I expect that every reasonable
implementations allows to specify the port to connect to.


I agree that there is little/no cost to using a different port
on the management and agent sides of the netconf connection.

My concern is that, in an effort to make it easier for operators
to administratively control management access to their devices,
we would actually make it harder.  If we have separate ports for
CLI/SSH and NETCONF/SSH, then the an administrator would have to
poke two holes through his firewall to enable both types of
external management access.  Alternatively, he would have to
block two types of traffic to block external management access.

I guess that Wes and I are operating under opposite assumptions...

I'm assuming that operators already have appropriate (by their
definition) access control mechanisms in place to block/allow
SSH-based management access to their networking equipment (for
CLI).  So, by using the same port, we would make it easy for
NETCONF/SSH to piggy-back on the same ACL configuration, etc.

Wes is, I guess, assuming that there are operators who might
like to distinguish between allowing CLI/SSH access to the device
and allowing NETCONF/SSH access to the device...  I'm not sure
why, because I am picturing a world in which both interfaces
can do the same things for the same users -- one just provides
a good human interface and the other a good programmatic
interface.

Margaret


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>