Re: SIZE restrictions for INDEX objects (to avoids more than 128 subI Ds)

[Andy Bierman <abierman@cisco.com>]

At 10:40 PM 12/27/2002 +0100, Wijnen, Bert (Bert) wrote:
>I am not sure we ever finished the discussion on this on the
>MIBS mailing list. But I would like to see if we have consensus 
>here. I want that for 2 reasons.
>- one is that I am currently reviewing APM MIB that has the issue
>- 2nd is that we should write something about this in the mib review 
>  document that Mike HEard is working on.
>
>So... I know that the SNMP protocol currently has max 128 subids.
>I don't think we want to dive in and change that at this point.
>
>the question is if we want to ENFORCE that INDEX objects are
>checked that together they will NEVER exceed 128 subids.
>
>I am starting to be inclined to not require that enforcement.
>In quite a few cases we have been "forcing" for arbirtrary and strange
>SIZE values so as to make sure it never can get over 128 subids.
>That is kind of goodness. But is it required?
>I find that:
>- in many cases, the current most prevalent use of such objects is such
>  that we will not exceed the 128 subids. 
>  So no absolute need to add the restriction.
>- in the future, it may bite us... 
>So why not do sonmething else instead.
>
>Require that the DESCRIPTION clause of such objects contains some
>words that 
>- This index may theoretically result in OIDs that would be more than 128 subids
>- In current practice, nobody would use that capability
>- in fact users of this table should be very carefull to not create index.items
>  that cause OIDs to be more than 128 subIDs, because current SNMP (formally) 
>  cannot handle it.

I like this proposal a lot.


>Thanks,
>Bert 

Andy



>-----Original Message-----
>From: Andy Bierman [mailto:abierman@cisco.com]
>Sent: woensdag 7 augustus 2002 3:51
>To: David T. Perkins
>Cc: mibs@ops.ietf.org
>Subject: Re: [RMONMIB] smilint messages for APM-MIB
>
>
>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