Re: [RMONMIB] smilint messages for APM-MIB

[Andy Bierman <abierman@cisco.com>]

At 06:00 PM 8/6/2002 -0700, David T. Perkins wrote:
>HI,

(removing rmonmib from the cc: list)

There is no issue with the range of a sub-OID being that of an Unsigned32.
It is an issue (that comes up over and over) that 128 sub-OIDs is
too low a value to allow for the complex INDEX clauses that occur
in some MIBs.  This may have been relatively valid reasons for
adding this rule back when, but operational experience is indicating
that the particular value (128) is too restrictive. We can choose to
do nothing about it, wait 5 or 10 years until SNMP dies altogether,
or fix it ASAP.  

We are a little off track on this discussion. The related discussion
is whether SIZE clauses should be mandatory for string objects.
I don't like the practice of selecting an arbitrary max-value just
so every string INDEX component has a range.  There are cases
where the max value depends on other objects (like in APM-MIB).

Andy


>On the issue of 128 sub-ids (and max sub-id value of 2^32-1), it was
>added to improve interoperation.
>
>At the time it was added, there were interoperation problems of agents
>and management apps. Some implementations (I seem to remember the
>early CMU was like this) had OID sub-id values that the max range
>was 2^16. The MIT agent supported values that were upto 2^32-1.
>Many SNMP API developers required pre-allocation of OID values
>of a fixed size array, and needed to "know" the max number of
>sub-ids for the #define used to set the size of the array.
>
>This issue of static vs dynamic, and then if static, what is the
>max size comes up all the time in designs related to computers.
>
>The "only" consideration that was done for MIB compilers was to
>cap the range at 2^32 so that "a big number" library wasn't needed
>in compilers (because at the time, "unsigned long long" support
>was not generally available in the current C compilers.)
>
>-- dave's opinion --
>And by the way, I'm really grossed out by the way all SNMP APIs
>that I've seen process and store OIDs. They all waste huge amounts
>of space. If the range for sub-id values is modified
>to be "unbounded", and the number of sub-ids is modified to be
>"unbounded", then things will change. Maybe it will result in
>better SNMP API for OIDs, or maybe just more grossness.
>-- end of opinion --
>
>Regards,
>/david t. perkins