Re: RFC 2576 vs IPv6

On Wed, 19 Feb 2003, Randy Presuhn wrote:
> I think the analysis of RFC 2576 in section 5.070 (see below) of
> draft-ietf-v6ops-ipv4survey-ops-00.txt is incorrect.
> These rules for handling legacy data which happen to be
> IPv4 addresses have no bearing on the ability to operate
> in or manage IPv6 environments.

I agree with that, and the same comment applies to the analysis of
the Notification Log MIB:

   5.112 RFC 3014 Notification Log MIB

   This document contains OIDs that are IPv4 specific:

   nlmLogVariableIpAddressVal OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
        "The value when nlmLogVariableType is 'ipAddress'.
        Although this seems to be unfriendly for IPv6, we
        have to recognize that there are a number of older
        MIBs that do contain an IPv4 format address, known
        as IpAddress.

        IPv6 addresses are represented using TAddress or
        InetAddress, and so the underlying datatype is
        OCTET STRING, and their value would be stored in
        the nlmLogVariableOctetStringVal column."
       ::= { nlmLogVariableEntry 9 }


   Not withstanding the note in the DESCRIPTION.

The purpose of this object is to handle legacy data.  It is, in
effect a member of a discriminated union designed to handle
arbitrary SMIv2 data types (including the obsolete ones), and its
presence in no way indicates that the MIB module is inadequate for
IPv6.

//cmh