Re: [802.1] MSTP MIB - mstpMapTable

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Tue, Sep 06, 2005 at 08:56:12PM +0300, Romascanu, Dan (Dan) wrote:
 
> However, my intention in bringing this issue to mreview was different.
> Taking into account that 3417 allows agents to support only 484 bytes,
> should we not at least warn   the MIB designers and reviewers upon this
> fact?

Dan, looking at the size of single MIB objects is actually missing the
point for several reasons. What is the typical size of the SNMPvx
header to assume? What is the length of the OID to assume, especially
if the object is in a fancy indexed table? Are there other related
objects that must be read/written/notified in an atomic operation?

So even if we would strictly enforce the 484 limit (which seems like
walking backwards to me), we would need a quite good machinery to
actually check such 484 violations automatically.

Note that smidump support a -f sizes option for some time. You can to
an experiement yourself to find out which are the bytes needed to
encode rows (with and without default values) and notifications. 

Please make up your mind what the state of the art is. My analysis of
some 800+ MIB modules has been published at IM 2005 and it seems that
MIB authors pay some attention that notifications fit into ~484 byte
PDUs but less so for rows in conceptual tables. (No, don't try to tell
me that proper MIB design ala RowStatus dribbling mode can be used to
solve these problems without first talking to your management
application code writers what they think about this.)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany