RE: Meeting Minutes for the SMIng WG at the 49th IETF...

[rpresuhn-lists@dorothy.bmc.com]

Hi -

> From: "Andrea Westerinen" <andreaw@cisco.com>
> To: "John Strassner" <johns@cisco.com>,
>         "Durham, David" <david.durham@intel.com>,
>         <rpresuhn-lists@dorothy.bmc.com>, <sming@ops.ietf.org>
> Subject: RE: Meeting Minutes for the SMIng WG at the 49th IETF...
> Date: Sat, 30 Dec 2000 23:25:14 -0800
> Message-ID: <GGEOLLMKEOKMFKADFNHOEEDODBAA.andreaw@cisco.com>
> In-Reply-To: <003001c07290$092ee820$826c45ab@cisco.com>
> 
> Perhaps we should avoid the use of the word "partial".  My memory of this
> discussion was that some constructs of a class are required and others are
> optional/best effort (and this is clearly labelled).  Whether in the
> "independent of everything" info model, or the protocol/encoding specific
> implementations of the data models - optional versus required means the
> same.

"Partial inheritance" (or whatever we end up calling it, if we
don't reject the concept) appears to have been invented to make
it possible to explain existing MIBs using the new language.
The basic problem is that if an attribute doesn't exist in
the existing MIB, calling it "optional" or "best effort"
in the SMING "explanation" would seem a bit disingenuous.
An additional problem with such ex post facto definitions is
that it's hard to get the object identifier assignments to
come out right.

> This is different than inheritance, and also different than saying that you
> have a "partial" implementation.  
..

The discussion was about the stuff that corresponds to
OBJECT-TYPE, (or possibly TEXTUAL-CONVENTION), not the stuff
the fits in with AGENT-CAPABILITIES or MODULE-COMPLIANCE.
It sounds like your thinking about modeling constructs to
describe the relationships between these reverse-engineered
SMING definitions and the original MIBs.

>                                   If a construct cannot reasonably be
> instantiated and provided, then it should not be in an info OR a data model.
> However, if it is reasonable, useful and we want to start standardizing on
> it, then it is a great candidate.
..

In this context, the issue is how much flexibility should be
provided in the re-use of definitions by specifications,
not in the instantiation.

 -------------------------------------------------------
 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.
 -------------------------------------------------------