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

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