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

Re: snmpconf FW: November Milestones

> Randy's point is well made - I don't think it is a rathole - and is directly 
> relevant to the MIB/PIB/snmpconf/DSMON discussions for diffserv management. In 
> the various iterations of the diffserv MIB we have veered between extremes of 
> optimise-for-read and optimise-for-configure without, I think, a clear idea of 
> why. The -04 version tended towards the former whilst the latest incarnation 
> (-06) veers back towards the latter in the interests of consistency with the PIB 
> work and the "template" concept for the diffserv policy MIB (snmpconf WG). 
> Should we treat these as valid reasons to sacrifice read performance or should 
> we find another way to optimise opbjects for configuration e.g. by duplication 
> (indexing of same information in multiple ways)? Right now, I believe the -06 
> MIB does cause additional complexity for reading.
> Andrew

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.