Re: augmenting std MIBs to use TransportAddress

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

Hi -

(I'm CC-ing the disman WG list since this thread
raises questions about RFC 3014.)

> Message-Id: <4.3.2.7.2.20030414124409.02463c48@fedex.cisco.com>
> Date: Mon, 14 Apr 2003 13:04:27 -0700
> To: mreview@ops.ietf.org
> From: Andy Bierman <abierman@cisco.com>
> Subject: augmenting std MIBs to use TransportAddress
> Cc: kzm@cisco.com
>
> Hi,
>
> I have a couple of Cisco MIB reviews that are augmentations
> of the NOTIFICATION-LOG-MIB (RFC 3014) and SNMP-TARGET-MIB
> (RFC 3413).  I'm having a little trouble interpreting sec
> 3.1.2 of RFC 3419.  These augmentations are 'replacing'
> the TAddress and TDomain objects with TransportAddress
> and TransportDomain objects.  The objects getting replaced:
>
> nlmLogEntry:
>     nlmLogEngineTAddress       TAddress
>     nlmLogEngineTDomain        TDomain
>
> snmpTargetAddrEntry:
>     snmpTargetAddrTDomain      TDomain
>     snmpTargetAddrTAddress     TAddress
>
> Q1) RFC 3014 seems to imply that we should use the old objects
>     for existing TAddress/TDomain values and use the new objects
>     for new values that TAddress/TDomain doesn't cover.  I think
>     this is broken.  I am telling the MIB designer to let the
>     new objects override the old ones if they are set, and
>     use the old objects if the new ones are not set.  Is this
>     what the last paragraph of 3.1.2 is suggesting (and I'm
>     just reading it wrong)?

I believe that paragraph is refering to the Object Indentifier
*values* defined in RFC 3419, not to the TCs.  I see no reason
to replace / override the objects in 3413 or 3014, and I think
the text in 3419 confirms this belief.

> Q2) What is the IETF plan for upgrading MIBs which use the old
>     TAddress/TDomain data types to use the types in RFC 3419?

I think the last paragraph in 3419 3.1.2 answers this: they
should continue to use the definitions from RFC 2579, along
with the specific object identifier values from 3419 as needed.

> thanks,
> Andy
>
>
>

Randy