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

Re: Methods in the NIM requirements



Before you do that, please read my response to you. Since
methods are just a generic tool available to the designer, I
think that this is a fruitless effort. Instead, we need to
concentrate on a set of use cases and develop a set of
guidelines of how to use methods based off of the
requirements, not off of the method itself.

regards,
John
----- Original Message -----
From: "Mark Stevens" <markstevens@lucent.com>
To: "Andrea Westerinen" <andreawest@mindspring.com>
Cc: "John Strassner" <jstrassn@cisco.com>; "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 11:26 AM
Subject: Re: Methods in the NIM requirements


> Andrea:
> I am looking for consensus on what is meant by
"appropriate" rather than a
> consensus that we appear to have, which merely states that
we will only use
> methods where we think we should. Saying that we will use
methods only when we
> think we should is not as valuable as developing a
consensus on rough
> guidelines for making the determination itself.
>
> I will go back and re-read  the thread to see if I can
synthesize a set of
> guidelines that would help a would-be modeler determine
whether or not the use
> of methods is appropriate for a given set of situations.
>
> -Mark
>
> Andrea Westerinen wrote:
>
> > I will try again (I sent this yesterday and it generated
no traffic,
> > unbelievable :-).
> >
> > "I believe that there is a consensus ...
> >
> > Use methods where the NIM WG (if one forms) believes
that they are
> > appropriate
> >
> > If the WG does not form, then there is no need to carry
on this discussion.
> >
> > An everything/nothing argument seems a foolhardy
approach."
> >
> > Andrea
> >
> > > -----Original Message-----
> > > From: owner-nim@ops.ietf.org
[mailto:owner-nim@ops.ietf.org]On Behalf Of
> > > Mark Stevens
> > > Sent: Tuesday, May 02, 2000 8:45 AM
> > > To: John Strassner
> > > Cc: Jon Saperia; Joel M. Halpern; David Harrington;
nim@ops.ietf.org
> > > 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>