[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