RE: Methods in the NIM requirements

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

Walter, You are confusing the info model with specific implementations.  You
certainly can map both data and methods into repositories and protocols.

But, if you really want to restrict the model to "how is the model
applicable to the directory" (your words), then you don't need an info
model, nor any real-time/dynamic DATA (since again using your words,
"directories are not well suited for real-time status representations").
You just need a data model for a directory.  However, I believe that this
defeats your own goals for NIM.

Andrea

> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> Weiss, Walter
> Sent: Friday, April 28, 2000 10:44 AM
> To: 'John Strassner'; nim@ops.ietf.org
> Subject: RE: Methods in the NIM requirements
>
>
> John,
>
> Sorry for the dalay. The point is that the requirements document
> specifically seeks an information model which is equally applicable to a
> protocol, repository, and API. Therefore, I may want to use a NIM defined
> data structure to represent an interface via SNMP or I may want to use the
> same data structure to represent the state of a device in a
> repository, or I
> may want to use the repository distribute data structure to devices as
> configuration. In the last case, the paradigm suggests a write to the
> directory from a management entity and a read from the device to retrieve
> the configuration. As neither of the operations in this paradigm could be
> considered as real-time, the "go" semantic is at best ambiguous.
>
> regards,
>
> -Walter
>
> > ??? An information model is independent of any specific type
> > of repository. What does the directory have to do with
> > anything?
> >
> > regards,
> > John
>
> > > I think Keith's point is accurate (and I phrased my point
> > poorly), SNMP
> > > assumes a memory map model. Therefore, the protocol *and*
> > the data
> > > structures assume an interactive relationship with the
> > device (a "go" in
> > > Andrea's terms). But I think we are refining the
> > parameters of the question
> > > without discussing the question directly. If the NIM model
> > implies a "go"
> > > semantic, how is the model applicable to the directory. If
> > I have a method
> > > for reboot that means do it now, how do I represent the
> > current state
> > > (rebooting/(re)initializing/unavailable) of the machine
> > in a directory.
> > > "Go" implies real-time semantics, yet we all know that
> > directories are not
> > > well suited for real-time status representations.
> > >
> > > regards,
> > >
> > > -Walter
> > >
> > > > -----Original Message-----
> > > > From: remoore@us.ibm.com [mailto:remoore@us.ibm.com]
> > > > Sent: Wednesday, April 19, 2000 7:40 AM
> > > > To: Weiss, Walter
> > > > Cc: nim@ops.ietf.org
> > > > Subject: RE: Methods in the NIM requirements
> > > >
> > > >
> > > >
> > > >
> > > > Walter,
> > > >
> > > > You've said this twice now:
> > > >
> > > > >Should the semantics of "go" be in the model? If we
> > look at many
> > > > >of the models out there today, all have "go" semantics.
> > However,
> > > > >most are in the protocol itself. The SET command is
> > part of SNMP,
> > > > >not the MIB.
> > > >
> > > > >In contrast, when the model is applied to a management
> > protocol
> > > > >(SNMP), actions are implied by the protocol (GETs and
> > SETs).
> > > >
> > > > But it isn't true.  The semantics of SNMP's SET command
> > itself
> > > > are simply changing the value of a MIB object
> > (attribute).  If an
> > > > SNMP SET is going to have side effects, these *must* be
> > specified
> > > > in the MIB definition of the object being SET.
> > > >
> > > > The *protocol* operation that embodies the concept of an
> > action is
> > > > (not surprisingly) CMIS/CMIP's M-ACTION operation.
> > > >
> > > >
> > > > Regards,
> > > > Bob
> > > >
> > > > Bob Moore
> > > > IBM Networking Software
> > > > +1-919-254-4436
> > > > remoore@us.ibm.com
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>