Yow! I agree completely.
Said very succinctly, we need a framework with:
- transport
- session
- security which includes authentication, privacy, and access control
- protocol operations
- schema definition language (e.g.: XML schema)We do not need common models to start. Having just the above framework will allow for access to information that is easy to parse and perhaps easy to use -- a big step over where we are today with CLI, SysLog, etc. which are difficult and error prone to parse.
In the future we can start to think about whether we want to define common models.
Cheers, /gww
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Wednesday, January 08, 2003 19:40
> To: Chen, Weijing
> Cc: Xmlconf (E-mail)
> Subject: RE: Perspective: XML's ticking time bomb
>
> At 05:40 PM 1/8/2003 -0600, Chen, Weijing wrote:
>
> >XML is a new bottle (syntax) waiting for wine (semantic) to be filled in.
> Historically, we have TL1 (text string based), CMIP (ASN.1 object-
> oriented), SNMP (ASN.1 table-oriented), CORBA (IDL object-oriented), CLI
> (text string based), syslog (text string based). TL1, CLI, syslog see
> more operation deployment than other mechanisms.
> >
> >
> >
> >In the real life, network management model standard is always lagging
> behind the network protocol standard. It is just a nature process of
> standard development. While the standard is being developed, vendors will
> implement the pre-standard protocol and mitigate into standard protocol
> later. Service providers will purchase pre-standard equipment with
> promise of software upgrade to standard protocol, which almost every
> vendor honors that promise later on.
> >
> >
> >
> >However, it is a totally different story about the implementation of
> network management model. Vendors will carve out whatever temporary
> suitable network management tool, be it CLI, syslog, TL1, craft interface
> to placate the service providers. Why vendor do that? Because first
> vendor sold to a service provider has a tendency to lock that service
> provider into his equipment. Service providers will buy into to an early
> bird vendor regardless his network management capability because initial
> deployment only involves very few boxes. Hey, nobody has long term vision
> nowadays, not just service providers. As the deployment grows, a more
> capable network management tool is a must. Now incumbent vendor will ask
> for outrage price for a standard compliance network management tool. So
> service providers decline this kind of offer and try to survival the
> growth of service by patching up the systems. And then low cost,
> reliable, profitable service got throw out of the window.
>
> I think the problem is more complex than you describe.
> Any re-engineering effort has to be cost-justified or it won't happen.
> The overall reduction in operational cost has be greater than the
> perceived cost of the re-engineering effort. This is rarely true
> for converting a solved problem from proprietary to standard technology.
>
>
> >
> >
> >It is more of a business problem than a technical problem in the network
> management domain. However, track record show a flexible framework helps,
> for example, CLI, syslog, TL1, etc. A rigid framework tends to stall, for
> example, CMIP, SNMP, CORBA. The advantage of XML is that it is more or so
> like CLI/syslog/TLI, yet could be more structure than all of them. If we
> are not careful of controlling XML proliferation, the structural advantage
> of XML will disappear quickly as mentioned in the Bert's first email. And
> I think that David Durham's email point out what we can do to make XML
> works: "This group should focus on determining which XML schema
> definition language IETF wgs will use, define the basic reusable data
> types useful across IETF wgs, define the operational model for XML
> transactions, and select a common transport. Just get the foundation in
> place & let the models work themse!
> >lves out over time in individual wgs and let XSLT be the glue between the
> early products and late standards".
>
> I agree, but I would add that the framework needs to include:
> - transport
> - session
> - security
> - high level protocol operations
>
> It seems there are some people that want to ignore these issues and skip
> ahead to the definition of a data model. I think there was widespread
> support at the XMLCONF BOF to attempt a phased approach. First
> standardize
> the framework, transport, and protocol for manipulating device
> configuration,
> then work on a standard data model.
>
> > Weijing Chen
>
> Andy
>
>
> --
> 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/>