|
All, When I
talk to the developers of our NMSs, they say that their toughest issues deal
with differences in semantics among the devices we have to manage, not the
syntax or protocol used to access the data. If this
group does manage to get the industry moving towards a single management
protocol, it would be a step forward, but not a big one. Still, if that’s all we can get, we’ll
take it. I think we should make it
clear that this is the strategy or scope of the group, though. Based on
some of the discussion I’ve seen here it seems that if this group is successful
then to manage a device we would go from using IPDR, SNMP, syslog with
proprietary messages, ftp of proprietary-formatted performance management data,
and proprietary CLI to IPDR, SNMP, syslog with proprietary messages, ftp of
proprietary-formatted performance management data, and XML with a proprietary
information model. It brings to
mind an Eastern proverb about a journey of 1000 miles beginning with a single
step. The main
argument here seems to be how big that first step should be. I can’t fault John Strassner for
wanting to take a bigger step. We
(SBC) would support taking that bigger step, but if the industry won’t accept
it from the start it will just be a waste of time. Given the
inability of the industry to support standards in this area, we here at SBC are
beginning to talk about other ways of easing the difficulty of integrating new
equipment with our management systems.
We are thinking of basically making the management interface provided by
our first supplier of some type of network element our de facto standard. So, if Vendor A is the first to sell us
an Ethernet switch, for example, then our contract with Vendor A would require
them to share their management interface specification with us free of intellectual
property rights. If we
subsequently sought a second supplier for Ethernet switches, that supplier
would have to support Vendor A’s management interface. So, I hope it is indeed easy to do
information model translations with XSLT.
If you’re an equipment supplier, in the future you may be forced to do
so to make a sale. Keith Allen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 (512) 372-5741 -----Original
Message----- I disagree. First, where's the paradigm shift? Second,
what you're describing in translation is exactly the same work that is
necessary to build a common model in the first place. I don't see how you can
say that building a common model is impossible, but having vendors agree on
translations is. Third, I don't see how different working groups in isolation
can do either of these. Finally, you say: "IMHO, 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 themselves out over time in individual wgs and
let XSLT be the glue between the early products and late standards." I honestly don't see how this works,
helps, or benefits anyone. Choosing a syntax, and defining the data types used
in that syntax, doesn't enable interoperability. Selecting a common transport
is immaterial, it just moves bits around. And the hope that "the models
will work themselves out over time in individual wgs" is simply naïve -
witness the ongoing painful arguments in CCAMP, for example, between
"IETF" and "ITU" "models". regards, -----Original Message----- I think we need to keep in mind that XML
presents a bit of a paradigm shift from what we have known. Yes, common models
are important, but they are almost always too late for companies and, thus,
incompatible with the vast majority of products when completed. It just takes
too long to get them standardized via the process of compromise, and even
longer to get them right. What XML offers is a large set of tools
that allow translation between different vendor's models. These models can be
developed independently around a specific technology, and, if deployed using
XML, can still be made to interoperate where there is commonality. So your schema can define
"<IntFace> UP </IntFace>" and mine can define
"<Interface> ON </Interface>" and XSLT can be used to
translate between these. Or, better yet, when a standard is completed, vendors
can easily provide translations from it to their existing models. IMHO, 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 themselves out over time in individual wgs and
let XSLT be the glue between the early products and late standards. -Dave |