Re: terminology challenge

[Andy Bierman <abierman@cisco.com>]

At 08:30 PM 12/27/2001, rpresuhn-lists@dorothy.bmc.com wrote:
>Hi -

Hi Randy,


>> Date: Tue, 18 Dec 2001 18:25:36 +0100
>> Message-Id: <200112181725.fBIHPau24391@haerke.ibr.cs.tu-bs.de>
>> From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
>> To: abierman@cisco.com
>> Cc: sming@ops.ietf.org
>> In-reply-to: <4.3.2.7.2.20011218082524.01f4b180@fedex.cisco.com> (message from
>>       Andy Bierman on Tue, 18 Dec 2001 08:51:13 -0800)
>> Subject: Re: terminology challenge
>> References: <4.3.2.7.2.20011217095939.01ef6e00@fedex.cisco.com>
>>  <4.3.2.7.2.20011215130827.01e7d6e8@fedex.cisco.com>
>>  <4.3.2.7.2.20011215130827.01e7d6e8@fedex.cisco.com>
>>  <4.3.2.7.2.20011217095939.01ef6e00@fedex.cisco.com> <4.3.2.7.2.20011218082524.01f4b180@fedex.cisco.com>
>..
>> Containment is not exactly the same as inheritance. And this does not
>> really look C-like either. ;-)
>..
>
>One of the things that bothers me about all the proposals
>(and perhaps this is just because I spent too much time in
>CMIP-land) is that we haven't been making a clear distinction
>between an object having attributes and an instance of an
>object being (logically) contained in another object instance.
>Instead, the SMI compells us to think in terms of INDEX
>clauses, which, if inherited, make my head ache when I think
>about scoping.
>
>Some of the examples of arrays of elaborate structs with
>complexly indexed attributes really seem like a kludgy way
>of representing object containment.  Perhaps the need to
>talk about other ways of encoding indexing information is
>just a symptom of the need to properly address representing
>containment, and not just the construction of elaborate
>type definitions.


If you are talking about the DSMON counter aggregation profile
example, then I tend to agree with you, because this is a bad example
for type reuse.  It's a good example of a real data structure needed
by a real application. In the SMI-DS draft, the DSMON example was
more complicated than necessary to demonstrate the instance naming
and syntax. 

The real dsmonAggProfile struct type definition is:
  - 3 scalars
  - 1 array of 64 DSCP to N aggGroup mappings
  - 1 optional array of N aggGroup descriptors

The dsmonAggProfileTable array variable declaration is:
  - 1 array of M dsmonAggProfile structs

This matches the terminology and data model for the C language.
We have more than a terminology gap in SMING -- the terminology is
gap is really a data modeling gap.

I've been saying for years that MIB objects provide the wrong level
of abstraction to be used efficiently by applications. We have no
real transaction PDUs, so every operation has to be 'cast' as a
set of peeks and pokes to individual variables. This assembly language
transaction model, the tabular SMI data model, and the
added complexity of the 'dribble-input', mix-and-match, Set PDU,
make SNMP too inefficient and uneconomical for developers to use.

We need an SMI that can express real data structures, a
protocol with high level transactions, such as "create object",
even if the parameters for the transaction require a megabyte
of data to express, and then we need a TCP-based transport
instead of hacking the transport features into SNMP or EOS.

I think we can approach the problem on two fronts. There are
the low-level building blocks to create (like GenericCounter),
and the high-level OO-like classes that define data structures
and method routines for using that data, supported by high-level 
transaction PDUs in EOS.  (The old, concurrent top-down, 
bottom-up, meet-in-the-middle game plan :-)

Andy




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