[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Methods in the NIM requirements



... Just back from vacation ...

Hummm, I thought that this methods discussion ended weeks ago. Obviously the
consensus is that we need both methods and attributes in the info model.
Clearly, however, we must provide some guidance as to what sorts of things
you model using methods and what sorts of things you model using attributes.
We must be able to provide such guidance otherwise we are only touting a
bunch of B.S. ... Count me as two hands up for such additional guidance or
we will end up with a model that will soon grow to be fundamentally
inconsistent with itself (e.g. he uses attributes to model X, she used
methods to model the same exact thing). Really, if the choice is completely
arbitrary, something is seriously screwed-up in the  holy theoretician's
world of proper 00 design.

-Dave

> ----- 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: Tuesday, May 02, 2000 8:44 AM
> Subject: Re: Methods in the NIM requirements
> 
> 
> > 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
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
> 
> 
>