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

Re: Methods in the NIM requirements



Hi Mark,

this helps, but I really don't understand why we need to
find such a balance. Method design is an art, and methods
are a general tool at the disposal of the designer. You
really need to talk about specific requirements that you are
modeling. It is the requirements that define what methods to
use, and without requirements, all you have is a general
tool.

regards,
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: 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
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>