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

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

On Mon, 14 Apr 2003, Harrie Hazewinkel wrote:
> 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.

In draft-ietf-sigtran-sctp-mib-09.txt there is only one object to
which that proposal applies.  That object is sctpAssocRemPrimAddr,
which is a readable column in sctpAssocTable but is an index in
sctpLookupRemPrimIPAddrTable.  If sctpAssocRemPrimAddr ever did
have a length > 114 bytes it could be read by walking through
sctpAssocTable but then the corresponding row in the
sctpLookupRemPrimIPAddrTable could not be retrieved.  So, it's
not just a "potential" problem.

Note that there are two other InetAddress index objects in
draft-ietf-sigtran-sctp-mib-09.txt, namely sctpAssocLocalAddr
and sctpAssocRemAddr.  These are auxiliary objects already so
the proposal doesn't apply to them.

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

If this is seen as an issue, then the solution is to document the
constraints that the index object lengths must satisfy through means
other than explicit SIZE constraints.  Here was the language that
was recently proposed for the InetAddress TC DESCRIPTION clause in
RFC 3291bis:

       When this textual convention is used as the syntax of an
       index object, there may be issues with the limit of 128
       sub-identifiers specified in SMIv2, STD 58. In this case,
       the object definition MUST include a 'SIZE' clause to
       limit the number of potential instance sub-identifiers
       or else the applicable constraints MUST be stated in the
       appropriate conceptual row DESCRIPTION clauses or in the
       surrounding documentation if there is no single DESCRIPTION
       clause that is appropriate.

Note that draft-ietf-sigtran-sctp-mib-09.txt doesn't document the
size constraints as suggested above;  it just documents the fact
that MIB compiler warnings may appear, which is substantially less
useful.

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

That's not needed.  You can already constrain the allowed types of
an InetAddressType object, and put the SIZE constraint appropriate
to the allowed type values on the associated InetAddress objects. Of
course, doing so is appropriate only if you are _sure_ that the MIB
objects you are defining won't ever need to acccomodate new address
types.  The whole issues arises when you are not so sure;  the
advice in RFC 3291 is to document (through SIZE constraints or
otherwise) the constraints imposed by the structure of your MIB
module and the 128 sub-id limitation of the SNMP, and relegate all
the rest of the subsetting to conformance statements.

//cmh