RE: Goals for netconf - moving towards the charter description

[Margaret Wasserman <mrw@windriver.com>]

Hi Faye,

We seem to have gotten way off-track here, and I'm not sure why.
I think that we may be using the same terms differently, or
something, as one message in this thread does not (to me) seem
to follow from another.

XMLConf is a generic configuration protocol.  It could be used to
configure any type of protocol or device.  Within the IETF, our
focus is on standardizing a protocol that will be useful to
configure networking equipment, but that doesn't preclude its
use for other types of equipment (industrial, consumer, etc.).

In order to support the XMLConf protocol, a device will need to
be reachable via IP, and will need to support three TCP connections.
It will also need to include HTTP, BEEP, an XML parser and an
implementation of XMLConf.  XMLConf cannot be used to configure
devices that do not support XMLConf.  We've looked closely at the
expected system resources needed to support XMLConf, and we
do not believe that the costs are prohibitive.

It is probably best if you think of XMLConf, not as a replacement
for SNMP, but as a replacement for (some uses of) CLI.  Today,
many operators use CLI to configure devices, either manually or
automatically.  The ones who build automated configuration systems
using CLI are forced to deal with many different command structures,
"screen scraping" and non-compatible changes from one release to the
other.  Most of these problems are caused by a disconnect between
their use of CLI (automated scripting) and the purpose for which
CLI was designed/implemented (human interface).  It is a primary
goal of XMLConf to offer programmatic access to the same type of
configuration data that can currently be manipulated using CLI.
Operators who currently use CLI and scripting to configure devices
have told us that their lives would be improved by the existence
of a protocol like XMLConf.

XMLConf has several compelling (we hope!) benefits for folks currently
using CLI for configuration, including (but not limited to):

	- The ability to deal with configuration data separate
		from state data (simplifies dump, compare, restore
		of complete or partial configurations).
	- The elimination of screen-scraping.  While this may seem
		small, minor software changes between one sofware
		load and another are currently costing operators a
		lot of time and money.
	- The ability to configure networks, instead of just devices
		(i.e. external transactions -- lock, commit, etc.)

XMLConf is also intended to retain the primary benefits of CLI that
caused these people to choose it (over SNMP, etc.) in the first
place:

	- All configuration data (standard and proprietary) will be
		available through a single mechanism. [The trick to
		this lies in making it very easy for vendors to make
		their proprietary information accessible via XMLConf.]
	- Maps well into configuration models where the canonical
		configuration is held in a centralized database.
	- Text-based.  Operators can understand what is transmitted
		on the wire, and the output can be manipulated using
		widely-available (and free) tools.

Operators who currently use SNMP-based systems to do configuration
obviously have different requirements and trade-offs than those who
are currently using CLI for configuration.  The folks using SNMP
may or may not find the benefits of XMLConf to be compelling, but
either way is okay.  If these folks would prefer to continue using SNMP
for configuration, they are welcome to do so.

XMLConf focuses entirely on _how_ systems and networks are configured,
not on _what_ is configured.  Other work may (and should) be undertaken
to specify a standard XML schema (or other representation) to describe
_what_ can be configured with XMLConf in a standard way, but that is
not part of our initial work.

Margaret



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