Section 4.5 OID size limits

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

section 4.5 ends with

   written using the SNMP and so is unusable.  Hence table design MUST
   take the 128 sub-identifier limit into account.  In some cases it is
   practical to use size constraints on the index variables to enforce
   the limit, and their use is strongly RECOMMENDED in such cases.

And I know the Mike Heard likes that. I also know that we have been
strongly recommending (maybe even enforcing) that up till now when
we did MIB reviews.

But I doubt we have consensus on this. It has been discussed on
the mibs mailing list in the past as well. I thought that I 
personally perceived consensus to say something like:

   written using the SNMP and so is unusable.  Hence table design SHOULD
   take the 128 sub-identifier limit into account.  In some cases it is
   practical to use size constraints on the index variables to enforce
   the limit. In other cases it is desirable to not use the size 
   contraints because it might hurt later. So we RECOMMENDED to use 
   the size constraints when it makes good sense. In cases where it
   does not make sense, the DESCRIPTION clause should clearly conatin
   some guidelines for implementers and users on how to deal with
   the situation. For excample text like this:

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

Pls express your views on this so we can try to read consensus of
the MIB doctors. Once we do, we probably should also check it on
the mibs mailing list again.

Thanks,
Bert