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

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

Mike,
    I agree that the present InetAddressType/InetAddress usage does
not look right.
    The immediate target of the proposed MIB module is is the MIPv6 -
there is no doubt aout 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.
       " ?

    Thanks

    Glenn


C. M. Heard wrote:
>MIB Doctors --
>
>I am doing a 2nd pass review of the MOBILEIPV6-MIB, which resides in
>http://www1.ietf.org/internet-drafts/draft-ietf-mip6-mipv6-mib-04.txt,
>and I'd like to get your opinions on the InetAddressType/InetAddress
>pairs in that draft.  Specifically, although the definitions are not
>subtyped, there is restrictive language in the DESCRIPTION clauses
>that has the same effect.  For example:
>
>     mip6BindingCacheEntry OBJECT-TYPE
>        SYNTAX      Mip6BindingCacheEntry
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>                "An entry in the binding cache table. It represents a
>                 single Binding Update.
>                "
>        INDEX  { mip6BindingHomeAddressType, mip6BindingHomeAddress }
>        ::= { mip6BindingCacheTable 1 }
>
>     Mip6BindingCacheEntry ::=
>        SEQUENCE {
>         mip6BindingHomeAddressType   InetAddressType,
>         mip6BindingHomeAddress       InetAddress,
>         mip6BindingCOAType           InetAddressType,
>         mip6BindingCOA               InetAddress,
>         mip6BindingTimeRegistered    DateAndTime,
>         mip6BindingTimeGranted       Gauge32,
>         mip6BindingTimeRemaining     Gauge32,
>         mip6BindingHomeRegn          TruthValue,
>         mip6BindingMaxSeq            Unsigned32,
>         mip6BindingUsageTS           DateAndTime,
>         mip6BindingUsageCount        Counter32,
>         mip6BindingAdminStatus       INTEGER
>        }
>
>    mip6BindingHomeAddressType OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>                "The InetAddressType  of the mip6BindingHomeAddress
>                 that follows.
>                 The only allowed type for this object is ipv6(2).
>                "
>        ::= { mip6BindingCacheEntry 1 }
>
>    mip6BindingHomeAddress OBJECT-TYPE
>        SYNTAX      InetAddress
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>                "The home address of the mobile node for which this
>                 is the Binding Cache entry.  This field is used as
>                 the key for searching the Binding Cache for the
>                 destination address of a packet being sent.
>
>                 The type of the address represented by this object
>                 is specified by the corresponding
>                 mip6BindingHomeAddressType object.
>
>                 Note that the only allowed type for this object is
>                 ipv6(2) and as such the size of this object is 16
>                 octets.
>                "
>        REFERENCE
>                "RFC3775 : Section 9.1"
>        ::= { mip6BindingCacheEntry 2 }
>
>    mip6BindingCOAType   OBJECT-TYPE
>        SYNTAX      InetAddressType
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>                "The InetAddressType of the mip6BindingCOA that
>                 follows.
>                 The only allowed type for this object is ipv6(2).
>                "
>        ::= { mip6BindingCacheEntry 3 }
>
>    mip6BindingCOA   OBJECT-TYPE
>        SYNTAX      InetAddress
>        MAX-ACCESS  read-only
>        STATUS      current
>        DESCRIPTION
>                "The care-of address for the mobile node indicated by
>                 the home address field (mip6BindingHomeAddress) in
>                 this Binding Cache entry. A mobile node can have
>                 multiple care-of-addresses.
>
>                 The type of the address represented by this object
>                 is specified by the corresponding mip6BindingCOAType
>                 object.
>                "
>        REFERENCE
>                "RFC3775 : Section 9.1"
>        ::= { mip6BindingCacheEntry 4 }
>
>All of the InetAddressType/InetAddress pairs are like this -- they
>are restricted to a single address type, which is either ipv6(2) or
>ipv6z(4).  This type of restriction is semantically equivalent to
>explicit subtyping in the SYNTAX clause and cannot be removed in
>future revisions, since that would be a semantic change.  So it
>certainly violates the spirit of the SHOULDs in RFC 3291bis.
>
>Now, this MIB module _is_ IPv6-specific, and it can be argued that
>application to different IP version is unlikely.  But even if that
>point is granted, it seems to me that this is a perverse way to
>define IPv6-specific address objects.  If that is really what is
>wanted, then it seems to me that a better approach would be to omit
>the InetAddressType objects altogether, and replace the InetAddress
>objects with objects of type InetAddressIPv6 or InetAddressIPv6z.
>
>Your comments would be appreciated.  If you do comment, I ask that
>you cc: the document author Glenn Mansfield Keeni <glenn@cysols.com>
>since he is not subscribed to the mreview list.
>
>Thanks & regards,
>
>Mike Heard
>