[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: snmpconf FW: November Milestones
Some of the info modeling work may be pertinent here. Some of the models
separate state and current operational data from configuration information.
The latter is described by Setting classes and collected into Configuration
aggregations. You can send clearly defined Setting classes and instances to
a device. You can "apply" these Settings to a device and/or its components.
You can retrieve (read mostly) current state/operational data from other
classes and instances.
From: email@example.com [mailto:firstname.lastname@example.org]On Behalf
Of Jon Saperia
Sent: Monday, December 04, 2000 5:46 AM
Cc: diffserv; Randy Bush
Subject: Re: snmpconf FW: November Milestones
> Randy's point is well made - I don't think it is a rathole - and is
> relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv
> the various iterations of the diffserv MIB we have veered between extremes
> optimise-for-read and optimise-for-configure without, I think, a clear
> why. The -04 version tended towards the former whilst the latest
> (-06) veers back towards the latter in the interests of consistency with
> work and the "template" concept for the diffserv policy MIB (snmpconf WG).
> Should we treat these as valid reasons to sacrifice read performance or
> we find another way to optimise opbjects for configuration e.g. by
> (indexing of same information in multiple ways)? Right now, I believe
> MIB does cause additional complexity for reading.
It is often the case that read only MIB documents are not well designed
in a number of respects. Relevant to this discussion is that the indices
are often created with implementation ease in mind. It is more difficult
to implement a table with multiple indices (regardless of basic
technology) than to use simple integer index values. This is true
whether the objects are read only or read write. This poor design,
while easy for software engineers, causes unnecessary data collection
overhead since it is more difficult to 'scope' what you want to retrieve
(Randy indirectly alluded to this in a previous post). In some cases,
the design makes it quite difficult not mater how much data you collect
to understand what it means in terms of the configuration.
My view is that the additional complexity for configuration will pay off
in terms of better quality data and less data movement. This is not to
say -06 is just right, there are other who can better assess that. My
point is that it is worth the work.