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

[David Harrington <dbh@enterasys.com>]

Hi,

I haven't been involved in the InetAddress work, but I realize it grew
from SNMPv2 transport mappings.

I don't remember why NetworkAddress was deprecated in SMIv2. It seems to
me that if we want a tagged address, or a discriminated union, that
NetworkAddress did just that using one extra byte in the Octet String,
rather than as a separate InetAddressType object. On the face of it, the
NetworkAddress approach seems simpler.

Can somebody refresh our collective memories about why NetworkAddress
was deprecated? Does the InetAddress approach avoid the problem of
NetworkAddress, and provide a more flexible, easier to maintain address
type?

dbh

"Wijnen, Bert (Bert)" wrote:
> 
> 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/>
> >
> >
> >
> >

-- 
---
David Harrington            Network Management Standards Architect
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA