[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OIDs longer than 128 subids for InetAddress indexes

On Sun, 27 Nov 2005, Wijnen, Bert (Bert) wrote:
> Dan Romascanu recently commented during MIB doctor review:
> 
>    14. The DESCRIPTION clause of tcpEStatsConnectLocalAddress 
>        and tcpEStatsConnectRemAddress still mentions SNMPv1, 
>        SNMPv2c and SNMPv3. The first two are Historical, 
>        SNMPv3 is the recurrent standard track version of SNMP,
>        the text should be replaced by simply 'SNMP'. 
> 
> Dan is correct, but we have (iirc) allowed such text as in this case:
> 
>         As this object is used in the index for the
>         tcpEStatsConnectIdTable, implementors of this table should
>         be careful not to create entries that would result in OIDs
>         with more than 128 sub-identifiers; else the information
>         cannot be accessed using SNMPv1, SNMPv2c or SNMPv3."
> 
> In earlier MIB documents.
> I personally can live with that. 
> Otehr opinions?
> Just trying to see if we can get consensus on this so we can
> be consistent in our feedback on MIB reviews.

I think I am the culprit responsible for the "cannot be accessed
using SNMPv1, SNMPv2c, or SNMPv3" wording.  I crafted it in response
to the following comments from Bert in a message to this list sent
on 27 December 2002 (see attachment for full text):

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

and (if my records are correct) first recommended it on 5 Jul 2003
in a message to the author of draft-ietf-ipv6-rfc2096-update.  I
have been recommending it ever since.  I think it ended up getting
used in all the pending or recently published IPv6 WG MIB modules,
and it is also in the ISIS-MIB.

The reason why I crafted the text the way I did was because I took
the "in the future, it may bite us" to mean that an SNMP version
without the 128 sub-ID restriction might actually appear someday,
and I wanted text that would not become obsolete in that case.  As I
recall, the EOS effort was still alive at that point, so it was
(maybe) a realistic concern at that time.  However, that is probably
not the case anymore.  The chances of ever having another SNMP
version are somewhere between slim and none.

Maybe the right way to handle this is not to hassle authors who are
currently using that text but to change what we recommend in the
future along the lines Dan suggests.

Mike
--- Begin Message --- 
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

--- End Message ---