[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Methods in the NIM requirements
I don't think we said anything about the criteria for determining the
guidelines. If you want to discuss criteria, I think use cases are quite
reasonable. However, I have not heard an overwhelming desire to debate the
guidelines on this list. Hence, my request for volunteers. It would appear
by Mark's earlier mail that he has unwittingly volunteered ;)
regards,
-Walter
> -----Original Message-----
> From: John Strassner [mailto:jstrassn@cisco.com]
> Sent: Tuesday, May 02, 2000 8:01 PM
> To: Mark Stevens (E-mail); Andrea Westerinen
> Cc: Jon Saperia; Joel M. Halpern; David Harrington; nim@ops.ietf.org
> Subject: 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
>
>
>