[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIZE constraint language for InetAddress index objects indraft-ietf-ops-rfc3291bis-01.txt
On Tue, 8 Jul 2003, Juergen Schoenwaelder wrote:
> I have changed the text as you suggested.
Thanks.
> However, I think that the 128 subidentifier limit always has the
> potential to hit you hard since you never know which MIB module
> in the future will expand a given table by adding more index
> components.
Indeed; if related MIB modules with common variable-length
indices reside in multiple documents, then the implementor will
have to be very careful to adhere to the most restrictive
constraint. Also, MIB authors and reviewers would be well-advised
to carefully document when extention modules require index size
constraints that are tighter than those in the base module.
> If you calculate the max. possible size for a given table index,
> you basically make tables with expanded indexes impossible
> (which is not really good). I guess we agree on that.
Yes. This is a good reason NOT to use arbitrary SIZE constraints,
and instead DESCRIBE the constraints. Lately I have been
recommending the use of language like this:
Implementors need to be aware that if the total
number of elements (octets or sub-identifiers)
in inetCidrRouteDest, inetCidrRoutePolicy, and
inetCidrRouteNextHop exceeds 111 then OIDs of
column instances in this table will have more
than 128 sub-identifiers and cannot be accessed
using SNMPv1, SNMPv2c, or SNMPv3.
This does not artifically restrict any index sizes; it just states
the facts.
Mike