Re: Closing on NIM requirements

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

>So my question then becomes, shouldn't there be
>two models, one declarative model for the
>attributes and then another model for the use
> of those attributes within operations?

No, this breaks encapsulation, which is a fundamental tenet
of object-oriented analysis and design.

regards,
John
----- Original Message -----
From: "Durham, David" <david.durham@intel.com>
To: "'Harald Tveit Alvestrand'" <Harald@Alvestrand.no>;
"'Weiss, Walter'" <WWeiss@lucentctc.com>; <nim@ops.ietf.org>
Sent: Sunday, April 16, 2000 1:40 PM
Subject: RE: Closing on NIM requirements


> I agree SNMP can indirectly and inefficiently simulate
methods in that you
> can set a bunch of OIDs (call them arguments), set the
runMethod OID (call
> the method), and then poll/get the result OID (or trigger
a report). But
> LDAP as an RPC model??? Not a chance.
>
> Nonetheless, operations still require the
attributes/classes (data) to be
> defined as well. So my question then becomes, shouldn't
there be two models,
> one declarative model for the attributes and then another
model for the use
> of those attributes within operations?
>
> -Dave
>
> > -----Original Message-----
> > From: Harald Tveit Alvestrand
[mailto:Harald@Alvestrand.no]
> > Sent: Sunday, April 16, 2000 1:05 AM
> > To: Durham, David; 'Weiss, Walter'; 'nim@ops.ietf.org'
> > Subject: RE: Closing on NIM requirements
> >
> >
> > At 15:49 15.04.2000 -0700, Durham, David wrote:
> > >Methods seem to
> > >break repository models (which do not support them
directly)
> > as well as
> > >protocol models that strictly set/get or add/remove
named
> > data (eg. SNMP).
> >
> > I'd claim the opposite argument: That the many
> > set-data-and-cause-magic-to-happen variables in SNMP
MIBs
> > proves that as a
> > modelling language, it suffers greatly from its decision
to disallow
> > methods and stick only to data.
> >
> >
Set-data-and-poll-result-variable-until-its-value-changes is
> > an RPC model,
> > just not an efficient one.
> >
> >                   Harald
> >
> > --
> > Harald Tveit Alvestrand, EDB Maxware, Norway
> > Harald.Alvestrand@edb.maxware.no
> >
> >
> >
>
>
>
>