RE: Methods in the NIM requirements

["Weiss, Walter" <WWeiss@lucentctc.com>]

Jon,

I believe you, Joel and David have summed up my concerns nicely.

1. I wanted to get a sense of how pervasive methods were to understand the
implications of the modeling language.

2. If it were pervasive, or at least of immediate necessity, I feel we would
want to beef up the requirements for methods to the same degree we have
fleshed out the requirements for attributes in the requirements spec.

3. It has not been clear to me, nor do I see concensus on, when methods
should be used and when attributes should be used. This is what I was
originally concerned with when this thread started (what I interpreted as
differing opinions on when to use each). This is still a significant issue
for me. From the example I posted yesterday, I have read and heard many
different opinions:

a: BandwidthAllocated is read/write
b: SetBandwidthAllocated ()
c: A generic container containing the value to be assigned and an Apply()
method.

4. Finally, I am concerned about how consistently the approach in (3) is
used. If there is concensus in principle on (3). There should be some
guidelines on when each should be used. This is specifically not part of the
requirements doc. However, early concensus will help determine how close we
all are and whether Juergen's prediction about a single model or yet another
model comes true. I for one certainly don't want to do yet another model. If
we can't or are unwilling to converge on these questions, we are almost
certainly doomed to failure.

regards,

-Walter

> -----Original Message-----
> From: Jon Saperia [mailto:saperia@mediaone.net]
> Sent: Monday, May 01, 2000 3:34 PM
> To: Joel M. Halpern; David Harrington
> Cc: nim@ops.ietf.org
> 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
> 
>