[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deja vu Again
HI Randy,
The format of an XML "flat file" that contains configuration is
totally different from how you get those from devices, and
how you apply them to devices. From an earlier message:
>What is a WG to standardize? Is it "higher level" operations,
>such as
> 1) replace existing config with config in this message
> 2) merge config in message with existing config
> 3) retrieve the existing (running) config
> 4) retrieve the saved (to be used at next system restart) config
>
>In general, there are several different models as to how configuration
>is done, such as
> 1) what can be changed during operation of the device versus what
> can only be changed by device reset.
> 2) does a config modification operation change both the "running"
> config and the "persistent" config, or is a explicit
> operation needed to cause running to be copied to persistent
> 3) are there more than one copy of persistent config, and if so,
> then how are they named and managed?
> 4) are default values supported (that is, are incomplete
> configuration allowed)?
> 5) how are configurations removed?
> etc
>What part of the above are to be standardized?
So, lets assume that the XML will be different for different
vendors (that is the XML for config for cisco will use DTD(cisco),
XML for config for Juniper will use DTD(juniper), etc).
Now, lets do the minimum, which is define a "standard" way
to get the complete config in XML format from a box. If this
is the only goal, is it valuable?
See other comments inline below...
At 04:24 PM 6/26/2002 -0700, Randy Presuhn wrote:
>Hi -
>
>> Message-Id: <5.1.0.14.2.20020626155354.02ddf2b0@127.0.0.1>
>> Date: Wed, 26 Jun 2002 15:56:30 -0700
>> To: Rob Austein <sra+xmlconf@hactrn.net>, xmlconf@ops.ietf.org
>> From: "David T. Perkins" <dperkins@dsperkins.com>
>> Subject: Re: Deja vu Again
>> In-Reply-To: <20020626143532.5E4721D14@thrintun.hactrn.net>
>> References: <102509064401@mx05.gis.net>
>> <5.1.0.14.2.20020625141310.032656a0@127.0.0.1>
>> <5.1.0.14.2.20020625152723.041c33b0@127.0.0.1>
>> <3D1982B9.2060801@cisco.com>
>> <102509064401@mx05.gis.net>
>> X-Spam-Status: No, hits=-2.4 required=5.0
>> tests=IN_REP_TO,RCVD_IN_MULTIHOP_DSBL,X_RCVD_IN_UNCONFIRMED_DSBL,
>> FUDGE_MULTIHOP_RELAY
>> version=2.30
>>
>> HI,
>>
>> Say the below is the goal. What is to be "standardized"?
>> Is there a standard for cisco config?
>> Another standard for Juniper config?
>> Yet another standard for each of vendors X, Y, and Z?
>
>Just being able to suck it out of a box and spit it back into
>the same or another box from the same vendor of the same type
>is a big step forward.
Putting it back seems simple, but there are some complications.
Putting it in another (identical) box (but with different
IP addresses, etc), is not so simple.
>Being able to break it up into identifiable bits and pieces
>(e.g., per interface) would be another step forward.
This is very vendor specific (and sometimes, product line
specific for a vendor). First question, "how are physical
and logical interfaces named?" Second question, "how are
logical interfaces created and deleted?" Third question,
"Is there referential restrictions for interface names?
That is, can you reference a physical interface that is
not present, or a logical interface that has not been
created?"
>To be able to intelligently display and edit this stuff with
>a single tool would be another step forward.
I can't see using an "off the shelf" XML editor with a DTD
per device type. I believe that a config editor is custom
code that has built into it the semantics of the device.
There can be common code that has knowledge of the
high level task that is being done, but putting the
config file in XML doesn't seem to me to help make this
high level task any easier.
>To be able to use the same configuration data for like things
>from different vendors would be another step forward. This can
>mean simple replay, or data-driven templates like some operators
>already use to plaster over vendor-specific differences.
>
>There's a strong temptation to solve all of these at once, but
>for some systems even the first step (dump config / load config
>consistent (but possibly opaque) format) would be a big improvement.
>
>> At 10:35 AM 6/26/2002 -0400, Rob Austein wrote:
>> >At Wed, 26 Jun 2002 07:25:51 -0400, Jon Saperia wrote:
>> >>
>> >> On the other hand if one wanted to create an XML based flat file
>> >> represenation of configuration information, regardless of how one got it
>> >> to the box in the first place, or even if it is on the intended device,
>> >> then that would be something that I think has some real value.
>> >
>> >Bingo! This was my understanding of the goal.
>>
>> Regards,
>> /david t. perkins
>...
>
> ------------------------------------------------------
> Randy Presuhn BMC Software, Inc. 1-3141
> randy_presuhn@bmc.com 2141 North First Street
Regards,
/david t. perkins
--
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/>