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

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Cc: "Glenn Mansfield Keeni" <glenn@cysols.com>
> Sent: Thursday, October 07, 2004 7:31 PM
> Subject: InetAddressType/InetAddress usage in draft-ietf-mip6-mipv6-mib-04.txt
...

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

I think the answer depends on whether application to different IP
versions is merely "unlikely" as you put it, or closer to "improbable",
"impossible" or "silly".

Regardless of how "unlikely" it is, I do agree with the characterization
of using InetAddressType with such tight constraints as "perverse".

If future-proofing is what is intended, then the constraint should be moved
from the OBJECT-TYPE description to the conformance material.  If this
is intrinsically tied to IPv6, then I agree that one of the v6-specific types
would make more sense.

Randy