The complaint is not that "the use of attributes breaks SNMP." The
complaint is that the use of attributes like this is really not SNMP. As
Paul M. says, SNMP has a clear, central model for representing
objects/attributes and values thereof, and this attributes table approach
does not follow the SNMP model. Instead, it uses SNMP as a mere framework
or platform on top of which to build a significantly different attributes
and values representational model. And it does this without benefit of
appropriate documentation or standards or infrastructure or technical
support or tooling or diagnostics or any of the zillion things that are
normally expected when a new standard data representational model is
established. (Does anybody have a MIB browser that will do a useful job of
browsing attributes tables? I'd be very surprised - albeit pleasantly so.)
It is conceivable that this attributes-table poor solution (poor because
unsupported, as above) is the best available under the circumstances, that
all the other available choices are worse. However, it is inappropriate
behavior on the part of a standards body to choose such a course, to go
charging off into wild new territory, without first at least clearly
recognizing the problems that it entails and clearly considering the
alternatives. I don't think I ever saw that done here. I lacked the time
and energy to raise the issue myself here. Paul M. is now raising it.
Of course it is rather late to be raising this issue in connection with the
FIN or the JOB MIBs. This issue was timely for those a year and two ago.
But the point is still well taken.
/Paul Gloger