Re: Latest posted agenda for SMIng meeting at the 49th IETF...

[rpresuhn-lists@dorothy.bmc.com]

Hi -

I'm re-posting this message, since the sming@ops.ietf.org
list insists that I forge my "from" address.

> To: "Durham, David" <david.durham@intel.com>
> Cc: "'Wes Hardaker'" <wes@hardakers.net>,
>         "David T. Perkins" <dperkins@dsperkins.com>, sming@ops.ietf.org
> Subject: Re: Latest posted agenda for SMIng meeting at the 49th IETF...
> References: <10C8636AE359D4119118009027AE998704F39C7E@FMSMSX34>
> From: Wes Hardaker <wes@hardakers.net>
> Date: 08 Jan 2001 13:06:26 -0800
> In-Reply-To: <10C8636AE359D4119118009027AE998704F39C7E@FMSMSX34>
> Message-ID: <sdn1d1ah4d.fsf@wanderer.hardakers.net>
..
> I've been surprised that no-one else has joined the conversation.  I'd
> expected more people to come forward and tell me it was a bad idea
> because they'd have to write too much new code (even though in the end
> they'd write less, imho).
..

In my opinion, the proposed inheritance model is both too
much and too little.

The limitation to single inheritance unnecessarily restricts
the class definer's ability to re-use existing bundles of
functionality.

The ability for a derived class to change the semantics of
an inherited attribute seems to be counter to the whole
notion of inheritance, particularly since the i-d talks
about specifications being "overwritten" rather than the
"refined" one might expect if changes were permitted at all.

The kind of "partial inheritance" that came up in the WG
session in San Diego is just asking for more trouble than
it could possibly be worth, in my opinion.  It would only
be of use for "reverse-engineering" existing MIB definitions,
and still begs the questions of getting the object identifiers
to come out right.  (Consider as a concrete examble RFC 2665,
which has gaps in the oids assigned to table columns.)

I'm trying to keep an open mind about all this, but if we
go with this new language, I think we'll have to make some
hard choices about how far we go to make it easy to support
existing MIBs.  The more we bend the language to make it
easy to say the kinds of things that have already been said
using the MIB notation (though we may now perhaps wish that
we hadn't), the harder it will be to use it to express what
we'd like to.

I suspect that we'll end up having to provide a mechanism
for the designer to assign specific object identifiers
to attributes when a class definition is used (not to be
confused with instantiation).   (It's oh-so-much-simpler
in the CMIP world.  There, an attribute has its own
object identifier, independent of whatever classes make
use of that attribute.)

 -------------------------------------------------------
 Randy Presuhn           randy_presuhn@bmc.com
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------