[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Goals for netconf - moving towards the charter description
Margaret,
Thank you for the reply. I am really happy to see your statement: "
XMLConf is a generic configuration protocol. It could be used to
configure any type of protocol or device." As I kept getting emails
stating XMLConf is for IP centric device only which is a bit frustrating
for me.
Please see my comments embedded in <FL> below.
Best,
-faye
-----Original Message-----
From: Margaret Wasserman [mailto:mrw@windriver.com]
Sent: Thursday, March 27, 2003 8:23 AM
To: Faye Ly
Cc: xmlconf@ops.ietf.org
Subject: RE: Goals for netconf - moving towards the charter description
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.).
<FL> YES!
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.
<FL> I believe you 100%. Does protocol provide any LITE version so that
only one TCP connection is sufficient given that only configuration
request and configuration confirmation are needed?
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.
<FL> I think we spent enough time at the BOF clarifying this and I
totally agree. This is not a SNMP replacement but rather more towards
CLI scripting replacement. One question though, What about downloading
partial or even full configuration file to the network equipment and ask
the NE to perform the file and return the results. This seems to match
really well with the scripting. This also helps to simplify the
interface between CLI and configuration file. Does XMLConf support this
as the XMLConf protocol document indicates?
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.)
<FL> I guess you answered my question here that XMLConf does support
full or partial configuration files. Please confirm though because I
got a bit lost during last round of emails exchanged. Yes, my biggest
argument in supporting XML configuration is that it fits configuration
file like a glove. I have actually done it personally too ...
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.
<FL> I do hope we can replace TL1 with XML too one day!
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.
<FL> Another YES!
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.
<FL> I like the 'should' very much. The _what_ don't have to be
covering every possible data model but a good set of sanity check or
examples ought to be provided as this is a configuration protocol and it
needs to be able to deal with configuration model. Again thanks a lot
for the detailed reply and that really answered a lot of my questions.
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/>