Re: Methods in the NIM requirements

["John Strassner" <jstrassn@cisco.com>]

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