RE: Methods in the NIM requirements

["Andrea Westerinen" <andreawest@mindspring.com>]

A few clarifications (I hope :-) inline ...
Andrea

> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> Lakshmi Raman
> Sent: Monday, May 01, 2000 4:56 PM
> To: Keith McCloghrie
> Cc: Weiss Walter; 'Lakshmi Raman'; nim@ops.ietf.org
> Subject: Re: Methods in the NIM requirements
>
> comments in line
>
> Keith McCloghrie <kzm@cisco.com> on 05/01/2000 07:47:26 PM
>
> To:   WWeiss@lucentctc.com (Weiss Walter)
> cc:   lraman@telcordia.com ('Lakshmi Raman'), nim@ops.ietf.org
> (bcc: Lakshmi
>       Raman/Telcordia)
> Subject:  Re: Methods in the NIM requirements
>
>
> >  ...  If I understand your
> > comments below, you would describe attributes as any element that is
> > persistent for the life of the object.
>
> There are attributes which do not have values for the life of an object.
> For example, interval counters do not have values between the birth of
> an object and the expiry of an interval timer.  Similarly, it seems
> reasonable that an attribute's value could have a TTL, and you should
> be able to read it while it's still valid.
> <LR> No that is not what I meant. if an attribute has a zero
> value as in the previous case, you would include it as an attribute.
> It is still a property that is part of the object and exists for
> its life time.

<arw> I agree, but posit that "exists" is the wrong word.  Perhaps, "Has a
context and meaning throughout the life of the object" may be better.
Admittedly, at specific times in the object's life, that "meaning" may be
zero or null, but this would be due to the current state of the object, not
because the property does not have meaning.

>
> > Attributes can be read or written
>
> or both.
> >LR> yes
>
> > Methods deal with cross-object interactions.
>
> If "clear an object's counters" were allowed, wouldn't it be a method,
> but have no interaction with any other object ??
> <LR> yes. It can be a method and it was never meant to exclude the case
> where a single object is impacted. Again that was an example as we seem
> to looking for guidelines.

<arw> Interactions between objects are a form of "behavior".  I would like
to put our guidelines for methods at "behavior" (for example, reboot or
interaction between objects), and stay away from data manipulation concepts
like read/write.  We can discuss whether "clear counter" is a method (I
would agree with Lakshmi that it is), but this takes us into the modeling
rathole when we are at the info model requirement stage.  Can we stay in one
rathole at a time?  Can we just leave our requirements at "we will use
methods where the NIM WG decides that they are needed"?

>
> Keith.
>
>
>
>
>