SIZE restrictions for INDEX objects (to avoids more than 128 subIDs)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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.

Thanks,
Bert 

-----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