At 10:07 AM 2/5/2004 +0100, Juergen Schoenwaelder wrote:
>>>>> Wes Hardaker writes:
Wes> Any and all transports could pick a netconf specific port to use.
Wes> It was simply decided that this wouldn't be done (except, I
Wes> guess, for BEEP). But its not BEEP that matters. It's the
Wes> different port, and there is nothing wrong with attaching the
Wes> other protocols to other ports too. The authors just didn't want
Wes> to do it.
Perhaps this needs to be revisited. Using a new port number, at least
for the SSH mapping, makes really sense to me. It also avoids this
"invocation of NETCONF as an SSH subsystem called "netconf" language
in the mapping document which never really made me happy.
So, if you didn't use this language, how would you invoke netconf?
Are you suggesting that all NETCONF/SSH nodes need to have special
SSH clients or servers that know that requests on port <netconf>
should go into the special netconf SSH application while requests on
port <ssh> should not?
I thought that one of the points of this excercise was to make
sure that we could use standard SSH clients and servers.
I don't have any objection to specifying that netconf should be
run over SSH on a specific <netconf> port if that is the consensus
of the group (assuming that is configurable in common client
applications, of course), but I think you'd still need to specify a
subsystem name. And, BTW, I think that there will end up being two
netconf subsystems based on recent "role" discussions: "netconf-agent"
and "netconf-manager".
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/>