Re: Thoughts on NetConf Requirements

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

This NETCONF effort is multi-dimensional, and both simple and complex
at the same time. Yes, one of the primary issues is being able to
send and retrieve configuration; but it also must retrieve status,
statistics, and asynchronous notifications of events and trace output.
   
And yes, to do simple things it should be simple, but to do "complete"
management, it should also be complete, secure, and do this using
the appropriate amount of managed system and network resources.
Plus, it's got to be interoperable. And there is this silly problem
of an installed base.

In an idealized world, the XML interface is just a portal to a transport
mapping, which as a user to the XML interface, the details of the
transport are not really relevant to accomplishing a task. Of course,
you are still concerned about security and cost to use the transport.
Given this, you could send the XML as text, encode it in binary,
put it directly on top of TCP, or on SSH, or on TLS. You could use
one transport connection per channel, or use BEEP to provide
support of multiple channels over one transport connection.
You might be able to get by with a single channel (if everything
works OK). But you might need a channel to abort a request or
its response. And another channel to receive the events and/or
tracing that starts to happen because of the command that you
sent on the operations channel.

I hope the above has provided a few insights into why the
NETCONF is not limited to just sending XML text over an
unspecified transport layer with support for just a single
channel.

Regards,
/david t. perkins


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