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.
Note that reserving a new port for netconf does not prevent CLI
implementations to have commands to switch to netconf mode and back in
the CLI session of interactive netconf debugging. But the real
scripted netconf interactions should IMHO go through the netconf
specific port.
/js