Re: Methods in the NIM requirements

[Mark Stevens <markstevens@lucent.com>]

John:
Perhaps my overview was  too simplistic. Rather than indicating that I
did not see a consensus on which of the three options we should choose,
I should have said that I don't see a consensus on where the balance
among then lies. That is to say, where do we find the balance between
the extremes I listed? We have not found the sweet spot yet, and
continued discussion seems to be the only way we will find it.

Thanks for your patience.
-Mark

John Strassner wrote:

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