RE: What we want to accomplish

["Durham, David" <david.durham@intel.com>]

Comments to comments:
-Dave
> -----Original Message-----
> From: John Strassner [mailto:jstrassn@cisco.com]
> Sent: Tuesday, April 18, 2000 11:05 PM
> To: Durham, David; 'Randy Bush'; Andrea Westerinen
> Cc: nim@ops.ietf.org
> Subject: Re: What we want to accomplish
> 
> 
> "Everything should be as simple as possible, but not
> simpler" - Einstein
> 

[Dave] I will never argue with Einstein... Well, there was that Universal
Constant fiasco... But, really, just water under the bridge:)

> more specific comments inline.
> 
> regards,
> John
> ----- Original Message -----
> From: "Durham, David" <david.durham@intel.com>
> To: "'Randy Bush'" <randy@psg.com>; "Andrea Westerinen"
> <andreawest@mindspring.com>
> Cc: <nim@ops.ietf.org>
> Sent: Tuesday, April 18, 2000 11:01 AM
> Subject: NIM: What we want to accomplish
> 
> 
> > I agree with Randy (because he has his reality hat on) and
> vote for inherent
> > simplicity, methods notwithstanding. Fundamentally, we
> want a model that is
> > easy to grok and is attractive to the subject experts such
> that THEY can
> > move relevant information out of their heads and into the
> model. This is
> > verses having modeling experts have to learn what's in all
> the subject
> > matter experts heads and try to integrate this into a
> model.
> >
> > To me this means:
> >
> > 1. Avoid excessive hierarchy
> 
> Why? Modeling == Classification. Classification needs
> hierarchIES (not just inheritance, but also aggregation) to
> properly protrary knowledge.
> 
> Please understand that I do agree with the overall goal of
> simplification. But let's not rush into cutting things out
> without proper examination that it doesn't hurt the model.
> 

[Dave] I agree the point of excessive hierarchies may be too ambiguous to
debate... We should be sensitive to the point though. More on aggregations
below, but I think aggregations can be dealt with via a more short-hand
representation. Pictures that look like a badly constructed spider webs are
found by many to be confusing.

> > 2. Avoid class REFERENCE explosion (Perhaps by avoiding
> aggregations and
> > instead using good-o'l-fashion containment and by creating
> some short-hand
> > notation for the real associations)
> 
> Aggregation is a modeling construct, containment is an
> implementation...
> 

[Dave] Absolutely, but where you may want a composite structure (classes in
classes), I think you should have the freedom in the information model to do
exactly that. Such a structure implies to me that the lifetime of all
"contained" classes are the same as their container. CIM today represents
such things by 1-1 aggregations, which works okay (I guess), but it's also
more spider web. C++, JAVA, XML, etc. can all handle composite structures,
so should the model. If an implementation can't (SMI MIBs or MOFs say), then
instances of such structures can simply map into separate but associated
instances. ... I believe the information model should make it easier for the
modeler. 

> > 3. Reusability of ALL constructs (existing and future).
> Model it once
> > (extend it many), so that we don't keep re-inventing the
> wheel.
> 
> ??? Don't grok what you mean here

[Dave] Well, the model should define its subnet ID structure (IPNumber +
Mask) once, not a zillion times. Inheritance hierarchies can screw-up reuse
when the data you want to reuse is defined off the wrong branch in the tree.
I believe containment (as implied above) will allow a large number of
reusable base data classes (such as subnet ID) to be defined once, and then
reused by many other classes, including other base data classes. These base
classes can be defined once and precisely constrained, and then simply
contained as attributes in other classes. The base classes can also be
extended as the need arises (say moving from IPv4 to IPv6) and all the
zillions of their container classes will benefit from not requiring
redefinition. That's OO at its best.

> 
> > 4. Scope the model... People tend to only be interested in
> a particular
> > subject area, so have mechanisms where the relevant subset
> of the model can
> > be easily identified (Andrea's requirement methinks)
> > 5. Model it precisely yet succinctly (constraint language
> will help oodles
> > here)
> 
> And a constraint language will complicate things too, both
> in adding classes and relationships as well as language
> constructs. So be careful what you ask for...
> 

[Dave] Your favorite example of UML + OCL would be a possibility. I think
you can define the model more generically (and therefore succinctly) and
then use a constraint language to describe precisely what you meant
(exceptions, restrictions, etc.). In CIM we do generic without the benefit
of a constraint language, but I feel this makes the resulting model
ambiguous. On the flip side, we can model very precisely (limiting the need
for a constraint language), but then have class and reference explosions up
where the sun-don't-shine.

> > 6. Don't think WE have to model the Universe: Instead
> provide (decide on) an
> > appropriate tool set and conventions such that those in
> the Universe can
> > effectively (and consistently) model themselves. This is
> what I see NIM
> > fundamentally accomplishing.
> >
> > 1+2+3+4+5+6 = 24x80 (for what you are interested in
> anyway).
> >
> > Cheers,
> > -Dave
> >
> >
> > > -----Original Message-----
> > > From: Randy Bush [mailto:randy@psg.com]
> > > Sent: Monday, April 17, 2000 11:36 PM
> > > To: Andrea Westerinen
> > > Cc: nim@ops.ietf.org
> > > Subject: RE: Closing on NIM requirements
> > >
> > >
> > > > The data/relationships/methods must be modeled enough,
> but
> > > not too much.
> > > > So, I always start with the problems being solved
> > > (requirements), and move
> > > > to the nouns and verbs.  I never start with a
> predefined
> > > model in mind.
> > >
> > > well, policy framework started with cim handed down from
> > > dmtf, and has been
> > > trying to recover 'ere since.
> > >
> > > so, what are the requirements here?  for what purpose(s)
> are
> > > we trying to
> > > model what?  can we get it on one 24x80 screen?
> > >
> > > randy
> > >
> > >
> >
> >
> >
> >
> 
>