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

["C. M. Heard" <heard@pobox.com>]

On Fri, 27 Dec 2002, 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.

Agreed.  There is also a corresponding requirement in SMIv2.

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

RFC 2578 does not require that OCTET STRING and OBJECT IDENTIFIER
valued index objects be given a SIZE clause.  So the most that the
guidelines doc could do is to recommend there SHOULD be a SIZE clause
on such objects to prevent instance names from exceeding 128 subids.

I guess what we are debating (in part) is whether the document should
make such a recommendation.

> 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 think we should give the MIB designer the option of either using static
SIZE restrictions or putting appropriate words in the DESCRIPTION clauses.

All other things being equal, I'd prefer to see static SIZE restrictions
to enforce the 128 subid cap.  But it's easy to see that there are cases
where this will not work because it will be too strict.  Specifically,
when there are multiple indices it is the sum of the sizes that needs to
be constrained, and that constraint cannot be properly expressed by SIZE
restrictions on the individual components.  I guess the APM-MIB is one of
these cases when all other things are NOT equal, and static SIZE
restrictions hurt more than they help.

One other point:  in cases where a MIB module does NOT use static SIZE
restrictions and a user (aka management application) needs to be careful
not to create index items that cause instance names to exceed the 128
subid limit, then the specification that contains that MIB module should
be very explicit in spelling out just what the application needs to do.
One example would be a table with multiple variable length indices that
have to satisfy a constraint on the sum of their sizes.  The specification
should state explicitly what that constraint is.  Constraints that
affect only one table should probably be stated in the DESCRIPTION
clause of that table's conceptual row;  constraints that affect items
in other tables might be best put in the narrative part of the spec.

Mike