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

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

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