[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Stream Control Transmission Protocol Management Information Base to Proposed Standard
On Monday, April 14, 2003, at 10:38 AM, Juergen Schoenwaelder wrote:
C M Heard writes:
Mike> Specifically, the InetAddress objects in this MIB module that
Mike> are used as indices appear as the only variable-length index
Mike> object, and all of the tables where InetAddress object appear in
Mike> the INDEX clause have similar index structure. So in every case
Mike> constraining the size to 114 octets fixes the problem.
Well, I do not want to beat a dead horse again, but there is still an
issue if you want to expand the table in the future with another table
that needs additional index columns. The 128 subid limit really sucks
and wherever we put size constraints in place to accomodate this
unfortunate SNMP limitation, we create problems for the future.
Is a reasonable way around this to define the objects in the
table used and put size constraint only applicable for the
local table?? The description could say the object has an equal
value as the original one, but applies size-constraints.
Since the object is part of an index and thus not-accessible
it could be an option. OK, I admit there is a potential
to have different values due to length differences
and creates as such different future problems.
But it leaves the option open to use it in a different
table as part of an index where again different size-constraints
Or there is a need for an InetAddress TC that only allows
an IPv4 or IPv6 type and not the dns type. Then sizes are
known and smaller.
(thinking out loud to come up with some solution)