Re: draft-enns-*.txt

[Margaret Wasserman <mrw@windriver.com>]

Hi Ran,

> My main concern is that the past threads on this list have largely
> reflected design-without-experience or abstract "requirements" that
> aren't based on operational experience with any XML-based Configuration
> system.
While I don't completely disagree with your thinking, I have to
point out a couple of flaws in this statement.

First, we are trying to build a configuration protocol that will
meet the needs of operators and vendors.  And, certainly, the
community has a great deal of experience with the configuration
of networking equipment.

XML is a _means_ to improve the state-of-the-art in configuration,
not an end in itself.  We used it because it met our needs, and
because of the wide array of commercial products available that
can be used to parse, manipulate and develop XML.

But, even if you believe that we should have specific experience
with XML-based configuration systems before proceeding, we _do_ have
significant experience with these systems.  Some network equipment
vendors are already shipping XML-based configuration interfaces, and
others are working on them.  There is at least one software company
that sells a software suite for XML-based configuration, with more
coming.  And, XML-based management is already widely used in some
other markets (i.e. industrial equipment).

I guess this all comes down to the role that IETF would like to
play in this sort of effort...

We can take a back seat role, as you have proposed, and wait until
something emerges as a defacto industry standard, or we can try
to drive a standard in this area.

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.

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

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.

Of course, this does mean that there will be more times when we
standardize things that don't become widely adopted...  but, I
don't see what's so bad about that, if the things that _do_
become adopted are better because of our efforts.

But, that may be a bit beyond the scope of an XML-based
configuration protocol...

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