[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DS MIB - please review this list...
- To: fred@cisco.com
- Subject: Re: DS MIB - please review this list...
- From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
- Date: Fri, 2 Mar 2001 16:46:16 +0100
- CC: mwdaniele@adelphia.net, bwijnen@lucent.com, brian@hursley.ibm.com, fenner@research.att.com, daniele@zk3.dec.com, haberman@nortelnetworks.com, sar@epilogue.com, mibs@ops.ietf.org, khchan@nortelnetworks.com, nichols@packetdesign.com, andrew@allegronetworks.com
- Delivery-date: Fri, 02 Mar 2001 07:56:01 -0800
- Envelope-to: mibs-data@psg.com
>>>>> Fred Baker writes:
Fred> Explain to me why (as in, answer the argument I made, rather
Fred> than simply trying to nullify it) when the reason there are two
Fred> InetAddress objects in an entry for the purpose of describing
Fred> either an IPv4 or an IPv6 header, having two InetAddressType
Fred> objects, and specifically having them located numerically before
Fred> the InetAddresses, produces a benefit?
I think we agree that you can only interpret an InetAddresses value if
you know the corresponding InetAddressType. And I think we also agree
that we have this construction since we the current SMI does not allow
us to express a discriminated unions in a single variable.
You are asking what the benefit is of having the discriminating
InetAddressType object registered directly before the InetAddress
object (the union). The benefit here is that an application can
(whether that is an agent code generator or a generic manager) can
identify the discriminating InetAddressType for a given InetAddress
union automatically.
Now you can look at this from different viewpoints:
(a) I don't care about this because my tools are not going to take
advantage of it anyway.
(b) I do agree that there are at least some benefits, but I am not
willing to pay the price of an additional column or index
component in cases where you have multiple InetAddress objects of
the same InetAddressType. Perhaps a slightly improved set of rules
would make me feel happier (e.g. just require that the
discriminating object is the last InetAddressType registered
before the InetAddress - which I think would handle the diffserv
filter case).
(c) I generally dislike to impose rules like these on SMIv2 MIB
designers that make the implementation of generic tools easier.
(d) I don't care at all.
There might be more possible positions. I am sure we will find out.
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>