Re: Last Call: Stream Control Transmission Protocol Management Information Base to Proposed Standard

[Harrie Hazewinkel <harrie@lisanza.net>]

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

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)


Harrie