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

Re: snmpconf FW: November Milestones



 From a thread from the snmpconf WG:
 > Jon wrote:
 >> Configuration is the heart of management. To the extent MIB Documents
 >> are created in each of the different technology areas such as routing or
 >> differentiated services (which is the right place), they should be
 >> designed for full coverage including configuration. There is no excuse
 >> not to.
 >
Randy wrote:
 > i do not intend to discourage those who wish to design for write from doing
 > so.  but i am not sure i see a need to mandate it when doing so would cause
 > complexity or architectural change.  and i believe that, and only that, was
 > the question (in the tewg) that [re]started this rathole.
 >
 > randy

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