[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DS MIB - please review this list...
- To: Bill Fenner <fenner@research.att.com>
- Subject: Re: DS MIB - please review this list...
- From: Fred Baker <fred@cisco.com>
- Date: Mon, 26 Feb 2001 16:49:58 -0800
- Cc: daniele@zk3.dec.com, haberman@nortelnetworks.com, sar@epilogue.com, schoenw@ibr.cs.tu-bs.de, mibs@ops.ietf.org, brian@hursley.ibm.com, khchan@nortelnetworks.com, nichols@packetdesign.com, andrew@allegronetworks.com
- Delivery-date: Mon, 26 Feb 2001 17:19:43 -0800
- Envelope-to: mibs-data@psg.com
>Bill> A related question: if there are multiple addresses in a given
>Bill> table row, where all of these addresses must be the same type
>Bill> because of the way the thing being managed works, do you have to
>Bill> have an InetAddressType for each?
>
>I would say yes. And I would even strongly suggest that the
>InetAddressType and the InetAddress columns sit next to each other in
>the order (InetAddressType, InetAddress). This rule will ensure that
>generic managers will be able to understand the relationship between
>these objects (which we unfortunately can't represent formally in the
>SMIv2).
That is just silly.
A generic manager doesn't know that the type of the address object is
InetAddress apart from having read a MIB in; it otherwise looks like an
OCTET STRING. It therefore does not know to look at the object numerically
before in order to get the type, apart from having read in a MIB. If it can
read in a MIB, it can find the InetAddressType in the entry and associate
it with all of the InetAddress objects in the entry.