RE: Closing on NIM requirements - New Thread for CIM/DMTF

["Andrea Westerinen" <andreawest@mindspring.com>]

Jon, I basically agree with your points.  I would also add in #1 that where
appropriate we should take NIM back into the DMTF.  Having standards bodies
cooperate is not a foreign concept :-).  I do it all the time.

IMHO, getting the subject matter experts involved and creating a workable
model are important.  That is why I am part of the NIM effort in the IETF.

What are your suggestions for increased hierarchy, mentioned in #2?  I would
be very interested in discussing this with you.

Andrea

> -----Original Message-----
> From: Jon Saperia [mailto:saperia@mediaone.net]
> Sent: Tuesday, April 18, 2000 5:44 AM
> To: Andrea Westerinen; Randy Bush
> Cc: nim@ops.ietf.org
> Subject: Re: Closing on NIM requirements - New Thread for CIM/DMTF
>
>
> on 04/18/2000 3:09 AM, Andrea Westerinen at
> andreawest@mindspring.com wrote:
>
> > I do agree that CIM should be simplified (which I am actively working to
> > bring a proposal forward to the DMTF).  However, the basic
> constructs and
> > thinking behind CIM are reasonable. Perhaps some details are
> flawed, but I
> > do not know of one design that was perfect in its first iteration.
>
> I broke this off to a separate title since these questions/issues may
> different than the main topic currently under discussion.  Perhaps these
> issues have been dealt with, if so, sorry for raising them again.
>
> 1. Since I assume DMTF is not giving change control of CIM to the IETF, we
> should take whatever we want from it, leave what we do not want and change
> it (of course with proper attribution) to be whatever is sufficient and
> necessary for our purposes. I am aware that is what some people
> are working
> toward. The point is that it is fine to make proposals to other
> organizations and cooperate with them. Our first goal should be for
> developing what works where that includes elements of timeliness,
> simplicity
> and implementability.
>
> 2. I appreciate the comments people have made that the model we
> are talking
> about is necessarily complex. We must also be sensitive to willingness and
> ability to undertake work with the model by others. This is particularly
> true for the applications people. Also it needs to be simple
> enough so that
> at a high level operational people can grok it as well. In the
> presentations
> I have seen, minimally the top level seems unaproachably complex. One
> suggestion to help would be to create a bit more of a hierarchy
> than exists
> now.
>
> 3. On the topic of attributes and operations, I find that I agree with the
> traditional OO views, that is that the class definition includes
> three parts
> (at least when expressed in UML) The Class name, attributes and
> operations.
> I found a review of the book Fundamentals of Object-Oriented Design in UML
> by Larry Constantine helpful. This may appear to be in conflict with other
> observations I have made about the requirement that we be able to take
> things expressed this way and use the tools we have to realize them.  In
> some places this will be easy and in some places this will be
> hard. This is
> the 'Reality' string Harald and I had yesterday.
>
> /jon
>