RE: DS MIB - please review this list...

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Can we get some more viewpoints in this pls.
There must be other MIB/SMI biggots who have an opionion
on this, right?

Thanks,
Bert (AD hat on)

> ----------
> From: 	Juergen Schoenwaelder[SMTP:schoenw@ibr.cs.tu-bs.de]
> Sent: 	Friday, March 02, 2001 4:46 PM
> To: 	fred@cisco.com
> 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
> Subject: 	Re: DS MIB - please review this list...
> 
> 
> >>>>> 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/>
> 
> 
> 
>