Re: InetAddressType/InetAddress usage in draft-ietf-mip6-mipv6-mib-04.txt

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

On Sat, 9 Oct 2004, Glenn Mansfield Keeni wrote:
>      The immediate target of the proposed MIB module is is the MIPv6 -
> there is no doubt [about] that. But, there are two possibilities that we
> thought of at the design stage -servicing MIP(v4) and MIPv* ( later
> versions that may come up).
>      In this context I would appreciate advise on what would be a better
> approach -
>      a) forget about possibilities - focus on MIPv6. Stick to ipv6(2) and
>         ipv6z(4). Instead of the InetAddressType/InetAddress we use
>         InetAddressIPv6 or InetAddressIPv6z types, as appropriate
>      b) make provisions for other stacks. Retain InetAddressType/InetAddress
>         pairs. Use compliance clauses to handle the MIPv6 stack - define IPv6
>         compliances for now. Add compliances later.
>         In this case what would be description of the corresponding MOs
>         look like ( in the context of the size of the MO)?
>         Would it be something like
>         "The size of this object will be determined by the value of the
>          corresponding InetAddressType object in the implementation. In
>          case of MIPv6 stack implementations the value will be ipv6(2)
>          and as such the size of this object is 16 octets.
>         " ?

Ultimately, this is a judgment call that you must make, but if you
think that it will be possible to support other MIP versions with
this MIB module, then you should probably choose option (b).

If you go that route, my recommendation would be to phrase the
DESCRIPTION clauses of the InetAddressType/InetAddress objects so
that you don't need to modify them at all.  You can do so by
eliminating all talk of what address types are supported in the
definitions of the index objects themselves, and instead stating in
the conceptual row object definition what constraints on index sizes
must be observed.  The messages from smilint report will help you do
that.  Here is how.

Using mip6MnBLEntry as an example, we see that there are two
InetAddress objects mentioned in the INDEX clause.  Their underlying
type is OCTET STRING (SIZE(0..255)), so the sum of their sizes can
go up to 510 octets.  According to the smilint report this would
cause the column instance OIDs to exceed the limit by 399 sub-IDs.
So to avoid OID overflow the sum of the sizes should not exceed 510
- 399 = 111 octets.  This can be documented by adding the text
marked with '+' to the mip6MnBLEntry DESCRIPTION clause:

       mip6MnBLEntry OBJECT-TYPE
           SYNTAX      Mip6MnBLEntry
           MAX-ACCESS  not-accessible
           STATUS      current
           DESCRIPTION
                   "Information about a Binding Update send by the
                    mobile node to a either to its home agent or one of
                    its correspondent nodes.

+                   Implementors need to be aware that if the total
+                   number of octets in mip6MnHomeAddress and
+                   mip6MnBLNodeAddress exceeds 111 then OIDs of column
+                   instances in this row will have more than 128
+                   sub-identifiers and cannot be accessed using
+                   SNMPv1, SNMPv2c, or SNMPv3.
                   "
           INDEX { mip6MnHomeAddressType,
                   mip6MnHomeAddress,
                   mip6MnBLNodeAddressType,
                   mip6MnBLNodeAddress
                 }
           ::= { mip6MnBLTable 1 }

You would then want to remove the phrase

                     The only allowed type for this object is ipv6(2).

from the DESCRIPTION clauses of the InetAddressType objects, and the phrase

                    Note that the only allowed type for this object is
                    ipv6(2) and as such the size of this object is 16
                    octets.

from the DESCRIPTION clauses of the InetAddress objects.

This is the approach used for inetCidrRouteEntry in the IP-FORWARD-MIB
(see draft-ietf-ipv6-rfc2096-update-07.txt) and in several other recent
MIB modules.  I'll send you the smilint report unser separate cover.

Please let us know if you have more questions about this.

Thanks,

Mike