[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-enns-*.txt


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