Re: Methods in the NIM requirements

["John Strassner" <jstrassn@cisco.com>]

Why in the world would you characterize methods with the
three choices you've listed below? We've done everything
including quoting textbooks that say that a method is an
intrinsic tool in designing a class. The fact that not all
classes have methods is irrelevant.

And I disagree that we don't have consensus, people from
many different backgrounds have overwhelmingly agreed that
methods should be used.

John
----- Original Message -----
From: "Mark Stevens" <markstevens@lucent.com>
To: "John Strassner" <jstrassn@cisco.com>
Cc: "Jon Saperia" <saperia@mediaone.net>; "Joel M. Halpern"
<joel@ivyplan.com>; "David Harrington" <dbh@cabletron.com>;
<nim@ops.ietf.org>
Sent: Monday, May 01, 2000 2:24 PM
Subject: Re: Methods in the NIM requirements


> John:
>
> The way I see it, we've got three choices:
>     - methods for everything
>     - methods for some things, but not others, or
>     - methods for nothing (attributes only).
>
> Making this choice is foundational. It will affect
everything we do from
> here on out. Based on my reading of this thread, I see no
clear cut
> conclusion, and I see no clear cut concensus. So, we need
to continue to
> refine the discussion.
>
> Our choice with respect to the three options listed above
speaks to the
> basic tenets of the proposed work. Until a good number of
us has a clear
> understanding of the ramifications of our choices, we must
push on with
> this discussion despite the fatigue that may be afflicting
us.
> Otherwise, I fear that we will face certain failure when
these issues
> resurface after we are well into the task of developing
models.
>
> -Mark
>
> John Strassner wrote:
>
> > With respect to the QoS Device model, the reason that
there
> > are no methods in it is solely because:
> >
> >   1) this is modeling state only
> >   2) configuration and other complex beasts
> >      may well require methods, but these
> >      will be built in an overlay model (e.g.,
> >      a model that intersects this model)
> >
> > It is NOT because I don't think that there aren't any
useful
> > methods to define in this model.
> >
> > That being said, let's please close this thread.
> >
> > regards,
> > John
> > ----- Original Message -----
> > From: "Jon Saperia" <saperia@mediaone.net>
> > To: "Joel M. Halpern" <joel@ivyplan.com>; "David
Harrington"
> > <dbh@cabletron.com>
> > Cc: <nim@ops.ietf.org>
> > Sent: Monday, May 01, 2000 12:34 PM
> > Subject: Re: Methods in the NIM requirements
> >
> > > on 05/01/2000 2:38 PM, Joel M. Halpern at
joel@ivyplan.com
> > wrote:
> > >
> > > > While I can not construct a strong example of what
> > methods the information
> > > > model requires, I am very much of the opinion that
the
> > modeling tool must
> > > > include support for methods.  For most attributes,
read
> > / write attribute
> > > > semantics will suffice, but for some cases methods
with
> > signatures and
> > > > semantics will be necessary.  I rather hope and
expect
> > that that is one of
> > > > the place where the power of inheritance will come
into
> > play as
> > > > well.  Otherwise it is purely a textual convention.
> > >
> > > I think this is well said. In the end much of what is
> > needed may not require
> > > methods. The important point is to be very careful if
they
> > are to be
> > > defined.
> > >
> > > The Qos Device Model was brought up by John recently.
I
> > have worked with the
> > > people developing the Differentiated Services Policy
MIB
> > Module and mapped
> > > the Qos Device Model to that. It works pretty well
though
> > there are some
> > > places we have some 'tuning' to do. An interesting
> > observation I would make
> > > however is that the UML diagram I see by John S.,
Walter
> > and David D. has
> > > only ClassNames and Attributes. There is not a single
> > method on the whole
> > > diagram. That does not mean methods are not good or
that a
> > language should
> > > not support them - I think it should. The point is
that we
> > should use them
> > > only when required.
> > >
> > > /jon
> > >
> > >
> > >
>
>