[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Goals for netconf - moving towards the charter description
Margaret,
Your explanation is clear, and may help in clarifying the goals of XMLConf. It would be useful to cut-and-paste or develop some of this text in the future WG Charter, and subsequent documents.
There still (at least) two issues open, and which are of some concern for me:
- Your use of 'network configuration' seems to imply a transaction model, which is one of the big missing pieces in SNMP. However, many people have something else in mind when they hear or say 'network configuration' which is the capability of performing configuration operations on a network (like configuring routing protocols, QoS parameters) while dealing with different types of devices
- Many operational models include performing configuration operations based on faults management (e.g. alarms) or performance monitoring management information. It is not clear if XMLConf will allow for such a model, especially as the discussion right now avoids ('by design') dealing with the information and data models behind XMLConf.
Thanks,
Dan
> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: Thursday, March 27, 2003 6:23 PM
> 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.).
>
> 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/>
>
--
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/>