Re: Deja vu Again

[Jon Saperia <saperia@jdscons.com>]

On Wednesday 26 June 2002 07:24 pm, 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.
>
> Being able to break it up into identifiable bits and pieces
> (e.g., per interface) would be another step forward.
>
> To be able to intelligently display and edit this stuff with
> a single tool would be another step forward.
>
> 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.

I think most would agree that all these benefits would be appreciated. One 
of the other reasons that I think the XML format for a file representation 
is a good one is that it gives you the benefits cited above without having 
to invent another infrastructure, normalize CLIs, proprietary MIB Modules 
etc. That is the vendors figure out how to get to the XML form in their 
own way. The XML form is the what it should look like to others part.

WRT this project (XML) not only do I think this is the place where the 
biggest win could be achieved, but also by just doing the XML file format, 
the problem is reduced is scope far enough so that there might 
be a chance of success. 

/jon
>
> > 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
>  Tel: +1 408 546-1006   San José, California 95131  USA
>  ------------------------------------------------------
>  My opinions and BMC's are independent variables.
>  ------------------------------------------------------

-- 
Jon Saperia                         
				
saperia@jdscons.com
Phone: 617-744-1079
Fax:   617-249-0874
http://www.jdscons.com/

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