Re: draft-enns-*.txt

[Steve Waldbusser <waldbusser@nextbeacon.com>]

Ran,

You're trying to reduce risk, and that's a good thing.

But where are the risky aspects of  XML-based configuration management?
The risk and complexity is on the configuration management side and this is
where we have a tremendous amount of experience. It seems to me that XML is
the least risky aspect of it.


Steve



RJ Atkinson wrote:

> On Monday, Feb 17, 2003, at 11:25 America/Montreal, Margaret Wasserman
> wrote:
> > But, even if you believe that we should have specific experience
> > with XML-based configuration systems before proceeding,
>
> I do.
>
> >  we _do_ have
> > significant experience with these systems.
>
> There is the crux of our disagreement.  I'd say we have a little
> experience -- certainly XML-based configuration is not in wide use
> today, so I don't see any way to come up with "significant experience",
> particularly on the operations side of things (as different from
> implementation side).
>
> > Some network equipment
> > vendors are already shipping XML-based configuration interfaces, and
> > others are working on them.
>
> Yes.  Getting more experience with them will likely lead to identifying
> changes that are needed.  We should get that experience before
> standardisation.
> Note that vendors only need an open spec to implement something, not
> a formal standard, so my approach is not an impediment to any vendor.
>
> > There is at least one software company
> > that sells a software suite for XML-based configuration, with more
> > coming.
>
> Great, that means that we have a good chance to get the additional
> experience we need before trying to standardise stuff.
>
> > And, XML-based management is already widely used in some
> > other markets (i.e. industrial equipment).
>
> Interesting, but not terribly relevant.  I used to work in factory
> automation and industrial equipment -- their situation is very very
> different from that of an ISP and its network equipment.
>
> > If you define success as standardizing things that become
> > widely adopted, we can certain assure our "success" by never
> > letting anything enter the standards track until it is already
> > widely adopted.
>
> Of course I did not define things that way.  However, there is
> ample recent experience that IETF is lousy at protocol design
> when there is inadequate implementation experience or operational
> experience,
> as is the case here.
>
> > But, this also _sharply_ reduces the impact and influence that
> > the IETF can have on the architecture of an emerging protocol,
> > to ensure that it meets our standards for:
> >
> >         - Security
> >         - Scalability
> >         - Ability to maintain the value of our data model
> >                 (AKA the MIBs) through some type of
> >                 adaptation/translation
> >         - Whatever else we care about...
>
> Not at all.  The impact and influence are no different standardising
> now versus doing standardisation later.  The only thing I've proposed
> is more experience before standardisation, so that we CAN get a good
> architecture that DOES meet our needs.  Right now, we don't have
> enough data to have a high probability of coming up with a good
> architecture, IMHO.
>
> > I believe that the IETF has a significant role to play in helping
> > to develop quality standards for emerging technologies.  I think
> > that we can offer our considerable aggregate expertise to the mix,
> > and the result will be much better than the defacto standard that
> > will emerge if big vendors develop new technologies without our
> > input and eventually converge.
>
> I don't see the choice as "IETF now" or "De Facto later" but
> instead as "IETF now with suboptimal results" or "IETF later
> with a very good technical result".  So we view things very
> differently at the moment.
>
> Cheers,
>
> Ran
> rja@extremenetworks.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/>


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