Thoughts on NetConf Requirements

[Kevin C Miller <kevinm@andrew.cmu.edu>]

With a request from various folks at NANOG for operational input to the 
WG/drafts, I'll bite:

The bottom line for me is that I'm interested in a mechanism that can 
eliminate screen-scraping and provide reliable ways of issuing commands, 
changing the config, and retrieving data from network boxes. I want to be 
able to send commands that bring in new firmware, change the configuration, 
and collect the output from reporting commands.

Certainly it appears that something xml based is the right way to go. I 
have two intertwined concerns though: complexity and transport.

I don't believe that the document should mandate requirements about the 
underlying transport, and I believe that it should be possible to use the 
netconf protocol over a "raw" connection.

Specifically, I can envision connecting to a device via ssh, issuing a 
command ('xmlconf') and then sending and receiving the 
commands/configuration/statistics. Obviously this would most often be done 
via an automated mechanism, but making it possible for someone with a 
terminal to use the protocol would seem to have merit. I don't see how 
requiring multiple channels would be possible in this case.

This wouldn't preclude transport mechanisms that do not involve first using 
an existing CLI, or multi-channel support for better control, but otherwise 
I'm not clear how transports such as consoles could be used by the 
protocol. Making it possible to reuse existing raw transports would seem to 
make the protocol useful in a wider array of contexts. (For example: 
configuration of a standalone server.)

-Kevin



--
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/>