[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [802.1] MSTP MIB - mstpMapTable
Juergen,
I agree with your argumentation, I know that fitting notifications in
one PDU is not the only problem, and I know that enforcing the 484 limit
is not enough, and does not provide a non-fragmentation warranty. There
is however one basic issue, the fact that a >484 bytes OCTET string
object is an obvious case where no single set or get operation will
succeed in any situation, and this happens for classes of SNMP entities
defined as fully standard compatible by RFC 3417. No tools are needed to
see this contradiction, and my question is whether we want to mention
this case in the review guidelines, as we do for example with the OID
size limitations in Section 4.6.6.
Thanks and Regards,
Dan
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
> Sent: Thursday, September 08, 2005 2:51 AM
> To: Romascanu, Dan (Dan)
> Cc: David T. Perkins; Keith McCloghrie; bwijnen@lucent.com;
> mreview@ops.ietf.org
> Subject: Re: [802.1] MSTP MIB - mstpMapTable
>
> 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
>