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

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