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

[Glenn Mansfield Keeni <glenn@cysols.com>]

Mike,
    Thanks. We will go for option (b). I will make the changes
in the DESCRIPTION clauses of the conceptual row objects, and the
corresponding *AddressType and *Address objects. That seems to be
straightforward.

    Glenn

C. M. Heard wrote:
>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
>