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

Re: Methods in the NIM requirements

on 05/02/2000 8:01 PM, John Strassner at jstrassn@cisco.com wrote:

> Hi Jon,
> I'm confused.
> With regard to your first point, I disagree. The key to
> optimal database performance lies not so much in the data,
> but in the types of queries (and other operations, like
> inserts) that are being performed. This is why data analysis
> by itself doesn't produce an optimal database system.

And the nature of the queries and inserts is fundamentally impacted by the
type of data stored. We are both in agreement about the 'use model' having
significant impact. The point about which we disagree (which is ok) is that
the nature of the underlying data substantially impacts the design, the way
indices are set up, where normalization is done etc.
> With regard to your second point, I humbly submit that this
> is a circular argument. You are basically saying that if one
> vendor deviates from the standard, then third parties are in
> trouble. That part I agree with. But you conclude with:
>> Back to the single vendor proprietary approach
>> under a thin veil of standards.
> which is the part that I don't get. If the vendor is playing
> by the rules, then the vendor isn't compliant with the
> standards. So how can this be "a thin veil of standards"?
> Rather, the third party now has the advantage of standards
> compliance, and if the standard is worth its weight, then
> the third party will be vindicated.
Let me cite an example outside of the management domain. Lets use routing
protocols - standards right. We can all point to the RFCs, but for a router
to not be bug for bug compatible with Cisco is a fatal flaw. Other examples
in the management area are, vendors claiming compliance with a standard that
has been inadequately/incompletely specified. Many MIB modules that are
standards-track RFCs represent the least common denominator. Vendors claim
compliance with them, yet have large proprietary MIB modules for all the
good stuff. Examples beyond the router/switch domain include for example
RDBMs modules. The issue is not the ability of the technology in this case
SNMP, to adequately represent what is needed. The problem is vendor
continued self-interest.

Please do not get these comments wrong. I have built a number of successful
management systems and the first thing to do is figure out the data and use
models. To fail to do so ensures bad performance and long term maintenance
and upgrade problems, not to mention the fact that the system will probably
not do what you wanted it to. While we will probably disagree from time to
time on the specifics, I firmly believe that a unified model of the network
is fundamental to building better management. I may not have expressed it
well since this is a non-technical problem that I do not know how to solve,
but I believe its solution is fundamental to forward progress in the
management area.